Intune Certificate Profiles: SCEP, PKCS, NDES and the Full Architecture

Password-based authentication is a liability. When you deploy certificate-based authentication in Intune, devices and users prove their identity with a private key that never leaves the device — there is nothing to phish. But certificates are also one of the most complex areas of Intune to configure correctly. This guide walks through the full architecture: Root CA to NDES server to Intune Certificate Connector to SCEP or PKCS profiles, through to VPN, Wi-Fi, and email authentication — and what to do when it breaks.

The Architecture: How It All Connects

SCEP vs PKCS — Choosing the Right Certificate Type

Setting Up the Certificate Chain

Step 1 — Root CA Certificate Profile

Before you deploy SCEP or PKCS profiles, you must deploy the trusted root certificate to all managed devices. Without this, devices will not trust certificates issued by your internal CA.

Step 2 — NDES Server Configuration (SCEP only)

The Network Device Enrollment Service (NDES) acts as the Registration Authority — devices request certificates from NDES, which validates the request against a challenge password and forwards it to the CA. The Intune Certificate Connector is installed on the NDES server and brokers the communication with Intune.

# Run on the NDES server
Get-Service -Name "NDESConnectorSvc" | Select Name, Status
Get-Service -Name "AADConnectAgentUpdater" | Select Name, Status

# Check Connector logs
Get-ChildItem "C:\ProgramData\Microsoft\MicrosoftIntuneCertConnector\Logs" |
  Sort LastWriteTime -Desc | Select -First 5

Step 3 — SCEP Certificate Profile

After the Trusted Root profile and NDES/Connector are in place, create the SCEP profile. The critical settings are: Subject name format, SAN (Subject Alternative Name), Key usage, Extended key usage, and the SCEP server URL.

Lifecycle Management

Integration: Entra ID, Azure Key Vault, Defender

Troubleshooting

Check Connector Errors

# On the NDES/Connector server
$log = Get-ChildItem "C:\ProgramData\Microsoft\MicrosoftIntuneCertConnector\Logs" | Sort LastWriteTime -Desc | Select -First 1
Select-String -Path $log.FullName -Pattern "error|fail|exception" -CaseSensitive:$false | Select -Last 20

Verify Certificate Chain

# Check certificate store on managed device
Get-ChildItem Cert:\LocalMachine\My | Where {$_.Issuer -like "*YourCA*"} | Select Subject, Issuer, NotAfter, Thumbprint

# Verify chain builds to trusted root
$cert = Get-Item "Cert:\LocalMachine\My\"
$chain = New-Object Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)

Common failure patterns

Best Practices

• Use SCEP with NDES for device certificates — private key stays on the device
• Deploy the Trusted Root certificate profile before any SCEP or PKCS profile
• Set renewal threshold to 20% — gives enough runway for NDES outages without expiry
• Monitor certificate expiry with Intune Reports → Device configuration → Certificate expiry
• Store recovery keys securely — for PKCS, use Azure Key Vault; for SCEP, back up the CA private key offline
• Use Intune Certificate Connector v6.x (the unified connector, not the legacy NDES Connector)

Official References

• Use certificates for authentication in Microsoft Intune
• Configure infrastructure for SCEP certificates
• Configure and use PKCS certificates with Intune
• Certificate Connector for Microsoft Intune