Streamlining Windows Admin Recovery with Okta Device Access and Intune Integration

August 2025: This is an Early Access release

Introduction

In today’s interconnected enterprise landscape, robust identity and access management (IAM) is no longer a luxury but a fundamental pillar of cybersecurity.
As organizations increasingly adopt cloud-first strategies and embrace a distributed workforce, securing endpoints, particularly Windows devices, becomes paramount. Okta Device Access significantly extends Okta’s powerful IAM capabilities directly to the device sign-in experience, enabling features like Desktop MFA and passwordless login.
While these advancements offer unparalleled convenience and security, they also introduce a critical consideration: how do administrators regain access to a Windows device when traditional authentication methods fail or are compromised?

This technical blog post will meticulously explore the intricacies of Okta Device Access Admin Recovery for Windows.
We will peel back the layers of the recovery mechanisms, dissecting the underlying architecture and the various scenarios that necessitate an administrator-led recovery.
The complete process typically involves several key stages:

1. Initial User Lockout and “Contact Administrator” Prompt: When a user is unable to sign in due to forgotten credentials, lost MFA device, or policy lockout, the Windows login screen will often direct them to contact their IT administrator.
   
2. Generating a Device Recovery PIN: For Windows devices, the administrator can generate a time-limited device recovery PIN from the Okta Admin Console.
   This PIN is a temporary credential designed to grant emergency access.
   
3. PIN Provisioning and User Access: The recovery PIN is then securely provided to the user, who enters it at the Windows login screen. This grants temporary access to the device. The PIN typically has a short validity period (e.g., two minutes for initial entry, then a longer duration once successfully used).
   

Requirements

This blog post will serve as a comprehensive guide to deploying and configuring
Okta Device Access Windows Admin Recovery using Microsoft Intune.

Below are the key requirements to ensure a successful implementation.

Okta Requirements

• An Okta Tenant (OIE) with administrator access.
• A valid subscription to enforce Okta Device Access Desktop.
• Okta Device Access Configuration Complete
  To continue with securing your environment, explore my in-depth guide on deploying Desktop MFA using Microsoft Intune.
• Okta Verify 6. or higher distributed on Windows devices

Microsoft Intune Requirements

• Microsoft Intune Subscription
• Necessary permissions to create and manage Intune app deployments, configuration profiles, and PowerShell scripts.
• Devices must be Azure AD-joined, Hybrid AD-joined or AD-joined for proper policy enforcement.

Demo – Windows Admin Recovery

To start, let’s walk through a demonstration of Windows Admin Recovery.

The user has to login once using Desktop MFA to get device enroll for Admin recovery.

Enable Desktop MFA recovery

After you enable Desktop MFA recovery, admins with the appropriate permissions can generate a recovery PIN that they can share with the user. If the user doesn’t enter the correct recovery PIN within the two-minute time limit, the PIN expires and a new one must be generated.

Configuring Desktop MFA recovery for Windows requires you to enable a security setting in the Admin Console.

In the Admin Console, go to Security > General.

Scroll to the Okta Device Access section, click Edit and select Enabled from the dropdown menu, to enable Device Recovery PIN for Desktop MFA.

 Desktop MFA access policies

Within the Windows Admin Recovery feature, two new policy configurations must be deployed to managed devices to support secure recovery workflows:

• DeviceRecoveryPINDuration – Valid time period for a device recovery PIN after activation
• DeviceRecoveryValidityInDays – Duration of the device recovery window for Desktop MFA

These settings are essential for controlling the time-bound behavior of recovery operations and ensuring alignment with your organization’s security policies.
I’ve covered the policy deployment in one of my previous blog posts.

Group Policy-Based Deployment of Desktop MFA for Windows

If you’re interested in deploying Desktop MFA policies using a Group Policy-based approach, refer to the following Knowledge Base article.
It includes instructions and provides the downloadable ADMX and ADML files required for configuration.

Overall the deployment is super easy on, in the Intune Admin Center navigate to

1. Devices and select Configuration
2. Click on the Import ADMX tab

Upload the files:

1. Click “Browse” or drag and drop your Okta.admx file
2. Click “Browse” or drag and drop your corresponding Okta.adml file
3. Click Next

Repeat the above steps to import OktaODA.admx ADMX and OktaODA.adml ADML file.

Review and create the Devices Configurations.

At this point, the imported ADMX templates should appear in the Intune console, ready for use.

Following the successful import of the ADMX/ADML files, a configuration profile can be created to apply these settings across your managed endpoints.

The next steps to create a configuration profile to deploy these settings by navigating to Devices > Manage Devices > Configuration

1. Click Create -> New Policy.
2. Platform: Select Windows 10 and later
3. Profile type: Select Templates
4. In the template list
5. choose Imported Administrative templates (Preview)
6. Click Create

Provide a name for the profile and click Next.

The settings defined in your ADMX file will be displayed, categorized as
“All Settings”, “Computer Configuration”, “User Configuration.
Browse to “Computer Configuration” and “Okta”, “Okta Device Access” to configure.

For each setting:

1. Select the setting
2. Choose Enabled, Disabled, or Not Configured
3. If Enabled, configure any associated values
4. Click OK

Click Next after configuring all desired settings.

Select the Azure AD user or device groups to which this policy should apply.

Review all the settings and assignments and click Create to deploy the profile.

Configure Okta as a CA with delegated SCEP challenge for Microsoft Intune

This section outlines a step-by-step process for configuring Okta as the Certificate Authority (CA) with delegated SCEP, integrated with Microsoft Intune as the MDM solution.

Register the AAD app credentials for Okta in Microsoft Entra

In Microsoft Entra admin center, click App registrations, click + New registration.

On the Register an application page, enter the following:

1. Name: Enter a name for the application.
2. Supported account types: Select the appropriate supported account type. Okta tested with Accounts in this organizational directory only ([Your_Tenant_Name] only – Single tenant) selected.
3. Click Register

On the app page under Essentials, copy and make a note of the Application (client) ID.

Now wee need to add a client secret, so in the left pane

1. Click Certificates & secrets.
2. Under Client secrets, click + New client secret
3. Description: Optional. Enter a description for the client secret.
4. Expires: Select an expiration time period.
5. Click Add

The secret appears under Client secrets, copy and make a note of the Value.

Set the Intune permissions for SCEP

In the next step we need to configure the Intune scep_challenge_provider permissions.

1. In the left pane, click API permissions.
2. In the Request API permissions section, scroll down, and then click Intune

Under What type of permissions does your application require?, click Application permissions.
In the Select permissions search field, enter scep, and then select the scep_challenge_provider checkbox
Click Add permissions to finish the configuration.

In the Configured permissions section, click Grant admin consent for [Your_Tenant_Name].

Click Yes in the message that appears.

You should see the following output.

Set the Microsoft Graph permissions

Click + Add a permission.
In the Request API permissions section, click Microsoft Graph

Under What type of permissions does your application require?
click Application permissions.
In the Select permissions search field, enter application, expand Application, and then select the Application.Read.All checkbox

Click Add permissions.

In the Configured permissions section, click Grant admin consent for [Your_Tenant_Name].
Click Yes in the message that appears.

The API permissions should appear as follows.

Implement the SCEP configuration in Okta

In the Okta Admin Console, go to Security –> Device integrations

Click the Devices Access  tab and click Add SCEP configuration

SCEP URL challenge type: Select Dynamic SCEP URL, and then select Microsoft Intune (delegated SCEP).
Enter the values that you copied from Microsoft Azure into the following fields:

1. Select Dynamic SCEP URL
2. Select Microsoft Intune (delegated SCEP)
3. AAD client ID: Enter the value you copied from the previous tasks.
4. AAD tenant: Enter your AAD tenant name followed by your Azure tenant
5. AAD secret: Enter the secret Value you copied from previous tasks.
6. Click Generate

Make sure to copy and retain the Okta SCEP URL, as it will be used in a later step within the Microsoft Intune admin center and Save your configuration.

Download the x509 certificate from Okta

“In the Device Integration configuration section, navigate to the Certificate Authority tab and click the Download X.509 Certificate icon.

Rename the downloaded file, so that it includes a .cer extension.

Create a Trusted Certificate configuration in Microsoft Intune

In the Microsoft Intune admin center:

1. Navigate to Devices / Configurations
2. Click + Create / New Policy
3. Platform: Select Windows 10 and later
4. Profile type: Select Templates
5. Search for the Trusted certificate template
6. In the Template name section, click Trusted certificate
7. Click Create

On the Trusted Certificate page, under the Basics tab, configure the following settings:

1. Name: Enter a name for the policy
2. Click Next

On the Trusted certificate page Configuration settings tab, Certificate file: Select the
x509 certificate (CER file) that you downloaded from the Okta admin console.

…

1. select Computer certificate store – Intermediate as the Destination store
2. Click Next after the certificate was successfully uploaded

Assign the profile to your desired groups.

Review and create the Configuration.

Create a SCEP profile in Intune

Navigate to

1. Navigate to Devices / Configurations
2. Click + Create / New Policy
3. Platform: Select Windows 10 and later
4. Profile type: Select Templates
5. Search for SCEP
6. In the Template name section, click SCEP certificate
7. Click Create

On the SCEP certificate page Basics tab, do the following

1. Name: Enter a name for the configuratio
2. Click Next

On the SCEP Certificate page, under the Configuration Settings tab, complete the following steps

1. Certificate type: Select Device
2. Subject name format: Enter a subject name.
   For example, CN=ODA {{DeviceId}}
3. Certificate validity period: Select Years in the list, and then enter 1 in the next field.
4. Select your desired Key storage provider
5. Key usage: Select Digital signature.
6. Key size (bits): Select 2048
7. Select your desired Hash algorithm
8. Click + Root Certificate select the trusted certificate that you created earlier
9. Select the Root Certificate that was previously created
10. Click OK

Move forward with the setup process:

1. Under Extended key usage, set Predefined values to Client Authentication
2. SCEP Server URLs: Enter the SCEP URL generated in the Okta admin console
3. Click Next.

assign this profile to your desired groups.

Review and create the Configuration.

Ensure that all profiles were created as expected.

Confirm Successful Certificate Deployment

After completing the SCEP configuration and certificate issuance process, it is essential to verify that the certificates have been successfully deployed on the target device.
Proper validation ensures the integrity of your certificate infrastructure and the smooth operation of secure communications.

Verifying the SCEP Certificate in the Local Personal Device Store

The SCEP (Simple Certificate Enrollment Protocol) certificate should be installed in the device’s Local Personal certificate store.
This certificate enables the device to authenticate securely within your network environment.

Verifying the Root Certificate in the Intermediate Certificate Authorities Store

The Root Certificate Authority (CA) certificate must be trusted by the device, so it should be present in the Intermediate Certification Authorities store.
This placement ensures the device trusts the certificate chain used for secure communication.

Verify Certificate Deployment in Okta

Within the Okta System Log, you should observe a record confirming the successful provisioning of the client certificate to the target device

The Okta Identity Service on the device periodically evaluates whether a device is eligible for registration and possesses a valid client certificate.
When a certificate is detected, its validity is verified against the Root CA certificate uploaded in the Okta admin console.

Upon successful validation, the service creates a registry entry with the key DevicePrincipalId under the path:

Once the device registration process completes successfully in Okta.