If you're transitioning from Entra ID to Rippling for your HR integration with Secureframe, follow these recommended steps to ensure a smooth switch:

Connect Rippling first: Rippling has higher precedence for all personnel attributes. When both integrations are connected, Secureframe will prioritize data from Rippling.

Review personnel data: Once Rippling is connected, go to the Personnel Details page to verify that data is syncing correctly. You can also see the source of each attribute to help identify any gaps.

Only remove Entra after confirming Rippling data is correct: Keeping Entra connected temporarily allows for comparison and validation. Once you're confident that Rippling is supplying complete and accurate data, you can safely uninstall the Entra ID integration.

Deactivating a service in Microsoft/Entra will update in Secureframe within 24 hours (after the next sync runs), but the application will remain in your Detected Applications list, it won't automatically disappear. Similarly, if you mark a vendor as "Ignored" and then remove it from Entra, it will stay on your Ignored list in Secureframe. Detected Applications is essentially a historical log of applications we've detected, giving you visibility into what's been connected. You can choose to add them to your vendor inventory or keep them ignored, but the list itself doesn't automatically remove entries when connections are deactivated.

Not at this time. SCIM provisioning for Microsoft Entra / Azure AD is on the roadmap. Contact [email protected] if you want to be added to the feature request.

No, the Jamf Pro integration does not support Okta OIDC credentials. The integration only accepts a Jamf native service account using a username, password, and domain. You'll need to create a dedicated service account directly in Jamf Pro and use those credentials to connect.

MFA test failures are usually a policy-coverage, enrollment, or sync-timing issue. See FAQs: Integration MFA tests, enrollment gaps, and troubleshooting for the full Okta checklist.

We do not currently support this specific Fast Pass feature from OKTA.

Okta FastPass is included with certain Okta packages, but not available in all plans by default.

This error indicates an issue with the Okta configuration. Specifically, the user attempting to establish the connection is not assigned to the relevant Okta application. To resolve this, ensure the user is assigned to the application in Okta. You can follow the steps outlined in the Okta support article below and confirm step 4 of the connection form in the Secureframe portal is completed correctly:
​https://support.okta.com/help/s/article/How-To-Assign-An-User-To-An-Application?language=en_US

Secureframe now supports real-time updates for Okta, which allows us to detect and reflect user changes more quickly in the platform.

If you're setting up a new Okta connection, you’ll be prompted to enable this feature automatically.

If you're using an existing Okta integration, no action is required to maintain your current sync. However, to take advantage of real-time updates, you’ll need to reconnect the integration and follow the updated steps to grant the required permissions:

okta.eventHooks.manage

okta.eventHooks.read

You'll see a message in the platform (like the one shown above) guiding you through the process. Reconnecting will not disrupt your existing sync or data.

In some Okta configurations, refresh tokens automatically expire after a fixed period (commonly around 90 days), even if they are set as persistent. When this happens, Secureframe can no longer refresh the access token and the integration will disconnect, requiring you to reconnect Okta.

This behavior is driven by Okta’s authorization server and token expiration policies and can occur across many third-party integrations, it is not specific to Secureframe.

We regularly request and rotate refresh tokens while the integration is active, but in certain Okta setups the refresh token will still expire after its maximum lifetime.

What you can do:

Reconnect the Okta integration when prompted to restore syncing.

Review your Okta authorization server and token lifetime settings to confirm refresh token behavior.

If this occurs frequently, you may consider using Okta API token authentication instead. This avoids the refresh token expiration limit, but requires manual token creation and rotation.

If you continue to experience repeated disconnects, please contact Support so we can review your Okta configuration and recommend the best option.

Secureframe will typically match new records to existing users based on first name, last name, and email, so duplicates shouldn’t occur. However, there can be cases where the system doesn’t recognize a match, and a manual merge may be needed to combine duplicate accounts.

Single Sign-On (SSO) is included at no additional cost for customers on the Complete plan.

If you're not on the Complete plan, please contact your Account Manager or email [email protected] for pricing details.

If an SSO integration is disconnected but remains added in Secureframe, the personnel profiles will stay in the platform. However, if the integration is archived, you’ll have the option to delete the personnel associated with that integration.

Check the integration filter settings for the Google Workspace connection. If a filter is configured that excludes users matching the customer's domain (e.g., NOT email:*domain*), those users will be discarded during sync and won't be able to log in. Review the filter logic and correct it so your domain is included rather than excluded. Once the filter is updated, affected users will be pulled in on the next sync.

During an IdP migration, Okta users in Staged are not fully active in Okta. Secureframe can interpret Staged as inactive or disabled and mark related personnel as offboarded.

This is expected with how Okta Staged status is mapped today. Staged does not mean "enabled employee" in Secureframe.

To keep users active in Secureframe during migration:

After users are enabled in Okta, re-sync the integration. Active Okta users should onboard or return to active status on the next successful sync.

Secureframe evaluates each connected account separately. The Okta connection and the Okta SCIM connection can appear as two accounts for the same person, even when both point at the same Okta tenant.

A user can be Suspended in Okta and correctly show as Disabled for the Okta app, while the Okta SCIM connected account still reports Enabled. That can keep Active Account(s) warnings or related access tests failing.

What to do:

When SCIM is enabled, Secureframe treats your identity provider (and any connected HR system) as sources of truth for active vs terminated status.

Common causes:

What to check:

If status still looks wrong after a fresh sync, contact [email protected] with the user email and screenshots of the Accounts rows.

Secureframe evaluates each connection separately, the same way it does for Okta and Okta SCIM.

Open Personnel → Accounts, compare the Google Workspace row to the Google Workspace SCIM row, re-sync both, and disconnect the duplicate connection if you only need one.