Microsoft updates its authentication options in Azure IDaaS

Microsoft has recently announced two improvements that will not usually make it to the headlines, but which have important implications for organizations adopting Azure Active Directory IDaaS (which is admittedly slow in the SEE region).

Following this year's high profile attacks, it has become apparent threat actors will now routinely bypass existing multifactor (MFA) authentication schemes. This happens via either phishing kits leveraging attacker-in-the-middle or simply exhausting users with MFA prompt bombing.

Authentication strength with FIDO2 and CBA support

It is therefore good to see Azure AD is catching up and now offering the choice of authentication strength within the conditional access policies, allowing administrators to specify which combination of authentication methods can be used to access a resource. For example, they can make only phishing-resistant authentication methods (Windows Hello for Business, FIDO2 security key or Certificate-Based Authentication) available to access a sensitive resource. But to access a nonsensitive resource, they can allow less secure multifactor authentication (MFA) combinations, such as password + SMS. More detailed info on this functionality here.

CBA authentication support without ADFS on-premise

The second update is making it easier to adopt certificate based authentication (CBA) to allow or require users to authenticate directly with X.509 certificates against applications protected by Azure AD.

The new Azure AD certificate-based authentication feature enables customers to adopt a phishing resistant authentication and authenticate with a certificate produced with the organization's PKI infrastructure.

Before cloud-managed support for CBA to Azure AD, customers had to implement federated certificate-based authentication, which requires deploying Active Directory Federation Services (AD FS). ADFS is a notoriously complex solution requiring multiple servers, mostly on-premises deployments or network reconfiguration, which ultimately implies additional maintenance and risk (as it's an extension of the attack surface).

The benefits here are clear: reduced attack surface, simplified architecture and cost reduction, as there is no more need to invest in federated AD FS.

The feature works well with the new authentication strength options described earlier, allowing an easier way to secure applications with CBA phishing-resistant authentication.

Also, Azure AD CBA is a free feature, and you don't need any paid editions of Azure AD to use it.

Worth noting is that this feature does not replace and certainly still requires customers to own Public Key Infrastructure (PKI) and provision certificates to their users and devices.

More details here.