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
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.
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:
Improve password practices
Migrate SSPR and MFA policies to authentication policies
Retire SSPR weak authentication methods
Enable and promote the Microsoft Authenticator
Enforce MFA via Conditional Access
Enforce entity attributes based policy
1 - Improve password practices
To modernize our password requirements we could:
require password of 12-20+ characters
promote Edge password manager or a third party solution.
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
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.
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.
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.
This is what your MFA policy could look like
After enabling user through Conditional Access MFA, ensure to disable them from the legacy 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:
Define your identity personas
Deploy the persona based scenarios
Enable phishing resistant authentication methods
Configure and require authentication strength
Disable legacy authentication methods
Enable passwordless authentication
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
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
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.
 |  |
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.
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.
There are other alternative for the deployment:
Authentication: Optimal
On this stage the roadmap is
Manage Workload Identities
Deploy Authentication context
Enforce Passwordless for all users
Deploy Continuous access evaluation
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.
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
SharePoint Online and OneDrive sites: Conditional access policy for SharePoint sites and OneDrive - SharePoint in Microsoft 365 | Microsoft Learn
Defender for Cloud Apps Session policies: Conditional Access authentication context now in public preview - Microsoft Community Hub
Privileged Access Management: Configure Microsoft Entra role settings in PIM - Microsoft Entra ID Governance | Microsoft Learn
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.
Claus Jespersen has documented how to use m365dsc, bicep or terraform for deployment automation: GitHub - microsoft/ConditionalAccessforZeroTrustResources: ConditionalAccessforZeroTrustResources holding resources for Azure AD CA guidance for Zero Trust
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
About William Francillette:
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.