Use certificates for authentication in Microsoft Intune
Use certificates with Intune to authenticate your users to applications and corporate resources through VPN, Wi-Fi, or email profiles. When you use certificates to authenticate these connections, your end users don't need to enter usernames and passwords, which can make their access seamless. Certificates are also used for signing and encryption of email using S/MIME.
Introduction to certificates with Intune
Certificates provide authenticated access without delay through the following two phases:
- Authentication phase: The user’s authenticity is checked to confirm the user is who they claim to be.
- Authorization phase: The user is subjected to conditions for which a determination is made on whether the user should be given access.
Typical use scenarios for certificates include:
- Network authentication (for example, 802.1x) with device or user certs
- Authenticating with VPN servers using device or user certs
- Signing e-mail based on user certs
Intune supports Simple Certificate Enrollment Protocol (SCEP), Public Key Cryptography Standards (PKCS), and imported PKCS certificates as methods to provision certificates on devices. The different provisioning methods have different requirements, and results. For example:
- SCEP provisions certificates that are unique to each request for the certificate.
- PKCS provisions each device with a unique certificate.
- With Imported PKCS, you can deploy the same certificate that you’ve exported from a source, like an email server, to multiple recipients. This shared certificate is useful to ensure all your users or devices can then decrypt emails that were encrypted by that certificate.
To provision a user or device with a specific type of certificate, Intune uses a certificate profile.
In addition to the three certificate types and provisioning methods, you need a trusted root certificate from a trusted Certification Authority (CA). The CA can be an on-premises Microsoft Certification Authority, or a third-party Certification Authority. The trusted root certificate establishes a trust from the device to your root or intermediate (issuing) CA from which the other certificates are issued. To deploy this certificate, you use the trusted certificate profile, and deploy it to the same devices and users that receive the certificate profiles for SCEP, PKCS, and imported PKCS.
Tip
Intune also supports use of Derived credentials for environments that require use of smartcards.
What’s required to use certificates
- A Certification Authority. Your CA is the source of trust that the certificates reference for authentication. You can use a Microsoft CA or a third-party CA.
- On-premises infrastructure. The infrastructure you require depends on the certificate types you use:
- A trusted root certificate. Before you deploy SCEP or PKCS certificate profiles, deploy the trusted root certificate from your CA using a trusted certificate profile. This profile helps establish the trust from the device back to the CA and is required by the other certificate profiles.
With a trusted root certificate deployed, you're ready to deploy certificate profiles to provision users and devices with certificates for authentication.
Which certificate profile to use
The following comparisons aren’t comprehensive but intended to help distinguish the use of the different certificate profile types.
| Profile type | Details |
|---|---|
| Trusted certificate | Use to deploy the public key (certificate) from a root CA or intermediary CA to users and devices to establish a trust back to the source CA. Other certificate profiles require the trusted certificate profile and its root certificate. |
| SCEP certificate | Deploys a template for a certificate request to users and devices. Each certificate that’s provisioned using SCEP is unique and tied to the user or device that requests the certificate. With SCEP, you can deploy certificates to devices that lack a user affinity, including use of SCEP to provision a certificate on KIOSK or user-less device. |
| PKCS certificate | Deploys a template for a certificate request that specifies a certificate type of either user or device. - Requests for a certificate type of user always require user affinity. When deployed to a user, each of the user’s devices receives a unique certificate. When deployed to a device with a user, that user is associated with the certificate for that device. When deployed to a userless device, no certificate is provisioned. - Templates with a certificate type of device don’t require user affinity to provision a certificate. Deployment to a device provisions the device. Deployment to a user provisions the device the user is signed into with a certificate. |
| PKCS imported certificate | Deploys a single certificate to multiple devices and users, which supports scenarios like S/MIME signing and encryption. For example, by deploying the same certificate to each device, each device can decrypt email received from that same email server. Other certificate deployment methods are insufficient for this scenario, as SCEP creates a unique certificate for each request, and PKCS associates a different certificate for each user, with different users receiving different certificates. |
Intune supported certificates and usage
| Type | Authentication | S/MIME Signing | S/MIME encryption |
|---|---|---|---|
| Public Key Cryptography Standards (PKCS) imported certificate |  |
|
|
| PKCS#12 (or PFX) | |
|
|
| Simple Certificate Enrollment Protocol (SCEP) | |
|
To deploy these certificates, create and assign certificate profiles to devices.
Each individual certificate profile you create supports a single platform. For example, if you use PKCS certificates, you create PKCS certificate profile for Android and a separate PKCS certificate profile for iOS/iPadOS. If you also use SCEP certificates for those two platforms, you create a SCEP certificate profile for Android, and another for iOS/iPadOS.
General considerations when you use a Microsoft Certification Authority
When you use a Microsoft Certification Authority (CA):
To use SCEP certificate profiles:
To use PKCS certificate profiles:
To use PKCS imported certificates:
- Install the Certificate Connector for Microsoft Intune.
- Export certificates from the certification authority and then import them to Microsoft Intune. See the PFXImport PowerShell project.
Deploy certificates by using the following mechanisms:
- Trusted certificate profiles to deploy the Trusted Root CA certificate from your root or intermediate (issuing) CA to devices
- SCEP certificate profiles
- PKCS certificate profiles
- PKCS imported certificate profiles
General considerations when you use a third-party Certification Authority
When you use a third-party (non-Microsoft) Certification Authority (CA):
SCEP certificate profiles don't require use of the Microsoft Intune Certificate Connector. Instead, the third-party CA handles the certificate issuance and management directly. To use SCEP certificate profiles without the Intune Certificate Connector:
- Configure integration with a third-party CA from one of our supported partners. Setup includes following the instructions from the third-party CA to complete integration of their CA with Intune.
- Create an application in Microsoft Entra ID that delegates rights to Intune to do SCEP certificate challenge validation.
For more information, see Set up third-party CA integration
PKCS imported certificates require use of the Microsoft Intune Certificate Connector. See Install the Certificate Connector for Microsoft Intune.
Deploy certificates by using the following mechanisms:
- Trusted certificate profiles to deploy the Trusted Root CA certificate from your root or intermediate (issuing) CA to devices
- SCEP certificate profiles
- PKCS certificate profiles (only supported with the Digicert PKI Platform)
- PKCS imported certificate profiles
Supported platforms and certificate profiles
| Platform | Trusted certificate profile | PKCS certificate profile | SCEP certificate profile | PKCS imported certificate profile |
|---|---|---|---|---|
| Android device administrator | (see Note 1) |
|
|
|
| Android Enterprise - Fully Managed (Device Owner) |
|
|
|
|
| Android Enterprise - Dedicated (Device Owner) |
|
|
|
|
| Android Enterprise - Corporate-Owned Work Profile |
|
|
|
|
| Android Enterprise - Personally-Owned Work Profile |
|
|
|
|
| Android (AOSP) | |
|
|
|
| iOS/iPadOS | |
|
|
|
| macOS | |
|
|
|
| Windows 8.1 and later | |
|
||
| Windows 10/11 | (see Note 2) |
(see Note 2) |
(see Note 2) |
|
- Note 1 - Beginning with Android 11, trusted certificate profiles can no longer install the trusted root certificate on devices that are enrolled as Android device administrator. This limitation doesn't apply to Samsung Knox. For more information, see Trusted certificate profiles for Android device administrator.
- Note 2 - This profile is supported for Windows Enterprise multi-session remote desktops.
Important
On October 22, 2022, Microsoft Intune ended support for devices running Windows 8.1. Technical assistance and automatic updates on these devices aren't available.
If you currently use Windows 8.1, then move to Windows 10/11 devices. Microsoft Intune has built-in security and device features that manage Windows 10/11 client devices.
Important
Microsoft Intune is ending support for Android device administrator management on devices with access to Google Mobile Services (GMS) on December 31, 2024. After that date, device enrollment, technical support, bug fixes, and security fixes will be unavailable. If you currently use device administrator management, we recommend switching to another Android management option in Intune before support ends. For more information, see Ending support for Android device administrator on GMS devices.
Related content
More resources:
Create certificate profiles:
- Configure a trusted certificate profile
- Configure infrastructure to support SCEP certificates with Intune
- Configure and manage PKCS certificates with Intune
- Create a PKCS imported certificate profile
Learn about the Certificate Connector for Microsoft Intune