top of page
  • Writer's pictureWill Francillette

Implementing CISA’s Zero Trust Architecture: A Microsoft Approach - Identity: Authentication

Updated: Mar 8

CISA Zero Trust Architecture

Welcome back to the series: Implementing CISA’s Zero Trust Architecture: A Microsoft Approach.

In this blog, we will start looking at the first pillar: identity. This pillar encompasses all types of identities including user, service, application, or machine accounts.

The identity maturity level will be assessed against different processes as we discussed in the previous blog in the definition of the maturity model. Those processes are:

  • authentication

  • identity stores

  • risk assessments

  • access management

  • visibility and analytics capability

  • automation and orchestration capability

  • governance capability


As a recurrent scheme in this series, we will use the traditional level to establish the baseline and identify some of the concerns and issues. We will then aim to implement the tasks attributed to each level until advancing to the next level. After each phases, the organisation can assess the gap between the baseline and target and identify possible discrepancies.

I won't dive in details about implementing each solution and focus on what to deploy rather than how. I will ensure to share links about guidance and further read on a topic.


In this blog, we will discuss the authentication process aiming to migrate from a one time username and password authentication to adaptive, strong and resistant passwordless authentication continuously evaluated and monitored.


You can find the previous blogs on this series here:


Table of Contents



Authentication: Overview


CISA Authentication

The authentication is the process or action of verifying the identity of a user or process.

As you can see in the above table, the CISA has focused this process around Multi-Factor Authentication (MFA) and passwordless. We will discuss how to implement and strengthen your MFA deployment based on your maturity level and use Entra capabilities to achieve the optimal stage.


Let's establish the baseline.


Authentication: Traditional

As mentioned in the introduction, this step is the preliminary stage where we agree the vision and identify concerns and issues, gather sponsorship and identify stakeholders.

At this stage, we can denote the following concerns:

  • password centred authentication

The combination of username and password is the most common authentication method but has been the ideal entry point for malicious actors to infiltrate your organization and initiate an attack. A password can be shared, written on a piece of paper, present in clear text in an application or a file. Regardless of its strength and complexity, it can be compromised using directory based attacks such as brute-force or password spray attacks.

Time for brute force password

In addition, many major data breaches occurred in the last decade in mainstream services such as LinkedIn or Facebook, and leaked passwords flooded the dark web. Attackers can purchase password databases giving access to millions of email addresses, passwords and other personal information.


  • static and rigid authentication The organisation may have deployed MFA using Entra ID legacy MFA capability said per-user. It is enabled on a user basis, and lack monitoring and customisation. You will be prompt for MFA challenge at every sign-ins except if you allow users to skip it for the specific period of time. It will apply to all applications and doesn't take in consideration possible change of circumstances like device risk or location.


  • legacy and weak authentication method

The initial deployment of MFA often include weak second step verification such as security questions, email, SMS, or voice call known to be exploitable by an adversary using social engineering or other technics.


Authentication: Initial

During this phase we will accomplished the following endeavours:

  1. Improve password practices

  2. Migrate SSPR and MFA policies to authentication policies

  3. Retire SSPR weak authentication methods

  4. Enable and promote the Microsoft Authenticator

  5. Enforce MFA via Conditional Access

  6. Enforce entity attributes based policy


1 - Improve password practices

To modernize our password requirements we could:


2 - Migrate SSPR and MFA policies to authentication policies

Historically, Microsoft Entra ID had 2 authentication scenarios and platforms: Self Service Password Reset (SSPR) and MFA. Both portals have now been merged but a distinct authentication methods page is still available for both solutions

Per-User MFA page
SSPR page


Microsoft is deprecating these 2 separates pages on September 30, 2025.

A new set of policies with additional authentication methods is available in the Entra ID portal > authentication methods.

After reviewing your current authentication usage from, for example, the authentication method activity report, enable the corresponding authentication methods from the new set of policies. They take precedence over the legacy set and can be scoped to a pilot group.


After migrating and confirming that all your users are using the new policies you can then complete the migration as documented by Microsoft here: How to migrate to the Authentication methods policy - Microsoft Entra ID | Microsoft Learn 


3 - Retire SSPR weak authentication methods

Ensure that security questions and email addresses for SSPR are disabled/unticked from the legacy SSPR portal. Security questions are not available in the new authentication policies but ensure Email OTP is not available for your users.

The legacy SSPR portal is available here:

Go to Entra portal > Users > User Settings > Password reset > Authentication methods

The new authentication policies are available here:

Go to Entra portal > Protection > Authentication methods > Policies


4 - Enable and promote the Microsoft Authenticator

The Microsoft Authenticator app provides an additional verification option during SSPR or MFA events via a notification or an OATH token.


You enable and configure your deployment scope from the Entra portal > Authentication methods > Policies > Microsoft authenticator.

Authentication policies: Authenticator

After enabling the policy, you can promote the authenticator app registration in your organisation using a registration campaign from Entra portal > Authentication methods > Registration campaign.

At the next login, your users will be prompted to register their account with the authenticator.

Authenticator registration campaign

5 - Enforce MFA via Conditional Access


Conditional Access policies are If-then statement policies allowing us to authorize or deny authentication requests based on signals and conditions retrieved from multiple platforms. The authentication will be assessed based on the user roles, location, application, or threat level.


Conditional Access overview

This is what your MFA policy could look like

Conditional Access MFA policy

After enabling user through Conditional Access MFA, ensure to disable them from the legacy per-user MFA

Disabling Per-User MFA


6- Enforce entity attributes based policy

We will enforce some restriction using Conditional Access such as:


Authentication: Advanced

During this phase we will accomplished the following endeavours:

  1. Define your identity personas

  2. Deploy the persona based scenarios

  3. Enable phishing resistant authentication methods

  4. Configure and require authentication strength

  5. Disable legacy authentication methods

  6. Enable passwordless authentication

  7. Deploy Windows Hello for Business


1 - Define your identity personas

Not all users have the same privileges and sensitivity. Microsoft divides those users as followed:

  • Enterprise account: standard users

  • Specialized account: developers and sensitive accounts

  • Privileged account: IT operations

Enterprise Account classification

There are other personas we haven't talked about such as guests (B2B), externals, service accounts, and service principals.

Those personas will be the base of deploying the persona-based conditional access framework created by Claus Jespercen.

Find the full detail for the different personas here:


2 - Deploy the Persona based framework

The persona based framework is designed to optimise security and productivity by enforcing a specific profile to each persona. It will allow a stronger and tailored security for your privileged and specialized users and a flexible profile for your standards (internals), guests, or non human identities.

This framework will help you minimize gaps in your environment and reduce the attack surface for your identities.

You can find Claus' whitepaper here: (3) Post | LinkedIn


3 - Enable phishing resistant authentication methods

Authentication methods strength classification

Specialized and privileged accounts will be of high value for an attacker and will be targeted by phishing attempt. You can enable phishing resistant MFA methods such as One Time Passcode (OTP) or device-bounded authentication (FIDO2) to strengthen those sensitive users and protect their accounts.

Those are enabled in the authentication policies page. OTP can be used for first time authentication or to register new authentication method.

Device-bounded authentication are ideal for IT operators as their are immune to Adversary-in-the-Middle (AitM) attacks of the like EvilGinx. You can use FIDO2 USB keys (example Feitan or Yubikey) or Passkeys. Microsoft has announced passkey in Entra ID (preview).


4 - Configure authentication strength

We will now configure the authentication strength for the different type of users we discussed above. Authentication strength are available here: Entra portal > Protection > Conditional Access > Authentication strengths

For privileged and specialized account we will enable Phishing-resistant MFA and OTP

Standard/enterprise users will be enabled for phishing resistant MFA, passwordless, OTP, push notifications and OATH token.

Ensure the configured authentication methods are enabled for your users otherwise the will be unable to sign in.


Authentication Strength : Privileged accounts


Authentication Strength: Standard account

5 - Require Strong Authentication

We use Conditional Access to require the authentication strength policy we've configured. This will also indirectly remove the SMS, Voice calls and others authentication methods non phishing resistant. To do so we modify the Grant control to require authentication strength and select the relevant policy.

Conditional Access: Require authentication strength

6 - Enable passwordless authentication

In the effort to move away from password centred authentication, privileged accounts are now passwordless and sign in with security keys.

Your standard users could use the authenticator as a mean for passwordless until Entra ID passkeys are generally available.


7 - Deploy Windows Hello for Business

We use Windows Hello for Business to enable biometric authentication to Windows devices or cloud resources.

WHfB is enabled out of the box for Entra Joined devices.

Organisation using Hybrid Entra Joined devices can use Cloud Kerberos Trust to enable WHfB.

You can configure and require WHfB to your users using Intune and account protection policies available here: Intune > Endpoint security > Account protection > Account protection.

Windows Hello for Business policy

There are other alternative for the deployment:


Authentication: Optimal

On this stage the roadmap is

  1. Manage Workload Identities

  2. Deploy Authentication context

  3. Enforce Passwordless for all users

  4. Deploy Continuous access evaluation

  5. Conditional Access automation


1 - Manage Workload Identities

A workload identity is an identity you assign to a software workload (such as an application, service, script, or container) to authenticate and access other services and resources.

Conditional Access for workload identities enables blocking service principals from outside of trusted public IP ranges, based on risk detected by Microsoft Entra ID Protection, or in combination with authentication contexts.

Conditional Access: Workload identities

2 - Deploy Authentication context

Authentication context can be used to further secure data and actions in applications. These applications can be your own custom applications, custom line of business (LOB) applications, applications like SharePoint, or applications protected by Microsoft Defender for Cloud Apps.

You could use Authentication context to request a term of use or request a new MFA challenge, request a different authentication strength and more.

Authentication context is available out of the box for


You can also integrate Authentication context with your own applications if they are using Open Id Connect for authentication: Developer guidance for Microsoft Entra Conditional Access authentication context - Microsoft identity platform | Microsoft Learn


3 - Enforce Passwordless for all users

All users should now use passwordless authentication using the Authenticator app or preferably device-based authentication such as keypass or FIDO2 security key. The authentication strength will be enforced via Conditional Access.


4 - Deploy Continuous access evaluation

Protect collaboration apps (Exchange Online, SharePoint Online, and Teams) in near real-time by assessing any specific events triggering a conditional access policy to be re-evaluated:

  • User Account is deleted or disabled

  • Password for a user is changed or reset

  • Multifactor authentication is enabled for the user

  • Administrator explicitly revokes all refresh tokens for a user

  • High user risk detected by Microsoft Entra ID Protection


5 - Conditional Access automation

Conditional Access policies are a crucial component of the security framework and changes should be closely monitored. Using DevOps and Configuration-as-Code will ensure those policies are only modified programmatically and manual/unauthorized changes should be reverted back.

You can use the Graph API for automation or use the Microsoft 365 DSC module to automatically monitor and revert those changes. You could also use those solutions to provision test, dev or multiple environments using a DevOps approach.


You can also look at my blog to automate Conditional Access configuration drifts monitoring: Monitor Entra Conditional Access with M365DSC and Azure DevOps (french365connection.co.uk)

Feel free to look at my other posts related to m365dsc: M365DSC (french365connection.co.uk)


Thomas Naunheim has also documented how to operationalise Conditional Access using the Graph API and Azure DevOps: AADOps: Operationalization of Azure AD Conditional Access - Thomas Naunheim (cloud-architekt.net)


Conclusion

Conditional Access is a comprehensive solution and in constant development. I wanted to mention 2 features in public preview: 1- authentication flows allows you to control device code signing and authentication transfer from a Outlook desktop app to a mobile. 2- token protection is a feature that will help protect against Adversary-in-the-Middle(AitM) attacks ensuring a token is only usable from the intended device. This feature is currently only available for Exchange Online and SharePoint Online on Windows devices.

In the next blog, we will cover the Identity Stores.


Thanks for reading!


References


 
Will

I am a Microsoft Solutions Architect specialized in Microsoft 365, Entra and Azure security products at Threatscape.

I love learning, blogging and coding. My interests are very diverse and span across architecture, security, cloud engineering, automation, DevOps and PowerShell.

I own over a dozen Microsoft certifications and have worked in IT across multiple and diverse industries for over 15 years.




1件のコメント


DEANL144
3月11日

This is excellent, looking forward to the next articles in this series.

いいね!
bottom of page