Skip to main content

Windows User SCEP Policy (Agent-based)

Updated yesterday

The Windows User SCEP Policy (Agent-based) uses the Swif agent (not the Windows MDM CSP) to enroll and install an SCEP certificate into the signed‑in user’s certificate store (CurrentUser\My). The policy is evaluated per user session, so each logged‑in user can obtain their own SCEP certificate.

This is typically used for user‑based certificate scenarios, such as Okta Verify FastPass, that need to see a certificate in the current user store.

If you instead need to install an SCEP certificate in the device (machine) certificate store, use the Windows Device SCEP Policy (CSP-based).

When to Use This Policy

Use Windows User SCEP Policy (Agent-based) when:

  • You need a user certificate (CurrentUser store), not a machine certificate.

  • Apps like Okta Verify, browsers, or VPN clients must read the certificate from the current user’s certificate store.

  • You want the certificate to follow the logged‑in user (for example, shared devices with multiple users).

  • You do not want to use the Windows ClientCertificateInstall CSP or device‑level SCEP.

Common scenarios:

  • Okta Device Identity / FastPass requires a user certificate in Cert:\CurrentUser\My.

  • User‑based certificate authentication for SSO, Wi‑Fi, VPN, or Zero‑Trust workflows where the app expects a user certificate.

If your use case is specifically to identify the device regardless of who is signed in (Wi‑Fi EAP‑TLS with device certs, VPN with machine certs, etc.), configure the Windows Device SCEP Policy (CSP-based) instead.

How It Works

  1. The Swif agent on Windows evaluates the Windows User SCEP Policy (Agent-based) for the current session.

  2. The agent contacts the Swif server, which:

    • Connects to the configured SCEP server (Okta or another SCEP CA).

    • Generates the enrollment key pair and requests a client certificate.

  3. Once enrollment succeeds, the Swif agent installs the certificate into the signed‑in user’s certificate store:

    • Store: CurrentUser\My

  4. On subsequent runs, the policy:

    • Checks for an existing certificate in the user store that matches the configured Subject Name.

    • Can re‑enroll or refresh as needed based on your configuration and SCEP server behavior.

This policy does not use the Windows MDM ClientCertificateInstall CSP. If you need CSP‑based enrollment into the device store, use the Windows Device SCEP Policy (CSP-based).

Requirements

  • Operating system: Windows 10 or later

  • Swif agent installed and enrolled on the device

  • An accessible SCEP server, such as:

    • Okta Device Identity SCEP

    • Microsoft NDES / Intune SCEP

    • Cisco ISE

    • EJBCA, JAMF, or any RFC‑compliant SCEP CA

  • SCEP server details (URL, challenge/password, and subject configuration)

This policy supports both company‑owned and BYOD Windows devices, as long as the Swif agent is installed.

Policy Fields

Below are the available fields in Windows User SCEP Policy (Agent-based) and how to configure them.

1. SCEP Name (scepName)

  • Display name: SCEP Name

  • Description: Optional label to identify this policy in the Swif admin console.

  • Type: String

  • Default: UserSCEP

  • Minimum OS: Windows 10+

Usage tip:
Use a clear name that reflects the SCEP usage, for example:

  • Okta User SCEP

  • User SCEP – Finance

  • User SCEP – VPN

This is for admin readability only and does not affect enrollment behavior.

2. Server URL (serverURL)

  • Display name: Server URL

  • Description: SCEP enrollment URL (for example, the Okta SCEP endpoint).

  • Type: URL

  • Required: Yes (for successful enrollment)

  • Default: Empty

  • Minimum OS: Windows 10+

Examples:

This is the endpoint the Swif server will contact to request the user certificate.

You obtain this value from your SCEP provider (Okta, NDES, etc.). For Okta, the SCEP URL is available in the Okta Device Identity / SCEP configuration.

3. Challenge (challenge)

  • Display name: Challenge

  • Description: Static or configured SCEP challenge password.

  • Type: String

  • Required: Yes (unless the SCEP server is configured without a challenge)

  • Default: Empty

  • Minimum OS: Windows 10+

This is the shared secret or challenge password used by the SCEP server to authorize certificate enrollment.

  • Obtain this from your SCEP provider (for example, Okta’s SCEP integration).

  • Treat it as a secret: only admins should see this value.

4. Subject Name (subjectName)

  • Display name: Subject Name

  • Description: Certificate subject (for example, CN=user@company.com). Used to detect an existing certificate in the user store.

  • Type: String

  • Default: Empty

  • Minimum OS: Windows 10+

This field controls the Subject of the issued certificate and is also used by Swif to look up an existing certificate in CurrentUser\My.

Examples:

Your SCEP provider’s documentation will specify what values or placeholders are supported. For Okta, you typically map it to a user identifier (like email/UPN).

Make sure this matches what your SCEP server expects. If you change the subject format after certificates have already been issued, Swif may treat previously installed certificates as non‑matching.

5. Key Length (keyLength)

  • Display name: Key Length

  • Description: RSA key length for the enrollment key pair generated on the server.

  • Type: Integer (with labeled options)

  • Default: RSA – 2048

  • Supported values:

    • No value (use SCEP server defaults, if allowed)

    • RSA – 1024

    • RSA – 2048

    • RSA – 4096

  • Minimum OS: Windows 10+

Recommendations:

  • Use RSA 2048 for most deployments (modern security baseline).

  • Use RSA 4096 only if explicitly required by your security policy and supported by the SCEP server.

  • Avoid RSA 1024 in production unless you are constrained by legacy systems.

Behavior vs. Windows Device SCEP Policy (CSP-based)

There are two separate SCEP policy types in Swif for Windows:

  1. Windows User SCEP Policy (Agent-based) – this article

    • Uses the Swif agent to enroll and install the certificate.

    • Targets the current user certificate store (CurrentUser\My).

    • Good for Okta Verify FastPass and other user‑centric apps.

  2. Windows Device SCEP Policy (CSP-based)

    • Uses Windows CSP (ClientCertificateInstall).

    • Targets the device (machine) certificate store.

    • Applies to the machine, regardless of the logged‑in user.

    • Common for device identity in Wi‑Fi, VPN, and Zero‑Trust flows.

    • Documentation: Windows Device SCEP Policy (CSP-based)

If your requirement is:

  • “Certificate must be present for all users on the machine” → use Device SCEP Policy (CSP‑based).

  • “Certificate must be present for the logged‑in user only” → use Windows User SCEP Policy (Agent-based).

High‑Level Setup Flow (Example: Okta as SCEP CA)

Below is a typical flow when using Okta as the SCEP CA for user certificates:

  1. Configure Okta SCEP

    • In Okta, configure the Device Identity / SCEP integration.

    • Obtain:

      • SCEP Server URL

      • SCEP challenge/shared secret

      • Subject / SAN mapping rules, if applicable.

  2. Create Windows User SCEP Policy (Agent-based) in Swif

    • Go to your Windows policies in the Swif admin console.

    • Add Windows User SCEP Policy (Agent-based).

    • Configure:

      • SCEP Name: e.g., Okta User SCEP

      • Server URL: Okta SCEP endpoint

      • Challenge: Okta SCEP shared secret

      • Subject Name: e.g., CN={userPrincipalName} (or as required by Okta)

      • Key Length: typically RSA 2048

  3. Assign the Policy

    • Target relevant device groups or user‑based groups where the Swif agent is installed.

  4. User Enrollment

    • When a user signs into Windows and the Swif agent runs:

      • The agent triggers the user SCEP enrollment via the Swif server.

      • The returned certificate is installed in CurrentUser\My for that user.

  5. Application Usage

    • Apps like Okta Verify can now detect and use the certificate from the current user store for authentication.

Verification & Troubleshooting

Verify the Certificate in the User Store

On a Windows device where the policy applies, run PowerShell as the signed‑in user:

Get-ChildItem Cert:\CurrentUser\My |
  Where-Object { $_.Subject -like "*<expected-subject-part>*" } |
  Format-Table Subject, Thumbprint, NotAfter -AutoSize

Replace <expected-subject-part> with part of the Subject (for example, the user’s email).

You should see an entry matching your Subject Name configuration.

If the Certificate Is Not Present

  • Confirm the Windows User SCEP Policy (Agent-based) is assigned to the device/user.

  • Verify:

    • Server URL is reachable and correctly copied.

    • Challenge is valid and has not been rotated/expired.

    • Subject Name format matches what your SCEP server expects.

  • Check Swif agent logs on the device for TASK_USER_SCEP_CERTIFICATE or similar entries for enrollment status.

  • Confirm the user has an active network connection to reach the SCEP server.

Choosing Between User and Device SCEP Policies

Use this quick guide:

  • I need Okta Verify / user FastPass certs in the user store
    → Use Windows User SCEP Policy (Agent-based) (this article).

  • I need device identity for Wi‑Fi/VPN/Zero‑Trust (machine certs)
    → Use Windows Device SCEP Policy (CSP-based).

Related Articles
Configuring a Policy for RADIUS Wi-Fi on Windows
Configuring a Policy for Windows VPN with RADIUS + SCEP
Windows-specific MDM policies available in Swif
Install an SCEP Profile from Okta to Windows Devices
Windows Device SCEP Policy (CSP-based)
Did this answer your question?