Managed Cloud PKI Service for Entra ID

Active Directory Certificate Services is Microsoft’s legacy PKI solution that gives organizations the ability to build their own on-premise Public Key Infrastructure. Unfortunately, this often ends up being a costlier venture in terms of finances and time spent. Building a private PKI requires expertise, space for the servers, and regular maintenance. Certificate lifecycle management with Active Directory Certificate Services - from issuance to renewal to building a certificate revocation list - is time-consuming.

It’s important to understand the costs of building a PKI with Active Directory Certificate Services. Aside from taking potentially hundreds of hours to set up initially, there’s a high upfront infrastructure and software cost that can easily exceed $200,000 USD. On top of up-front software and infrastructure costs, Active Directory Certificate Services will have recurring costs in the form of high maintenance.

These costs, unfortunately, are unavoidable. A PKI is a foundational part of security systems. Rushing a configuration, or setting it up with inexperienced professionals is a huge liability. In this writeup by Specter Ops, they identify countless security vulnerabilities organizations will run into if they leave default settings enabled in AD CS. This reason alone is why many organizations choose a managed PKI.

Finally, a PKI service like ours makes it easier to manage on a day-to-day basis. You can generate whatever type of certificate you need, whether it’s a root certificate, a CA certificate, or certificates for user authentication. All of this can be achieved through a single pane of glass, saving you both time and money.

One of the greatest differences between our natively integrated Entra ID PKI and the new Microsoft Cloud PKI service is that it was designed for vendor neutrality. Yes, our platform can integrate with your Microsoft ecosystem, including Entra ID and Intune. However, we can also integrate with all major IDPs and MDMs, providing the secure authentication method of certificates to any organization regardless of the infrastructure they have.

Microsoft Cloud PKI is part of the Intune subscription. Organizations must have Intune in order to leverage it. For more diverse environments incorporating a range of vendors, it’s easier to have a vendor-neutral solution that can integrate with your entire infrastructure at once. Commonly, organizations manage Apple Devices with an MDM like Addigy, Kandji, Mosyle or Jamf. With SecureW2’s PKI, you can easily point your Apple MDM to us, and we will automate its certificate lifecycle management alongside all your Intune-managed devices.

We wouldn’t be able to call it PKI as a Service if we didn’t provide you with everything you needed to deploy certificates. SecureW2 is known for its ability to ingest real-time data from IDPs, MDMs, and EDR/XDRs and use that to automate certificate lifecycle management. For endpoint distribution, we have our automatic gateway APIs for managed devices and our self-service onboarding technology that talks directly to any IDP for unmanaged devices/BYODs.

When it comes to revocation, our cloud-based PKI can revoke certificates in a few different ways, including manually and through automatic revocation with some MDMs such as Intune. Our PKI as a service also includes customizable policies you can create, such as non-utilization, which means certificates that aren’t used for a definable period of time (such as 60 days) are automatically revoked. Revoked user certificates and device certificates are revoked through a Certificate Revocation List as opposed to through the Online Certificate Status Protocol (OCSP).

Our PKI leverages an enhanced integration with Intune’s third-party certificate authority (CA) APIs. While JoinNow Connector PKI can integrate with all major MDMs, it works especially closely with Intune.

In typical Simple Certificate Enrollment Protocol (SCEP) certificate deployment, all a device needs to enroll for a certificate is the SCEP URL and key. However, with Intune, our PKI can take an additional step by verifying that a device exists within your Intune organization prior to issuing a certificate. It’s an extra security measure that truly ensures only authorized devices are capable of enrollment.

On top of this extra security check, our PKI can automate the certificate lifecycle even further with Intune. Our enhanced Intune integration allows our PKI service to check with Intune every several minutes. When a device is removed from your Intune organization for any reason, our PKI will automatically revoke that device’s certificate. A similar integration applies to Jamf.

The user experience with certificate-based authentication differs based on whether they are using managed or unmanaged devices/BYODs. For managed devices, the end user will never notice the certificate enrollment process - our PKI as a service includes gateway APIs that will automatically enroll them for a certificate.

For BYODs, you can utilize our self-service onboarding technology, which allows end users to configure their devices for certificates in a matter of minutes. Users simply navigate to our onboarding page, which can be customized, and log in using their Microsoft Entra ID credentials once. Afterward, our dissolvable client can easily configure their devices for certificates and enroll them quickly.

After enrollment, certificate-based authentication is mostly the same for either type of end-user. They no longer need to remember a plethora of passwords, reset those passwords regularly, or adhere to complex password requirements.

In short, Azure certificate-based authentication (CBA) is a Microsoft authentication feature that allows organizations to use certificates to sign in to Azure. With CBA, a user certificate or a device certificate can be used to authenticate to an Azure AD/Entra ID application instead of a username or password. This has several use cases since Azure can be used to SSO into various systems. The most common use cases we see are to require Devs to verify Device Trust before accessing Azure resources. Applications can be gated behind an Azure sign-in. Lastly, desktop logon can use Azure CBA.

Azure CBA (Entra CBA) is an efficient way for users to access the cloud applications they need to complete work on a daily basis. It’s faster than having to manually type a username/password in and saves them the hassle of regular password resets or changes. It’s also extremely simple to configure.

Yes. Azure Active Directory CBA can be used to create a conditional access policy in Entra ID. Combining certificate-based authentication with conditional access policies allows administrators to create extremely in-depth access control rules.

This configuration doesn’t even need to be challenging. We’ve created a detailed guide outlining how it works and how to CBA authentication policy rules here.

Microsoft Entra Multifactor Authentication provides extra assurance about the authenticity of user accounts when they log in. It’s based on the concept of multi-factor authentication (MFA), which simply uses more than one form of identity at the time of authentication.

Microsoft defines various levels of authentication for its own MFA feature. It categorizes the strength of these authentication factors as MFA strength, passwordless MFA strength, and phishing resistant MFA strength. Certificates can be used as one of the factors in MFA, and is categorized as phishing resistant authentication in terms of how secure it is. You can read more about this in our blog on understanding phishing resistant authentication.