<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content

Deployment Model - Customized Okta Hosted SIW

Administration

Telemetry detected custom JavaScript, CSS, or both on the Okta Hosted Sign-In page (CUSTOM_SIGN_IN_PAGE). Okta includes this org in the App branding migration upgrade path, so Okta upgrades the org to Okta Identity Engine (OIE) while the customized Sign-In Widget and existing apps continue to run on Classic Engine, with no change to the sign-in experience at upgrade. Identity Engine adoption becomes a post-upgrade task: update the widget code on the cloned Identity Engine brand, then switch apps to Identity Engine one at a time. The upgrade cannot proceed until an administrator gives consent.

What changes with the upgrade: Okta clones each Classic Engine brand into an Identity Engine brand. The live Classic Engine sign-in page and email templates keep their customizations, so end users see no change to sign-in at upgrade.

Okta first-party apps, such as the Admin Console, upgrade automatically and always run on Identity Engine. All other apps keep the Classic Engine sign-in pipeline and their Classic Engine app sign-on policies until an administrator changes the Authentication pipeline setting for each app. Other policies upgrade immediately, and future changes to those policies can affect Classic Engine apps.

After the upgrade, the cloned Identity Engine brand controls the End-User Dashboard and error pages. Review these pages if the Classic Engine brand carries customizations for them.

After an administrator gives consent, eligibility advances to Eligible - Ready to Upgrade. The upgrade requires no widget remediation because the customized Classic Engine sign-in page remains in place.

What Changes When an App Moves to Identity Engine?

The customized Okta Hosted Sign-In page continues to serve every app that remains on Classic Engine. Sign-in impact begins only when an administrator switches an app to Identity Engine. After an app uses an Identity Engine policy, the sign-in page on the cloned Identity Engine brand serves the app once an administrator publishes that page. The cloned sign-in page is an exact copy of the Classic Engine page, so Classic-only code in it stops working in Identity Engine until an administrator updates the widget code.

 

Review deprecated JavaScript methods, Extended Flows JavaScript, and CSS overrides on the cloned Identity Engine brand before switching any app:

  • Deprecated JavaScript methods: some methods valid in Classic Engine are unavailable or behave differently in Identity Engine. See Deprecated JavaScript methods.
  • Extended Flows JavaScript: code that uses OktaUtil.getRequestContext to switch behavior based on application context requires review for Identity Engine compatibility.
  • CSS overrides: style overrides tied to the Classic widget Document Object Model (DOM) structure require testing against the Identity Engine widget DOM structure.

Before the Upgrade

Complete the Upgrade Hub action items, consent to the Migrate Apps and Brands One by One item, inventory the apps and brands that use the customized sign-in page, and then schedule the upgrade:

  1. Complete the remaining action items in the Upgrade Hub.

  2. Review the Migrate Apps and Brands One by One item, select I have read and agree with the changes described above., and select Submit.

  3. Review the Applications and Brands lists to identify the apps and brands that use the customized Okta Hosted Sign-In page, and rank the apps from lowest to highest risk.

  4. Schedule the upgrade for a date and time with the least operational impact. Okta sends a confirmation email to all administrators.

After the Upgrade

Update the sign-in page on the cloned Identity Engine brand, switch apps to Identity Engine one at a time by changing each app’s Authentication pipeline setting, and assign each switched app to its app sign-in policy and user profile policy.

 

Step 1: Update the sign-in page on the cloned Identity Engine brand

Open the cloned Identity Engine brand in Customizations > Brands, update the code in the Sign-in page section, confirm the Sign-In Widget version, and review the End-User Dashboard, error pages, and custom domain, as described in Configure brands after app branding migration:

  1. In the Admin Console, go to Customizations > Brands. Each Classic Engine brand, marked Classic, appears next to its cloned Identity Engine brand, named with a - Clone suffix. The Default Okta Subdomain brand migrates automatically and needs no changes.

  2. Select the cloned Identity Engine brand.

  3. On the Pages tab, select Configure in the Sign-in page section.

  4. Remove deprecated JavaScript methods and Classic-dependent OktaUtil.getRequestContext logic, and test CSS overrides against the Identity Engine widget DOM structure. Update and preview the page until it is ready to publish.

  5. On the Settings tab, review the Sign-In Widget version. The upgrade sets the cloned brand to the latest widget version, so the brand needs no separate version update.

  6. On the Pages tab, review the End-User Dashboard and error pages, and configure them if needed.

  7. On the Domains tab, review the custom domain assignment. An administrator can reassign a custom domain only to another Identity Engine brand.

  8. Repeat these steps for each Classic Engine brand and its cloned Identity Engine brand.

NOTE: To protect the existing Classic Engine customizations until cutover, pin a specific Sign-In Widget version on the Settings tab of the Classic Engine brand sign-in page.

 

NOTE: The sign-in page preview renders only the base HTML and JavaScript. If the page includes logic based on application context, such as OktaUtil.getRequestContext, or loads external resources, the preview may not render it fully. Test these pages with a sample application before publishing.

Post-Upgrade Warning (publishing the Identity Engine sign-in page): After an administrator publishes the sign-in page on the cloned Identity Engine brand, Okta sends end users of apps that use an Identity Engine policy to that page. Okta displays the Classic Engine sign-in page only for apps that still use a Classic Engine app sign-on policy.

Preview the cloned sign-in page, then test it with a sample application before publishing.

 

Step 2: Switch apps to Identity Engine one at a time

Set each app’s Authentication pipeline to Okta Identity Engine on the Sign On tab, starting with the lowest-risk app, and verify sign-in before moving to the next app, as described in Upgrade apps to Identity Engine:

  1. In the Admin Console, go to Applications > Applications and select the lowest-risk app. Apps still on Classic Engine show a Classic tag.

  2. On the Sign On tab, in the User authentication section, select Edit.

  3. Set Authentication pipeline to Okta Identity Engine, confirm the Authentication policy field shows Migrated policy, then select Save. Okta migrates the app’s Classic Engine app sign-on policy into an Identity Engine authentication policy with similar assurance requirements and keeps a snapshot of the Classic Engine policy for rollback.

  4. Select Policy details to open the migrated policy and confirm its rules match the intended outcomes.

  5. Verify the sign-in flow for the app.

  6. Review the app’s authenticator settings. See Configure the password authenticator after app branding migration.

  7. Repeat these steps for the remaining apps in order of risk.

To roll back an app, repeat steps 1 and 2 of this procedure, set Authentication pipeline to Classic, and select Save. For bulk migrations, set the authentication pipeline through the Apps API.

 

Which policies apply after an app switches?

Review the app sign-in policy and the user profile policy for each switched app, and assign apps according to the org’s requirements, as described in Assign migrated apps to Identity Engine policies:

  • App sign-in policy: see Assign apps to an app sign-in policy. The global session policy applies org-wide and can require stricter session establishment or multi-factor authentication (MFA) behavior than an individual app sign-in policy allows.
  • User profile policy: see Add apps to a user profile policy. Identity Engine merges self-service registration and progressive enrollment into user profile policies that apply to specific apps or groups.

NOTE: Administrators can add only Identity Engine apps to app sign-in policies and user profile policies.

Post-Upgrade Warning (apps that remain on Classic Engine): Apps that remain on Classic Engine cannot use Identity Engine capabilities such as Okta FastPass, device assurance policies, Identity Engine authentication policies, and self-service registration until an administrator switches them.

Post-Upgrade Parity

The upgrade requires no parity changes. Apps keep the existing customized Classic Engine sign-in experience until an administrator switches them.

 

Post-Upgrade Enhanced Experience (OIE Functionality)

After apps switch, review email templates and widget code, then extend the sign-in experience with Identity Engine sign-in policies and Profile Enrollment Policies:

  • Discovery Dependent: Review and update Email Templates (Activation and Recovery)
  • Discovery Dependent: Update Sign-In Widget JavaScript and CSS for the OIE widget structure
  • Enhance with Sign-in Policies (Global Session and Authentication policies)
  • Enhance with Profile Enrollment Policies

Artificial Intelligence (AI) Code Review Prompt

AI findings are a starting point, so verify all results through end-to-end testing before publishing the cloned sign-in page. To get a scored OIE compatibility review, copy the prompt below into any AI assistant and replace [PASTE SOURCE CODE HERE] with the full HTML, JavaScript, and CSS from the Sign-in page of the cloned Identity Engine brand:

You are an Okta Sign-In Widget specialist. Review this custom Okta-hosted sign-in page for OIE upgrade compatibility. The code comes from the cloned Identity Engine brand created by App branding migration.

[PASTE SOURCE CODE HERE]

---

WHAT TO CHECK:

Deprecated feature flags (+1 pt each if present):
features.idpDiscovery, features.rememberMe, features.autoPush, features.smsRecovery,
features.callRecovery, features.webauthn, features.selfServiceUnlock,
features.multiOptionalFactorEnroll, features.registration,
features.showPasswordToggleOnSignInPage, features.scrollOnError,
features.skipIdpFactorVerificationBtn

High impact (+3 pts each): registration: {  |  .setCookieAndRedirect(  |  processCreds:
Medium impact (+2 pts each): .preSubmit( or .postSubmit(  |  parseSchema:
Low impact (+1 pt): idps: [  (still works in OIE, no change required)

CSS rules targeting #okta-sign-in or .auth-container: 1 to 10 = +1 | 11 to 30 = +2 | 30+ = +3
i18n overrides (config.i18n or englishLanguage[): +1
Event hooks (oktaSignIn.on(): +1

EFFORT TIER:
0 = DEFAULT (no findings)  |  1 to 4 = LOW  |  5 to 9 = MEDIUM  |  10 to 14 = HIGH  |  15+ = CRITICAL

---

OUTPUT:
For each finding: matched line with ±1 line context, OIE impact explanation, and remediation action.
Close with a scored summary table, effort tier, and priority-ordered action list.
Cite links from the reference list below where applicable.

---

REFERENCE LINKS:
Deprecated feature flags / widget upgrade: https://developer.okta.com/docs/guides/oie-upgrade-sign-in-widget/main/
Deprecated JavaScript methods: https://developer.okta.com/docs/guides/oie-upgrade-sign-in-widget-deprecated-methods/main/
setCookieAndRedirect: https://developer.okta.com/docs/guides/oie-upgrade-sessions-api/main/
Registration block: https://support.okta.com/help/s/article/OIE-Incompatible-FF-SELFSERVICEREGISTRATION
CSS / custom sign-in page: https://help.okta.com/oie/en-us/content/topics/identity-engine-upgrade/self-service/custom-sign-in-page.htm
OIE upgrade overview: https://developer.okta.com/docs/guides/oie-upgrade-overview/main/
App branding migration: https://help.okta.com/oie/en-us/content/topics/identity-engine-upgrade/app-branding-migration.htm
General upgrade hub: https://support.okta.com/help/s/product-hub/oie/upgrading-to-okta-identity-engine

Related References

Loading
Deployment Model - Customized Okta Hosted SIW | Okta Support