Configuring Azure AD CBA with Conditional Access Policies

Conditional Access policies, the if-then statements available in Microsoft Azure AD (Entra ID), enable a much more granular level of access control over the resources managed with Azure AD/Entra ID. They can be used to assess a user’s authorization in real time against specific conditions to grant them access appropriately.

When Conditional Access policies are combined with certificate-based authentication, they allow organizations to factor device trust into their Azure AD/Entra ID security. Given that policies available in Azure Conditional Access have an initial learning curve, let’s explore this setup with an example configuration with our SecureW2 certificates.

Prerequisites for Configuring Conditional Access Policies With Certificate-Based Authentication

• Have a client certificate enrolled on your device that contains the attribute User Principal Name
• Enroll unmanaged devices for certificates using Azure AD
• Auto-enroll managed devices for certificates using Intune
• A root CA and intermediate CA (we create ours in SecureW2)
• An active Azure environment and Microsoft Entra ID subscription, ideally as a Global Administrator

Overview of the Configuration Steps

1. Exporting and/or Creating a SecureW2 Certificate Authority
2. Uploading your Root and Intermediate CAs and CRL to Azure Security
3. Creating a Conditional Access Policy in Azure for CBA
4. Creating CBA Policy under Authentication settings in Azure
5. Issuing Client Certificates to Users and Devices

1. Exporting and/or Creating a SecureW2 Certificate Authority

To set up Azure AD CBA with Conditional Access control, you’re going to need a Certificate Authority (CA) to link to your Azure. Our management portal automatically generates Root and Intermediate CAs that you can use. Alternatively, you are free to create your own in our portal.

Exporting an Existing Certificate Authority

• If you already have a Root and Intermediate CA in SecureW2, here’s how you can export them:
• Log in to the JoinNow Management Portal .
• Go to PKI Management > Certificate Authorities
• In the Certificate Authorities section:
• Download the Root CA you’d like to use for Azure CBA set-up
• Download the respective Intermediate CA as well
• Click View on each CA, to find the respective CRL URLs. Save the Base and Delta CRL for each CA.

Creating a New Certificate Authority

If you’d like to create a new Certificate Authority to use for Azure AD CBA, here’s how to do it:

Creating a CA in the SecureW2 Management Portal

• Go to PKI Management > Certificate Authorities.
• In the Certificate Authorities section, click Add Certificate Authority
• Create a Root and/or Intermediate CA, configure settings as desired, and click Save.
• Once it’s been created, navigate back to Certificate Authorities, and click View on your newly created CAs. Save the Base and Delta CRL for each of them.
• Download the CAs as well, as they would need to be uploaded onto Azure Security under Certificate Authorities.

2. Importing the Certificate Authorities to Azure

Now that we have our Certificate Authorities handy, we can import them into Azure.

Certificate Authorities in Azure Security

• Log in to Azure with the right Admin credentials
• Navigate to Security > Manage > Certificate authorities
• Click Upload
• Upload your Root CA
• Check Yes under Is Root CA certificate option as it’s a Root CA
• Paste your Base and Delta CRL URLs
• Click Add
• Do the same Upload process for Intermediate CA as well and check the NO option under Is Root CA certificate option, as it’s not a Root CA
  Note: Certificate Revocation List URL is where you upload your Base CRL.

3. Creating a Conditional Access Policy for Setting up CBA Azure

Now you will have to move to the Conditions Access Policy blade.

• Go to Conditional Access > Create New Policy and give the appropriate name to the policy
• Under Assignments
• Users – Include/Exclude the required users/groups to whom this policy is required to be applied on
• Target Resources > Select what this policy applies to keep the option as Cloud Apps and Include/Exclude the required cloud applications. This step defines the cloud applications on which CBA policy is required to be applied to, hence it’s very important to define them accurately here.
• Conditions – Azure offers a plethora of conditions an organization might want to use to meet their individual IT Security requirements. Choose the relevant conditions that you need to run along with CBA. We have chosen Device platforms as an example here.
• Access Controls – again, you can configure the settings here depending on their requirements. In this example, we have used Grant access > Require Authentication Strength > Phishing-resistant MFA. There is no Session control in our example.

Conditional Access policy set in Azure

Note: CBA is one of the Phishing-resistant authentication methods available in Azure

Phishing-resistant authentication methods available in Azure

4. Creating a CBA Authentication Policy in Azure

After setting up the required conditions in the Conditions Access policy blade, you will have to move to the Certificate-based authentication policy.

Certificate-based authentication configured under Authentication policies

• Go to Authentication methods > Policies > Certificate-based authentication
• Under Enable and Target
• Include/Exclude the groups/users to which CBA policy must be applied
• To create authentication binding rules, go to Configure > Authentication binding > Add Rule and do the following settings
• Certificate attribute, select Certificate Issuer
• Select the appropriate CA through which you want to establish trust under the drop-down Certificate Issuer Identifier
• Check on the Authentication Strength. Multi-factor authentication in this case as we had forced ‘Require phishing-resistant MFA’ under Grant control in Conditional Access policy
• Keep the Affinity binding as Low

Authentication binding policy rule in Certificate-based authentication setting

Note: While Username binding policy rules could be customized, for this use case we didn’t have the need to do anything here.

5. Issuing Client Certificates to Users and Devices

If your organization uses an MDM such as MEM Intune, SecureW2 can integrate with your infrastructure directly to automatically enroll end users for certificates through our gateway APIs. This ensures that the managed devices on your certificates can self-enroll for certificates without any input from the end-users themselves, avoiding any potential misconfigurations.

Even if your network consists of unmanaged devices, issuing certificates doesn’t need to be complicated, thanks to our onboarding software, JoinNow MultiOS. With JoinNow MultiOS, enrolling for certificates is as simple as end-users navigating to your customized onboarding portal, entering their existing credentials, and letting our dissolvable client handle the rest. You can read more about this process in our guide.

Deploy Conditional Access for Azure CBA With SecureW2

The greatest challenge to the widespread implementation of digital certificates has been the difficulty associated with managing them. Building a PKI to create, issue, and revoke certificates required an enormous amount of expertise that few network administrators had.

However, infrastructure like Microsoft Entra ID (Azure AD) provides a clear path to CBA and managed PKIs further pave the way to secure passwordless authentication. There’s no need to build your own PKI from scratch, pouring time, money and expertise into the endeavor when you can utilize an already existing MPKI that was created to integrate with your existing infrastructure.

If you’d like to see exactly how your network would look with SecureW2, we’d be happy to demonstrate. Set up a free demo with our team to see firsthand how easy it can be to go passwordless.

---

Frequently Asked Questions

What is certificate-based authentication?

Certificate-based authentication (CBA) is a passwordless authentication method that verifies a user or device using a digital certificate instead of credentials such as a username and password. During authentication, the certificate proves the identity of the user or device through public key cryptography, making it much more resistant to phishing, credential theft and MFA fatigue attacks than password-based logins.

In Microsoft Entra ID (formerly Azure AD), CBA allows organizations to authenticate users to cloud applications using X.509 certificates and can be combined with Conditional Access policies for stronger identity and device trust controls.

Is Conditional Access authentication or authorization?

Conditional Access is primarily an authorization and access control framework, not an authentication method itself. It evaluates signals such as user identity, device compliance, location, risk level and authentication strength to determine whether to grant, block or restrict access to an application or resource.

In Microsoft Azure/Entra ID, Conditional Access works like an “if-then” engine. For example, if a user signs in from an unmanaged device, then the policy may require certificate-based authentication or phishing-resistant MFA before granting access. Authentication methods like passwords, certificates, or MFA verify identity while Conditional Access determines what the authenticated user is allowed to access under specific conditions.

Why use certificate-based authentication with Conditional Access?

Combining certificate-based authentication with Conditional Access helps organizations enforce stronger identity and device trust policies. Certificates verify user and device identities, while Conditional Access evaluates additional context such as compliance status, location and risk signals before allowing access. This combination supports zero-trust security strategies and phishing-resistant authentication requirements.

Can Conditional Access require certificate authentication?

Yes. Conditional Access policies in Microsoft Azure AD/Entra ID can require certificate-based authentication by enforcing authentication strength policies, including phishing-resistant MFA requirements. Organizations can apply these policies to specific users, groups, applications, devices or risk scenarios.

Does Azure AD support certificate-based authentication?

Yes. Microsoft Azure AD/Entra ID supports certificate-based authentication for cloud and web applications. Organizations can use X.509 certificates to authenticate users without passwords, helping reduce the risk of phishing and credential theft. However, Azure AD itself does not issue certificates, so organizations typically integrate with a PKI or managed PKI provider to deploy and manage certificates.