Key Points
- Okta Device Access uses SCEP to deploy device certificates through your MDM to macOS and Windows endpoints.
- Three SCEP challenge types exist: static (shared secret), dynamic (per-device secret), and delegated (MDM-issued secret).
- Okta as a CA does not support certificate renewal; you must redistribute the SCEP profile before expiration.
- A managed cloud PKI replaces the renewal gap and adds identity-bound certificate issuance.
- Most teams miss these two configuration steps: required EKU OID and intermediate CA upload.
Phishing-resistant device trust is the bar Okta Device Access (ODA) raises for every IT team running an Okta tenant. The device proves itself with a certificate, and that certificate lands on the device through a SCEP profile that your mobile device management (MDM) solution pushes silently. Get the wiring right, and the user never sees a prompt; get it wrong, and you chase renewal failures and broken sign-ins.
This guide covers configuring Okta device access SCEP end-to-end: the three challenge types, the SCEP profile setup in the Okta admin console, the matching configuration in Intune, Jamf Pro, and Workspace ONE, and the cleaner path of pointing ODA at a managed cloud public key infrastructure (PKI).
What Is Okta Device Access SCEP?
Okta Device Access SCEP is the certificate enrollment workflow that issues a client certificate to a managed device so Okta can recognize the device on every sign-in. The Simple Certificate Enrollment Protocol (SCEP) carries the request from the device through your MDM to a certificate authority (CA), which signs and returns the certificate. Once installed, the certificate identifies the device to Okta during ODA-protected authentication.
The CA signs. The MDM pushes the SCEP profile. Okta consumes the certificate and ties device trust to user trust. You can use Okta as the CA, or plug in your existing PKI and keep Okta out of issuance.
SCEP Challenge Types in Okta
The challenge type controls how the device proves it is allowed to request a certificate. Okta supports three options; the right pick depends on which MDM you run and how strict your security model is.
Static SCEP
Static SCEP uses one shared secret across every device. You generate it in Okta, paste it into the SCEP profile in your MDM, and every enrolled device uses the same value. Setup is the simplest of the three; Workspace ONE on Windows defaults to this pattern.
The trade-off is risk: a leaked secret lets any device request a certificate. Rotate on a schedule and treat the secret like a service account credential.
Dynamic SCEP
Dynamic SCEP issues a unique, short-lived secret per device. The MDM coordinates with Okta to assign each device its own challenge value; the device redeems it for exactly one certificate, and the secret expires. Jamf Pro on macOS is the most common dynamic-SCEP deployment. Dynamic is the right default wherever a leaked static secret would matter.
Delegated SCEP
Delegated SCEP lets the MDM generate the per-device secret. With Microsoft Endpoint Manager (MEM, also called Intune), MEM creates and signs the secret per request, and Okta validates the signature before issuing. The MDM owns the secret lifecycle, which keeps provisioning in the same control plane as the rest of your Intune workflows.
Configure SCEP in Your MDM
The Okta-side configuration is the same regardless of challenge type. The differences live in the MDM profile, not the Okta URL.
- Open the Admin Console. Sign in as administrator and navigate to Security > Device integrations.
- Add the platform. On the Endpoint management tab, click Add platform and select Desktop (Windows and macOS).
- Add the SCEP configuration. Click Add SCEP configuration and pick Static, Dynamic, or Delegated.
- Generate the SCEP URL. Okta produces the URL and, for static challenges, the shared secret. Copy these for the MDM profile.
- Save. Confirm the configuration appears active in the Device integrations list.
Repeat for separate macOS and Windows profiles. Okta keeps them distinct, each with its own URL.
Configure SCEP in Your MDM
The Okta SCEP URL only works when an MDM profile pushes it to the device. Three patterns cover most deployments.
Intune (Microsoft Endpoint Manager) for Windows and macOS
Use delegated SCEP with Intune. In the Intune admin center:
- Create a SCEP certificate profile.
- Paste the Okta SCEP URL into the SCEP server URL field.
- Select device as the certificate type.
Set the subject name format to match what your Okta policy expects, and assign the profile to the Entra ID device groups your ODA policies target.
Jamf Pro for macOS
Use dynamic SCEP with Jamf Pro:
- Create a configuration profile.
- Add a Certificate payload.
- Paste the Okta SCEP URL.
- Set challenge type to dynamic.
Configure subject and key usage to match the EKU requirement, and scope to the Smart Group containing your managed Macs.
Workspace ONE for Windows
Workspace ONE typically uses static SCEP. In the Workspace ONE UEM console:
- Create a credential profile.
- Set source to SCEP.
- Paste the Okta SCEP URL and shared secret.
Push to your Windows device group and verify the certificate lands in the local machine certificate store.
For all three MDMs, validate that the pushed certificate carries the correct Extended Key Usage (EKU) value. A certificate without the Okta-required EKU fails ODA verification even when issuance succeeded.
Use Your Own Certificate Authority With Okta Device Access
Using Okta as a CA is convenient for a quick deployment, but two limitations push most production environments to plug in their own PKI:
- No renewal: Okta as a CA does not support SCEP renewal. You redistribute the profile before expiration to force re-enrollment, which adds overhead and risks outages.
- Limited identity binding: Certificates issued by Okta do not bind to user identity, group membership, or live MDM enrollment status. Your existing PKI can.
To use your own CA with ODA, three setup tasks are non-negotiable:
- Add the Okta-required EKU OID as an Application Policy on your CA. Okta uses this OID to identify ODA certificates and reject any other client cert.
- Upload the intermediate CA chain to the Okta admin console. PEM and DER are supported; PKCS#7, PKCS#12, and PFX are not.
- Point your MDM SCEP profile at your CA, not at Okta. Okta only validates the resulting certificate against the EKU and uploaded chain.
Validate the SCEP Enrollment
A SCEP rollout is not finished until you confirm three things on a real device:
- Certificate present: On macOS, check Keychain Access (System keychain). On Windows, check the Local Computer certificate store under Personal > Certificates.
- EKU correct: Inspect certificate properties and confirm the Okta-required Extended Key Usage value is present. A missing EKU is the top cause of ODA verification failures.
- Sign-in succeeds: Trigger an Okta sign-in with an ODA-protected app. The certificate should present automatically, and sign-in should complete without a prompt.
If any check fails, confirm the profile actually pushed, then check the chain in Okta, then verify the EKU. Most failures fall into one of those three categories.
How a Managed Cloud PKI Improves Okta Device Access
A cloud-managed PKI designed for Okta gives you the benefits of bringing your own CA without running Active Directory Certificate Services (ADCS), Network Device Enrollment Service (NDES), or a hardware CA. The right cloud PKI handles three things the Okta-as-a-CA path leaves unsolved:
- Automatic renewal: Devices renew before expiration without admin intervention, so the redistribute-the-profile cycle disappears.
- Identity-bound issuance: Each request is evaluated against live user identity, group membership, and MDM compliance, so the cert represents user and device at issuance.
- Auditability: Every issuance, renewal, and revocation lands in one log tying device, user, and policy together, which is the audit trail SOC 2 and ISO 27001 reviewers ask for.
JoinNow Dynamic PKI is the SecureW2 implementation. It integrates with Okta as the identity source, hands certificates to Intune, Jamf Pro, and Workspace ONE through SCEP, and supports the EKU and chain requirements ODA enforces. Teams already running JoinNow Cloud RADIUS for Wi-Fi can have the same certificate do double duty for ODA and 802.1X authentication.
Schedule a demo to see how SecureW2 connects to your Okta tenant, your MDM, and your devices in one configuration pass.
Frequently Asked Questions
What is Okta Device Access?
Okta Device Access ties device trust to user authentication. A managed device must present a valid client certificate during sign-in for ODA-protected applications, preventing access from unmanaged or untrusted devices.
How does SCEP work with Okta?
SCEP carries a certificate signing request from the device through the MDM to a CA. Okta acts as the CA (or validates against an external CA), signs the certificate, and the MDM installs it. Okta consumes that certificate during ODA-protected sign-ins.
What is the difference between static, dynamic, and delegated SCEP challenges?
Static uses one shared secret for all devices. Dynamic issues a unique short-lived secret per device. Delegated lets the MDM generate the secret per request, and Okta validates it. Static is the simplest; dynamic and delegated are stronger.
Can I use my own certificate authority with Okta Device Access?
Yes. Upload your intermediate CA chain to Okta, add the Okta-required EKU OID as an Application Policy on your CA, and configure your MDM SCEP profile to point at your CA instead of at Okta.
Does Okta Device Access support certificate renewal?
Okta as a CA does not support SCEP renewal. You must redistribute the profile before expiration. A managed cloud PKI, such as JoinNow Dynamic PKI, handles renewal automatically.
Which MDMs work with Okta Device Access SCEP?
Okta documents support for Microsoft Intune (delegated SCEP) on Windows and macOS, Jamf Pro (dynamic SCEP) on macOS, and Workspace ONE (static SCEP) on Windows. Other MDMs supporting standard SCEP profiles can be configured against the same Okta SCEP URL.
