PKIaaS for Hybrid Workforce Authentication

The hybrid workforce has fundamentally changed the authentication problem. When all employees worked from a corporate office on managed laptops connected to a corporate network, a password checked against Active Directory was a reasonable authentication mechanism: the network location provided implicit trust, and the corporate perimeter enforced who could reach the authentication endpoint at all. That model no longer describes how most organizations operate. Users authenticate from home broadband, hotel Wi-Fi, coffee shop networks, and cellular connections. Devices range from corporate-managed laptops with full MDM enrollment to personal phones accessing corporate email under a BYOD policy. Network perimeters have been replaced by identity as the control plane.

In this environment, passwords and OTP tokens are not sufficient authentication mechanisms. Passwords are phishable, reusable across services, and dependent on the user entering the correct credential at every authentication event. Certificates are not. A certificate cannot be phished because the private key never leaves the device. A certificate cannot be reused across unauthorized services because each authentication event proves possession of the private key without transmitting it. A certificate authenticates silently once enrolled, without user interaction, regardless of the user’s network location. PKI as a Service provides the certificate authority infrastructure that issues, manages, and revokes these certificates at workforce scale, integrated with the MDM platforms and identity providers that IAM and infrastructure teams already operate.

Quick Answer: What Does PKIaaS Provide for Hybrid Workforce Authentication?

PKIaaS provides the governed CA backend that issues certificates for every workforce authentication use case: user authentication certificates for VPN and Wi-Fi 802.1X via EAP-TLS, device authentication certificates for managed endpoints on corporate network segments, S/MIME certificates for signed and encrypted email, and smart card logon certificates for high-security physical and logical access. The MDM platforms (Intune, Jamf, Workspace ONE) distribute these certificates to devices through SCEP or WSTEP enrollment, without requiring users to manually install anything. The CLM layer monitors certificate expiry and automates renewal so that certificates remain valid across the entire device fleet without certificate-related authentication failures.

Key Takeaways

• Certificate-based authentication via EAP-TLS is the only phishing-resistant authentication mechanism that works for VPN, Wi-Fi 802.1X, and network access control without requiring a password or OTP token at each authentication event. The private key never leaves the device; authentication proves key possession without transmitting a secret.
• PKIaaS integrates with Microsoft Intune, Jamf, VMware Workspace ONE, Ivanti, and other MDM platforms through SCEP and WSTEP enrollment protocols, distributing certificates to Windows, macOS, iOS, and Android devices automatically as part of device enrollment and compliance profile assignment.
• S/MIME certificates from a PKIaaS CA provide email signing and encryption for the workforce without requiring a public CA’s involvement. The private PKIaaS CA issues S/MIME certificates with the Email Protection EKU and the user’s email address in the SAN, distributable through Intune, Jamf, or Active Directory Certificate Services autoenrollment.
• Smart card logon certificates issued by PKIaaS require the Smart Card Logon EKU and PKINIT support in the domain controller configuration. They provide the highest authentication assurance for privileged access and physical access control systems, with the private key stored in the smart card’s hardware cryptographic module.
• WSTEP (Windows enrollment via Web Services Trust protocol) and Active Directory-based autoenrollment allow Windows domain-joined devices to receive user and device certificates from the PKIaaS CA automatically through Group Policy, without any user action or IT helpdesk involvement in the certificate distribution process.

Why Certificates Are the Right Authentication Layer for Hybrid Work

The authentication problem for hybrid workforces has two dimensions that passwords alone cannot address. The first is phishing resistance: passwords and TOTP tokens can be captured by a well-crafted phishing page that proxies the authentication flow in real time. A certificate-based authentication event cannot be proxied because the authentication proof is cryptographically bound to the specific service the client is authenticating to. The TLS channel provides this binding: the client’s EAP-TLS authentication includes the server’s certificate in the handshake, so a man-in-the-middle presenting a different server certificate will cause the client authentication to fail.

The second dimension is silent continuous authentication. In a hybrid workforce where users move between network environments multiple times per day (home network in the morning, VPN for a meeting, corporate Wi-Fi on-site in the afternoon), an authentication mechanism that requires manual user action at every network transition introduces friction and creates helpdesk load when users fail to re-authenticate correctly. Certificate-based EAP-TLS authentication is automatic: the device presents its certificate to the network authenticator without any user interaction, and the user regains network access transparently. This is operationally critical for large hybrid workforces where the authentication volume and variety of network environments makes manual authentication unsuitable at scale.

VPN Authentication with PKIaaS Certificates

VPN remains the primary remote access mechanism for most enterprise hybrid workforces, particularly for access to on-premises systems, development environments, and internal services that are not accessible from the public internet. Certificate-based VPN authentication provides material security improvements over password-based or OTP-based VPN authentication:

• User VPN certificates: The PKIaaS CA issues a user authentication certificate with the TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) and the user’s UPN (User Principal Name) in the SAN URI or UPN field. The VPN gateway validates the certificate against the PKIaaS CA trust chain and checks revocation via OCSP. If the certificate is valid and unrevoked, the user is authenticated. The VPN gateway can also map the UPN to the corresponding Active Directory or IdP user account for authorization decisions;
• Device VPN certificates: Separate device authentication certificates with the device’s FQDN or serial number in the SAN allow the VPN gateway to enforce a device posture check before allowing user authentication to proceed. A managed device with a valid, MDM-enrolled device certificate can establish a device tunnel; a personal device without a device certificate cannot. This enables a Zero Trust VPN architecture where both the user and the device identity must be valid before access is granted;
• Certificate validity and revocation: When a user leaves the organization, the IT team revokes the user’s VPN certificate in the PKIaaS CA. The revocation propagates to the OCSP responder within seconds. The next VPN authentication attempt from the revoked certificate fails immediately, without requiring password reset, account deprovisioning in the VPN gateway, or any manual intervention in the VPN configuration.

VPN certificate profiles in PKIaaS typically specify: ECDSA P-256 or RSA-2048 key, 1-year validity (or shorter for high-security environments), TLS Client Authentication EKU, and UPN SAN populated from the IdP attribute at enrollment time. The MDM platform delivers the certificate to the device’s certificate store and configures the VPN client profile to reference it, so users do not need to manually select a certificate when connecting to the VPN.

Wi-Fi 802.1X Authentication with EAP-TLS

Enterprise Wi-Fi authentication via 802.1X with EAP-TLS is the certificate-based equivalent of the corporate network access control that previously required users to be on a wired corporate network to access internal resources. With EAP-TLS, a managed device presents its certificate to the wireless access point’s RADIUS server; the RADIUS server validates the certificate chain against the PKIaaS CA, checks revocation, and signals the access point to allow or deny association.

The practical advantages over password-based Wi-Fi authentication (WPA2-PSK or PEAP-MSCHAPv2) are significant:

• No shared secret to manage: WPA2-PSK requires distributing a pre-shared key to every authorized user. When a user leaves or the key is compromised, the PSK must be rotated and redistributed to all authorized users. EAP-TLS has no shared secret: each device has its own certificate, and revoking a single certificate removes exactly that device’s access without affecting any other device;
• Per-device identity: EAP-TLS provides the RADIUS server with the specific device’s certificate identity, not just proof that the connecting device knows a shared key. The RADIUS server can enforce network access policies at the per-device level: assign managed devices to the corporate VLAN, assign BYOD devices to a restricted VLAN, and deny access to devices whose certificates have been revoked;
• Automatic re-authentication: When a managed device roams between access points in the same 802.1X-secured network, EAP-TLS re-authentication is handled automatically by the device’s supplicant without any user interaction. Users moving through a campus or office building never experience authentication prompts as they move between wireless cells.

For hybrid workforces, 802.1X EAP-TLS authentication at corporate office locations provides seamless, phishing-resistant network authentication when users are on-site, while the same certificate is used for VPN authentication when they are remote. A single PKIaaS-issued user or device certificate serves both use cases, with the same revocation mechanism providing instant access termination across both network access channels.

S/MIME Certificates for Workforce Email Security

S/MIME (Secure/Multipurpose Internet Mail Extensions) uses PKI certificates to provide two email security capabilities that no other standard email security mechanism can provide together: digital signing (cryptographic proof that the email came from the stated sender and has not been modified) and end-to-end encryption (encryption of the email body and attachments so that only the recipient with the corresponding private key can decrypt).

PKIaaS issues S/MIME certificates for workforce email security with the Email Protection EKU (OID 1.3.6.1.5.5.7.3.4) and the user’s email address in the SAN RFC 822 name field. The certificate is issued by the private PKIaaS CA; the email client (Microsoft Outlook, Apple Mail, or mobile email clients) trusts the certificate because the PKIaaS root CA certificate is installed in the enterprise trust store via Group Policy, MDM profile, or operating system trust store management.

For hybrid workforce email security, S/MIME provides:

• Email signing for executive and sensitive communications: Signed emails provide recipients with cryptographic proof of the sender’s identity and message integrity. Phishing attacks that spoof executive email addresses fail when recipients are trained to verify S/MIME signatures, because the attacker cannot produce a valid signature from the executive’s private key;
• Email encryption for regulated data: Organizations in regulated industries (healthcare, financial services, legal, government) often have obligations to protect the confidentiality of specific communication categories. S/MIME encryption ensures that email containing patient data, financial information, or privileged legal communications is encrypted end-to-end from sender’s mail client to recipient’s mail client, not only in transit through the mail server;
• Certificate discovery via Active Directory or LDAP: For S/MIME encryption to work, the sender’s email client must have the recipient’s S/MIME certificate (public key). Enterprise deployments publish S/MIME certificates to Active Directory or an LDAP directory so that Outlook and other enterprise email clients can discover recipient certificates automatically when composing an encrypted message. The PKIaaS CA’s CLM integration can automate publishing newly issued S/MIME certificates to the directory.

Smart Card Logon Certificates for Privileged Access

Smart card logon certificates provide the highest authentication assurance available for Windows domain logon and privileged access control. The certificate’s private key is generated and stored in the smart card’s hardware cryptographic module and never exported. Windows Kerberos authentication via PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) uses the smart card certificate to replace the password-based AS-REQ/AS-REP exchange: the domain controller verifies the smart card certificate chain against the PKIaaS CA and issues a Kerberos ticket-granting ticket based on the certificate identity.

Smart card logon certificates from PKIaaS require specific profile configuration:

• Extended Key Usage: Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2);
• Subject Alternative Name: UPN matching the user’s Active Directory account in the UPN SAN field, required for PKINIT to map the certificate to the correct AD account;
• Key storage: The private key must reside in the smart card’s hardware module; the certificate profile should specify that the key is not exportable and must be hardware-backed;
• Issuing CA trust: The PKIaaS issuing CA certificate must be published to the Active Directory NTAuthCertificates store, which authorizes certificates from that CA for Windows domain logon. This configuration is performed once per PKIaaS issuing CA that will issue smart card logon certificates;
• Certificate validity: Smart card logon certificates typically have 1 to 3 year validity periods, with renewal triggered before expiry through the enrollment workflow configured in PKIaaS.

For hybrid workforce environments, smart card logon is most applicable to: privileged administrator accounts that require two-factor authentication combining the physical smart card (something you have) and the PIN (something you know); shared workstations in secure facilities (hospital nurse stations, manufacturing floor terminals) where multiple users authenticate with personal smart cards; and government or defense environments where personal identity verification (PIV) card-based authentication is mandated by policy.

Microsoft Intune Integration for Certificate Distribution

Microsoft Intune is the most widely deployed MDM platform for hybrid workforce device management. PKIaaS integrates with Intune through two enrollment mechanisms, each appropriate for different device platforms and enrollment scenarios.

SCEP-Based Certificate Enrollment for Intune

SCEP (Simple Certificate Enrollment Protocol) is the most broadly supported certificate enrollment protocol for mobile and managed devices. For Intune SCEP integration, the PKIaaS CA exposes a SCEP endpoint. The Intune administrator creates a SCEP certificate profile in Intune specifying: the SCEP server URL (the PKIaaS SCEP endpoint), the trusted root CA certificate (the PKIaaS root CA), the certificate subject and SAN fields (populated from Intune device and user attributes using template variables), the key size and algorithm, and the certificate validity period. Intune assigns the SCEP profile to device groups; enrolled devices request certificates from the PKIaaS SCEP endpoint as part of their Intune compliance profile application, and the certificate is installed in the device certificate store without any user action. SCEP-based Intune certificate delivery supports: Windows (machine and user certificates), macOS, iOS, and Android device platforms.

WSTEP and Windows Auto-Enrollment

WSTEP (Web Services Trust Enrollment Protocol) is the Windows-native certificate enrollment protocol used by Active Directory Certificate Services and supported by PKIaaS for Windows device and user certificate enrollment. For Windows domain-joined devices in an Intune co-management or Active Directory environment, WSTEP-based auto-enrollment allows user and device certificates to be issued from the PKIaaS CA through Windows Group Policy autoenrollment, without requiring the device to use the Intune SCEP flow. The PKIaaS agent is installed on a Windows server in the domain; Group Policy configures autoenrollment to reference the PKIaaS issuing CA. When a domain-joined Windows device processes Group Policy, it automatically requests the certificates specified in the certificate templates configured for autoenrollment, and the PKIaaS CA issues them. This is the seamless experience most Windows administrators expect from AD CS and is now available against a PKIaaS CA without maintaining on-premises CA infrastructure.

Jamf Integration for Apple Device Certificates

Jamf is the MDM platform most widely used for managing Apple device fleets (macOS, iOS, iPadOS). PKIaaS integrates with Jamf through SCEP, the same protocol used for Intune on Apple platforms. The Jamf administrator creates a PKI integration in Jamf Pro pointing at the PKIaaS SCEP endpoint. Certificate profiles in Jamf specify the subject and SAN template, the certificate type (user or device), the key algorithm and size, and the validity period. Jamf scope rules determine which devices receive which certificate profiles.

For hybrid workforces with large Apple fleets, PKIaaS-Jamf integration enables:

• macOS Wi-Fi 802.1X EAP-TLS: Jamf delivers a device or user certificate and a Wi-Fi payload that configures EAP-TLS authentication using that certificate. MacBooks connect to enterprise 802.1X Wi-Fi automatically without prompting users for credentials;
• macOS VPN certificate authentication: Jamf delivers the user certificate and a VPN payload configured to use certificate authentication. The VPN client references the certificate from the keychain without user interaction;
• iOS and iPadOS device certificates for mobile workforce: Field workers and mobile employees with managed iPhones and iPads receive device certificates through Jamf that authenticate them to corporate network resources and VPN;
• Automatic certificate renewal: Jamf monitors certificate expiry dates for certificates it manages and can trigger SCEP renewal requests to the PKIaaS CA before the certificate expires, maintaining certificate validity across the Apple device fleet without manual helpdesk involvement.

VMware Workspace ONE Integration

VMware Workspace ONE (now Omnissa Workspace ONE) is widely deployed in enterprise environments that manage a mix of Windows, macOS, iOS, Android, and ChromeOS devices. PKIaaS integrates with Workspace ONE through SCEP and PKI profile-based certificate delivery, using the same enrollment model as Intune and Jamf: the PKIaaS SCEP endpoint is registered in Workspace ONE as a certificate authority, and certificate profiles assign certificates to device groups based on Workspace ONE’s smart group rules.

For multi-platform hybrid workforces, Workspace ONE’s cross-platform MDM capability combined with PKIaaS certificate issuance provides a unified certificate delivery architecture: the same PKIaaS CA issues certificates for Windows laptops, macOS MacBooks, Android phones, and iOS devices, all managed through Workspace ONE profiles, all with consistent certificate profiles and revocation. The CLM layer connected to PKIaaS gives the IAM team visibility into the certificate status of all devices across all platforms in a single inventory view.

BYOD and Unmanaged Device Considerations

Hybrid workforces often include a proportion of personally owned devices operating under a BYOD policy. Certificate-based authentication for BYOD devices requires a different enrollment model than MDM-managed devices, because the organization’s MDM does not have management authority over a personally owned device and cannot silently install a certificate through the MDM profile mechanism.

For BYOD certificate enrollment, PKIaaS supports several approaches depending on what the user’s device can support:

• User-initiated SCEP enrollment through a registration portal: The user navigates to an organization-provided enrollment portal, authenticates with their IdP credentials (SSO or MFA), and the portal triggers a SCEP enrollment request to the PKIaaS CA. The certificate is installed in the user’s personal device certificate store. The portal can be integrated with the IdP to enforce MFA before allowing certificate enrollment, ensuring that only authenticated users can obtain certificates for their personal devices;
• Limited Workspace ONE or Intune enrollment for BYOD: Many organizations enroll BYOD devices in a limited MDM profile that manages only the work profile (on Android) or only specific applications (on iOS), without full device management. In this limited enrollment model, the MDM can still deliver certificates to the work profile or managed app keychain, providing certificate-based authentication for corporate resources without requiring full MDM enrollment of the personal device;
• BYOD-specific certificate profiles with restricted access: The PKIaaS CA issues BYOD device certificates from a separate issuing CA or certificate profile that is trusted only for access to BYOD-appropriate resources (a restricted network VLAN, specific applications). Managed device certificates from the MDM-enrollment issuing CA are trusted for broader corporate resource access. The separation is enforced at the RADIUS and application layer by checking which issuing CA signed the authenticating certificate.

Certificate Lifecycle Management for Workforce Certificates

Workforce certificates have different lifecycle management requirements than TLS server certificates. A TLS server certificate renewal failure causes a service outage visible to all users. A user authentication certificate renewal failure causes an individual user’s VPN, Wi-Fi, or email signing to stop working, which the user may not report immediately and which may not be noticed until the user is offsite and unable to authenticate.

Effective CLM for workforce certificates requires:

• Per-user certificate inventory: The CLM platform maintains an inventory that maps each certificate to the user and device it was issued to, not just to a generic certificate type. When an expiry alert fires, it routes to the user’s manager or the helpdesk with enough context to identify which user’s access is at risk;
• MDM-triggered renewal: For certificates distributed through MDM, the renewal should also go through the MDM platform. Intune, Jamf, and Workspace ONE each support SCEP renewal requests triggered by the MDM platform before the certificate expires. The PKIaaS CA processes the renewal request and the MDM delivers the renewed certificate to the device without user action;
• Joiner/mover/leaver integration: Certificate lifecycle must be integrated with the HR system’s joiner/mover/leaver process. When a user joins, the IAM provisioning flow should include requesting their VPN, Wi-Fi, and S/MIME certificates from PKIaaS through the MDM enrollment. When a user leaves, the offboarding flow should include revoking all certificates issued to that user. PKIaaS revocation through the management API or the CA administrator interface propagates to OCSP within seconds;
• Revocation confirmation: After revoking a departed user’s certificates, the CLM platform should confirm revocation by checking the OCSP status of each revoked certificate and logging the confirmed revocation timestamp. This provides the audit trail needed to demonstrate to auditors and compliance teams that access was terminated promptly after the user’s departure.

PKIaaS and Zero Trust Workforce Identity

Zero Trust architecture requires that every access request be explicitly authenticated and authorized, regardless of network location. Certificate-based authentication aligns naturally with Zero Trust principles because it provides continuous, cryptographic identity verification without relying on network perimeter trust:

• Identity verification independent of network location: A certificate issued by the organization’s PKIaaS CA verifies the user’s or device’s identity whether the request comes from the corporate network, a home office, or a public Wi-Fi connection. The network is not trusted; the certificate is;
• Short-lived credentials for sensitive access: Zero Trust implementations often use short-lived credentials for sensitive access to minimize the window of credential misuse. PKIaaS supports issuing short-validity certificates (24 to 72 hours) for time-limited privileged access sessions, with the certificate’s expiry providing automatic access termination without requiring an explicit revocation event;
• Device posture enforcement: A PKIaaS device certificate can only be issued to a device that successfully completes the MDM enrollment process. An unmanaged device cannot obtain a device certificate from the PKIaaS CA through the MDM enrollment path. RADIUS and access control systems that require a valid device certificate for network access therefore implicitly enforce managed device posture without a separate NAC agent;
• Continuous revocation checking: Zero Trust access control systems query OCSP for certificate revocation status at each access decision point, not just at initial authentication. PKIaaS OCSP responders provide real-time revocation status so that a revoked certificate fails at the next access attempt even if a session was previously established.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA infrastructure for all workforce authentication certificate types: user authentication certificates (TLS Client Auth EKU, UPN SAN) for VPN and 802.1X, device certificates for managed endpoint network access, S/MIME certificates (Email Protection EKU, RFC 822 SAN) for signed and encrypted email, and smart card logon certificates (Smart Card Logon EKU, UPN SAN, NTAuthCertificates publishing) for privileged access. Contact us at Encryption Consulting to design your workforce certificate architecture.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM visibility layer for workforce certificate lifecycle management: per-user certificate inventory, expiry monitoring with role-based alert routing, MDM-integrated renewal confirmation, joiner/mover/leaver integration for certificate provisioning and revocation, and OCSP revocation confirmation logging for compliance audit trails.
• PKI Services (MDM Integration): Encryption Consulting’s PKI Services include PKIaaS integration with Microsoft Intune (SCEP and WSTEP enrollment), Jamf Pro (SCEP-based Apple device certificate delivery), and VMware Workspace ONE (SCEP and PKI profile configuration), including certificate profile design for each use case, RADIUS and 802.1X SCEP troubleshooting, and Group Policy autoenrollment configuration for Windows domain environments.
• PKI Assessment Service: For organizations evaluating a transition from password-based VPN and Wi-Fi authentication to certificate-based EAP-TLS, Encryption Consulting’s PKI Assessment Service evaluates the current authentication architecture, identifies the certificate types and profiles required, maps each certificate type to the appropriate MDM enrollment mechanism, and produces an implementation roadmap for the certificate-based authentication program.
• PQC Advisory Services: Workforce authentication certificates using ECDSA P-256 or RSA-2048 signing keys are subject to the same NIST IR 8547 algorithm deprecation timeline as all other PKI certificates. Encryption Consulting’s PQC Advisory Services include workforce certificate migration planning: identifying which authentication certificate types can transition to ML-DSA (FIPS 204) and which require continued classical algorithm use pending relying party (RADIUS server, smart card middleware, mobile OS) support confirmation.

Conclusion

The hybrid workforce authentication problem is fundamentally a certificate problem. Every authentication use case that matters for a distributed workforce, including VPN access from home, Wi-Fi authentication at corporate offices, encrypted email for regulated communications, privileged access with smart card assurance, and managed device identity for BYOD governance, has a certificate-based solution that is more phishing-resistant, more operationally scalable, and more auditable than the password or OTP equivalent.

PKIaaS is what makes this certificate program operationally feasible: a governed CA backend that issues the right certificate type for each use case, integrated with the MDM platforms that distribute certificates to devices, monitored by the CLM layer that ensures certificates remain valid and revokes them promptly when they should not. IAM and infrastructure teams that design and operate this system get a workforce authentication layer that does not depend on users remembering passwords, does not require helpdesk involvement for routine authentication events, and provides an audit trail from certificate issuance to revocation that passwords and OTP systems cannot match.

If your organization is evaluating certificate-based authentication for VPN, Wi-Fi, email security, or privileged access, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when major MDM platforms (Intune, Jamf, Workspace ONE) publish updates to their SCEP or certificate delivery integrations that affect PKIaaS enrollment configuration.

Frequently Asked Questions

What is certificate-based authentication and how does it differ from password-based authentication?

Certificate-based authentication proves identity using a digital certificate and corresponding private key. The private key never leaves the device; authentication proves possession of the key without transmitting a secret. Passwords require transmitting a shared secret at every authentication event, making them vulnerable to phishing and interception. Certificates authenticate silently and continuously without user interaction after initial enrollment, regardless of the user’s network location.

How does EAP-TLS certificate authentication work for VPN and Wi-Fi?

In EAP-TLS authentication, the client presents its certificate to a RADIUS server (for 802.1X Wi-Fi) or a VPN gateway. The authenticator verifies the certificate chain against the trusted PKIaaS CA, checks revocation via OCSP, and grants or denies access. The client also verifies the server’s certificate, providing mutual authentication. No password is transmitted in the flow. PKIaaS provides the CA that issues client certificates and the OCSP responder that authenticators query for revocation status.

What certificate types does PKIaaS issue for hybrid workforce authentication?

PKIaaS issues user authentication certificates (TLS Client Auth EKU, UPN SAN) for VPN and 802.1X, device certificates (TLS Client Auth EKU, device FQDN SAN) for managed endpoint network access, S/MIME certificates (Email Protection EKU, RFC 822 email SAN) for signed and encrypted email, and smart card logon certificates (Smart Card Logon EKU plus Client Auth EKU, UPN SAN) for privileged Windows domain logon. Each type has a distinct certificate profile in PKIaaS with the appropriate constraints for that use case.

How does PKIaaS integrate with Microsoft Intune for certificate distribution?

PKIaaS integrates with Intune through SCEP (for Windows, macOS, iOS, and Android) and WSTEP (for Windows domain-joined devices via Active Directory autoenrollment). SCEP Intune profiles reference the PKIaaS SCEP endpoint and template variables for certificate subject and SAN fields. Enrolled devices request certificates automatically as part of Intune compliance profile application, with the certificate installed in the device certificate store without user action.

What is S/MIME and how does PKIaaS support it for workforce email security?

S/MIME uses certificates to provide email digital signing (proving sender identity and message integrity) and end-to-end encryption (encrypting the email body so only the recipient with the corresponding private key can decrypt). PKIaaS issues S/MIME certificates with the Email Protection EKU and the user’s email address in the SAN RFC 822 field. Certificates are distributed to email clients through MDM profiles or Active Directory autoenrollment. For encryption, recipient S/MIME certificates are published to Active Directory or LDAP so that senders’ email clients can discover them automatically.