Okta’s 3 November 2026 production notes list Provisioning Agent 3.3.2: Amazon Corretto JRE 17.0.21.0.10, removal of distrusted roots, and RPM/Windows coverage. Production notes
Two trust checks to separate
Okta warns that chains ending at removed roots fail SCIM TLS validation. Upgrades replace the bundled JRE, so previously imported custom certificates need reimporting. Agent history
Replace distrusted chains; reimport only approved custom certificates. Never restore the whole old trust store.
A focused upgrade checklist
The following are recommended operational checks, rather than reported test results:
- Map the connection. Record the installed agent version, the SCIM server names it contacts, the chains those servers present, and any custom trust entries. Keep passwords, tokens and private keys out of this inventory.
- Review custom certificates. Identify their owners and why they are needed. Verify certificate fingerprints against an authoritative internal source before importing approved entries into the upgraded agent’s runtime. A certificate copied from an unverified connection is not enough evidence to trust it.
- Test a limited deployment. Use a test environment or an approved pilot. Check the agent’s active Java runtime and its actual connection to each relevant SCIM endpoint, rather than assuming an installer’s success means provisioning works.
- Exercise the account lifecycle. With designated test accounts, verify the import, creation, attribute-update and deactivation operations your integration uses. Review failures and confirm downstream state, especially for queued or retried changes.
Okta’s connector documentation describes the agent trust store and recommends HTTPS. Follow the instructions appropriate to the installed platform; do not substitute an old example path without checking it. SCIM connector documentation
Keep the security boundary intact
If provisioning fails after the upgrade, do not disable TLS validation or switch the connector to HTTP. Diagnose the presented chain and missing approved trust entries, then fix the relevant configuration. Treat any rollback as a controlled temporary recovery decision, not a substitute for resolving the trust dependency.
The entries identify neither roots nor CVEs. Impact depends on your deployment; no hands-on testing was performed.