Post-rollback SAML attribute drift after failed Okta upgrade

Rollback Behavior for SAML and Integrations

Okta's automatic rollback mechanism is designed to revert the platform's core version and system state, but it does not function as a full database snapshot of application-level configurations. Consequently, custom SAML attribute statements and third-party integration configurations are not guaranteed to be restored and may require manual intervention.

Configuration Persistence and Gaps

Based on platform behavior, here is the breakdown of what is typically captured versus what is at risk during a rollback:

• SAML Attribute Statements: These are treated as application-level configuration data. Because these can be modified independently of the platform version, they are often excluded from the system-level rollback snapshot to prevent accidental overwriting of intentional changes made during the upgrade window.
• Integration Tokens and Endpoints: Secrets and tokens are stored in secure vaults. To prevent credential regression or security holes, these are generally not reverted by a version rollback. Endpoint configurations may persist in the "upgraded" state even after the platform version is rolled back.

Verification and Recovery Steps

Since the Activity Log does not provide a configuration "diff," you must manually verify the state of your integrations after a rollback completes:

1. Compare Attributes: Cross-reference the current SAML attribute mappings in the Admin Console against your pre-upgrade manual exports or documentation.
2. Test Assertion Flow: Trigger a test authentication flow with a sample user and inspect the SAML assertion (using a browser extension like SAML Tracer) to ensure all required attributes are present and correctly formatted.
3. Validate Tokens: Test connectivity to third-party integrations to ensure tokens remained valid and endpoints were not altered.

Activity Log Indicators

There is no single event type that definitively confirms a "full restore" of configurations. Instead, look for the absence of application.attribute.update events occurring after the rollback timestamp. If the rollback successfully reverted a change, the log will not show a "revert" event; it will simply reflect the state of the system. If you see updates occurring during the upgrade but no corresponding updates during the rollback, the attributes likely remained in the drifted (upgraded) state.

Diagnostic Detail Needed: To provide a more specific recovery path, please clarify if the failed upgrade involved a migration to a new Okta cell or remained within the same tenant infrastructure, as this changes how configuration data is mirrored.