Okta Certificate Authority (CA) Renewal and Activation Process

Okta periodically renews the Okta Certificate Authority (CA) used for management attestation in the Okta Identity Engine (OIE) to maintain security and compliance. Depending on the MDM solution, administrators may need to download the renewed certificate and upload it to the Mobile Device Management (MDM) solution to prevent service disruptions. Microsoft Intune requires this; Jamf does not. Beginning with the 2026.09.2 release, organizations with the Okta CA renewal enhancement enabled follow an updated API process that prevents certificate validation failures during enrollment.

• Okta Identity Engine (OIE)
• Okta Certificate Authority (CA)
• Management Attestation Condition in Authentication Policies

To ensure the organization remains secure, Okta periodically renews its Certificate Authority (CA). This renewal process requires action to maintain continuous service and compliance. An Okta CA is valid for 5 years and automatically renews after 3.5 years. If an organization is leveraging Okta's management attestation feature, it may be necessary to upload the new CA to the MDM to allow new client certificates to be issued.

Microsoft Intune pins issued client certificates against the CA certificate in its Trusted Certificate Profile. If the SCEP configuration is switched to the renewed CA before that profile is updated, devices requesting a new client certificate fail validation. Jamf does not deploy the CA certificate to devices, and Workspace ONE uploads it for chain-building without pinning, so neither is affected the same way.

The updated process exists to remove this failure by letting Intune configurations move to the renewed CA alongside the existing one, rather than switching in place.

How is the correct renewal process determined?

The configuration of the organization determines the required process. Process A applies to organizations without the renewal enhancement. Process B applies to organizations with the renewal enhancement. Contact Okta Support for assistance in determining which process applies.

Process A outlines the Admin Console steps for organizations without the renewal enhancement.

Download the latest Okta CA, upload it to the MDM solution, and activate the new Okta CA in Okta by following these steps.

1. In the Okta Admin Console, navigate to Security > Device Integrations.

2. Select the Certificate authority tab.

3. In the Actions column for the Okta CA, select the Download x509 certificate icon.

4. Rename the downloaded file to include a .cer extension.

5. Upload the renewed certificate to the MDM solution. NOTE: Do not remove the previous CA from the MDM until all managed devices hold a client certificate issued by the renewed CA.

6. Activate the new CA in Okta by selecting Activate in the Actions column for the Okta CA. NOTE: If administrators take no action, Okta activates the renewed CA automatically about six months after creation, roughly a year before the previous CA expires. If the MDM has not been updated by then, new client certificates cannot be issued from that point on. Activate as soon as the MDM upload is confirmed rather than waiting.

Process B outlines the updated API steps for organizations with the renewal enhancement.

Requirements
• An API token or OAuth 2.0 access token.
• Read calls: okta.certificateAuthorities.read scope.
• Renewal call: okta.certificateAuthorities.manage scope. Super Administrator or Organization Administrator only; others receive a 403.

IMPORTANT: Do not select Activate in the Admin Console during this process. It moves all SCEP configurations to the renewed CA at once and breaks enrollment for devices not yet migrated.
• If Activate was already selected, contact Okta Support. Do not renew again.
• If a renewed CA is already waiting for activation, the renewal call activates it for you.

How do administrators identify and download the renewed Certificate Authority?

Execute a GET request to identify the renewed CA and download the renewed certificate by following these steps.

1. Execute the following GET request to identify the renewed CA:

GET /pki/api/v2/certificate-authorities?type=INTERMEDIATE&expand=certificates

2. Each authority lists its certificates under _embedded.certificates. Locate the certificate whose rotationState is ACTIVE. This is the renewed certificate to deploy. The certificate marked RETIRING is being phased out but remains valid until it expires.

3. Note the authorityInstanceId from the authority, and the ski from the certificate whose rotationState is ACTIVE.

4. Execute the following GET request to download the renewed CA certificate:

GET/pki/api/v2/certificate-authorities/{authorityInstanceId}/certificates/{ski}/download

Optional parameters: format=pem (default) or format=der, and include=chain to return the renewed certificate plus its issuing root. include=chain cannot be combined with format=der. Use include=chain if the MDM expects the full chain.

The configuration type determines the migration strategy for each Simple Certificate Enrollment Protocol configuration.

Review the Simple Certificate Enrollment Protocol (SCEP) configurations in the Admin Console by navigating to Security > Device Integrations > Certificate configuration. Alternatively, execute the following GET request:

GET /pki/api/v2/certificate-authorities/{authorityInstanceId}/registration-authorities

The renewal call identifies each configuration by its raId. This is the ID field in this response, and also the last path segment of the configuration's SCEP URL (/pki/{authorityInstanceId}/scep/{raId}).

The configuration type determines the migration strategy.

The Intune type is labeled "Dynamic SCEP URL" in the console, but its challenge type is DELEGATED, not DYNAMIC. The "(delegated SCEP)" suffix is what distinguishes it.

Rollover: Switches the configuration to the renewed CA in place. The SCEP URL does not change.
Parallel: Creates a second configuration on the renewed CA alongside the original, so devices can migrate gradually.

• Microsoft Intune: Use parallel. Rollover causes certificate validation failures.
• Jamf and VMware Workspace ONE: Use rollover. For Workspace ONE, update the Credentials payload and confirm with VMware whether it validates against a locally deployed CA certificate.
• Other MDMs: If the MDM validates against a locally deployed CA certificate, use parallel.

NOTE: Parallel is available only for DELEGATED configurations. In the console, Intune appears as "Dynamic SCEP URL - Microsoft Intune (delegated SCEP)". Strategies can be combined in one request.

The renewal requires a POST request and updates to the Mobile Device Management profiles.

Upload the certificate to Microsoft Intune, execute the renewal POST request, create the new SCEP profile, and retire the old configuration by following these steps.

1. For parallel configurations, create a new Trusted Certificate Profile in Microsoft Intune and upload the downloaded certificate. NOTE: Do not modify the existing Trusted Certificate Profile or SCEP profile.

2. Execute the following POST request to renew the CA:

POST /pki/api/v2/certificate-authorities/{authorityInstanceId}/renew

{

  "rolloverConfigIds": ["<raId>", "<raId>"],

  "parallelConfigs": [

    {

      "sourceConfigId": "<raId>",

      "protocol": "SCEP",

      "challengeType": "DELEGATED",

      "name": "Intune Windows (renewed CA)"

    }

  ]

}

Each parallel entry requires sourceConfigId, protocol SCEP, and challengeType DELEGATED. Supply a name; renewal does not generate a default, and the name is what distinguishes the two live configurations in the Admin Console. The new configuration inherits its Intune connection settings, including the client secret, from sourceConfigId. Send configInfo only to change a setting. A request that names no configuration is rejected.

Rolled-over configurations are live on the renewed CA as soon as this call returns. No further action is needed for them.

3. For parallel configurations, create a new SCEP profile in Microsoft Intune using the scepUrl from the API response and link it to the new Trusted Certificate Profile. Copy the scepUrl exactly. It differs from the existing URL only in the last path segment, so it is easy to transcribe the old value by mistake. It can also be copied from Security > Device Integrations > Certificate configuration. Leave the existing profiles in place and unmodified.

4. Assign both profiles to the same device groups as the existing profiles.

5. Devices request a new client certificate the next time they check in. Devices must be powered on, and SCEP enrollment is rate limited. Track re-enrollment through the MDM's certificate reporting before retiring the old profiles.

6. Once every device receives a client certificate from the renewed CA, delete the old SCEP profile and old Trusted Certificate Profile in Microsoft Intune.

7. Optional: Delete the old SCEP configuration in Okta by executing the following DELETE request:

DELETE /api/v1/certificateAuthorities/{authorityInstanceId}/registrationAuthorities/{raId}

This deletes the SCEP configuration only. It becomes inert once the previous CA expires. The previous CA itself cannot be deleted.

Frequently Asked Questions

What happens if administrators take no action?

The previous CA remains valid and existing client certificates continue functioning until expiration. If administrators do not update the MDM by the expiration date, devices cannot obtain new client certificates and lose access to Okta-protected resources. For Process A, the effective deadline is earlier: Okta auto-activates the renewed CA about six months after creation, and new client certificates stop being issued at that point if the MDM has not been updated.

Will the renewed Certificate Authority activate on its own?

For organizations using Process A, Okta activates the renewed CA automatically about six months after creation. For organizations using Process B, there is no activation step and nothing auto-activates.

Are both Certificate Authorities valid at the same time?

Existing client certificates continue authenticating during the migration. Once the previous CA expires, devices can no longer use certificates issued by it to sign in.

Can the previous Certificate Authority be deleted from Okta?

Administrators cannot delete a CA from Okta. The previous CA remains in place until the expiration date. Okta chain validation rejects certificates issued by the expired CA. Administrators must remove the previous CA certificate from the MDM only after every managed device holds a client certificate issued by the renewed CA. Removing it earlier can prevent managed devices from reaching Okta-protected resources. The deadline is the previous CA's expiration date, normally up to 18 months after the renewed CA was created. Read the exact date from the previous certificate rather than calculating it. After that date, affected devices are treated as unmanaged until they re-enroll.

What happens if the renewal call is retried and returns 409 Conflict?

The renewal already succeeded. Each SCEP configuration can be migrated onto a renewed CA only once, so a repeat call is rejected. For a parallel migration, the error names the configuration that was already created. Look it up with GET /pki/api/v2/certificate-authorities/{authorityInstanceId}/registration-authorities and read its scepUrl there. Do not call renew again.

Why cannot Jamf or Workspace ONE configurations use the parallel strategy?

Parallel migration currently works only for SCEP configurations with a DELEGATED challenge type. Jamf and Workspace ONE use static or dynamic challenges and do not need parallel migration: rollover keeps the same SCEP URL, so no MDM profile changes are required.