The Identity Pillar of Zero Trust: Where Your MFA Sits and What Moves You Up
September 02, 2026 •
Zero Trust programmes stall in a predictable place. The strategy gets written, the five pillars get named, and then nobody can say concretely what “improve identity” means this quarter. The maturity model exists to fix exactly that, and the identity pillar is the one worth starting with, because it is the pillar where a small number of decisions produce a measurable stage change.
This page is about that specific question: which stage your authentication is actually at, and what moves it up one. If you are looking for the broader case for Zero Trust and MFA together, that is covered in why Zero Trust MFA is essential for your business security.
Why the identity pillar first
The CISA Zero Trust Maturity Model version 2.0, published in April 2023, sets out five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. They are not sequential and you are not meant to finish one before starting another.
Identity is still the sensible first move for most organizations, for three reasons that have nothing to do with ideology.
- It gates the others. Every other pillar makes an access decision that assumes the identity behind the request has been established. Get identity wrong and the sophistication elsewhere is decorative.
- It does not require re-architecture. Advancing the identity pillar is a change to how people authenticate. Advancing the network pillar is a change to your network. One of those can be done this quarter.
- It is where the attacks are. Credential-based intrusion remains one of the most common initial access routes, and it is the route that stage progression here directly closes.
The four stages, applied to authentication
The model assesses each pillar across four maturity stages. Applied to how your users actually sign in, they look like this.
| Stage | What authentication looks like | Typical tell |
|---|---|---|
| Traditional | Passwords, or passwords plus basic MFA, with static access rules that do not change based on context. | MFA is on for remote access but not internal systems, and the rules have not changed in two years. |
| Initial | MFA is applied broadly and some of the enforcement is automated, while significant parts are still handled manually. | Policy is centrally defined for cloud applications, but on-premises systems are governed by a separate manual process. |
| Advanced | Phishing-resistant methods, such as FIDO2 or PIV credentials, are the standard rather than an option for a pilot group. | You can name the users who are not on a phishing-resistant method, because there are few enough to name. |
| Optimal | Continuous validation of identity, so that trust is re-evaluated during a session rather than granted once at sign-in. | A change in risk mid-session triggers re-authentication, rather than being noticed at the next login. |
Summarised from the CISA Zero Trust Maturity Model version 2.0, April 2023. This is a plain-language paraphrase of the identity pillar’s authentication expectations, not a quotation. The full model is linked in the sources at the end.
Traditional to Initial: coverage, not strength
The first move is unglamorous and it is about reach rather than technology. Moving out of Traditional means MFA stops being a remote-access control and becomes an everywhere control, with enforcement defined centrally rather than system by system.
The systems that hold organizations at Traditional are consistent: the VPN is covered but the Windows desktop login is not, the cloud applications are covered but the on-premises line-of-business application is not, and the service desk has an exception process that has quietly become a standing arrangement. None of that is solved by buying a stronger factor. It is solved by extending the factor you already have to the places it does not reach.
Initial to Advanced: the kind of factor starts to matter
This is the stage transition where the type of authentication becomes the point. Advanced expects phishing-resistant methods as the standard, which rules out the methods most organizations are relying on today.
Phishing-resistant means the credential is cryptographically bound to the legitimate domain and cannot be replayed against a lookalike site. FIDO2 security keys and passkeys qualify. PIV and CAC smart cards qualify. One-time passcodes delivered by text message do not, and neither does a standard approve-or-deny push notification, because both can be relayed by an attacker-in-the-middle proxy in real time. The distinction is explained properly in our guide to what phishing-resistant MFA is.
The practical sequencing advice is to do privileged accounts first. Administrators, finance approvers and anyone who can change access rights are both the highest-value targets and the smallest population, which makes them the fastest measurable progress available. Read the stage transition as two projects rather than one: phishing-resistant for privileged accounts this quarter, broad rollout next.
Advanced to Optimal: trust that expires
Optimal is where the model stops being about the login and starts being about the session. Continuous validation means access is re-evaluated as conditions change, rather than a successful sign-in buying uninterrupted trust for the rest of the day.
In practice this looks like re-authentication triggered by a change in risk signal, step-up authentication in front of a sensitive action rather than at the front door, and session lifetimes set by sensitivity instead of by convenience. It is worth being realistic that most organizations are not close to this, and that a credible Advanced is a better goal for the next twelve months than a theoretical Optimal.
The group that decides your stage
Every Zero Trust identity programme eventually arrives at the same obstacle, and it is not technical. There is a group of users for whom the standard method does not work.
Common examples: staff who do not have a corporate mobile device and cannot be required to use a personal one, shift and shared-station workers where one device is used by many people, staff working in environments where phones are prohibited or physically cannot be brought in, field staff with no reliable connectivity, and contractors outside your device management entirely.
What usually happens is that this group gets an exception, the exception becomes permanent, and the exception is what your maturity stage is actually measured by. The better approach is to solve for them with a different method rather than a weaker one. A hardware token, a security key, a passcode grid or an offline-capable method can put a user on a strong factor without requiring them to hold a phone. That is the difference between an organization at Advanced and an organization that describes itself as Advanced.
Where this shows up in compliance
Zero Trust is increasingly referenced in the frameworks that already apply to you, which means stage progression is usually defensible on compliance grounds as well as security ones.
- US federal. Executive Order 14028 directs federal agencies toward Zero Trust, and OMB memorandum M-22-09 sets a phishing-resistant MFA requirement for agency staff.
- NIST CSF 2.0. The Protect function and its authentication subcategories align with the identity pillar directly.
- CMMC 2.0. Defence contractors are pushed toward these controls through the underlying NIST SP 800-171 requirements.
- Essential Eight (Australia). Maturity Level 2 and 3 expectations around phishing-resistant MFA line up with the Advanced stage. See our Essential Eight MFA guide.
- HIPAA. A proposed update to the HIPAA Security Rule would make MFA an explicit requirement for systems handling electronic protected health information. It is a proposal rather than a rule in force, so treat it as direction of travel. See our HIPAA MFA guide.
The full set is in our MFA compliance hub.
A self-assessment you can run this week
Six questions. Answer them honestly about your weakest covered population, not your pilot group.
- Is MFA enforced at the Windows or desktop sign-in, or only at remote access?
- Is there a single place where authentication policy is defined, or does each system have its own?
- What percentage of privileged accounts use a phishing-resistant method today?
- Can you produce a list of every user whose only method is a text message or a push notification?
- What happens to authentication when the network or the MFA service is unreachable? Is the answer documented?
- Does anything re-evaluate trust after a successful sign-in?
Questions 1 and 2 place you between Traditional and Initial. Questions 3 and 4 place you between Initial and Advanced. Questions 5 and 6 are the ones that tend to reveal that a stage was claimed too early.
How LoginTC fits
LoginTC is a multi-factor authentication platform that covers cloud and on-premises systems from one subscription, which is relevant to this model mainly because of the coverage problem described above. The systems that hold organizations at Traditional are usually the on-premises ones, and the users who hold organizations at Initial are usually the ones who cannot use a phone.
Method choice covers both. Security keys and FIDO2 in several form factors address the phishing-resistant requirement at the Advanced stage, covered on our FIDO2 authentication page. Hardware tokens, passcode grids and offline-capable methods address the users who cannot carry a phone, and the full list is on our authentication solutions page.
Stuck one stage below where you want to be?
Talk to our team about the systems and the users that are holding your identity pillar back, or start a free trial today. We cover cloud, on-premises and hybrid deployments from one subscription.
Frequently asked questions about the Zero Trust identity pillar
What are the five pillars of the CISA Zero Trust Maturity Model?
Identity, Devices, Networks, Applications and Workloads, and Data. The model is currently at version 2.0, published in April 2023. The pillars are not sequential, and organizations are expected to advance across several at once rather than completing one before starting the next.
What are the four maturity stages?
Traditional, Initial, Advanced and Optimal. Each pillar is assessed against all four, so an organization can sit at different stages for different pillars. For the identity pillar the stages are best understood by what kind of authentication is standard: passwords or basic MFA with static rules at Traditional, broad MFA with partly automated enforcement at Initial, phishing-resistant methods as the standard at Advanced, and continuous validation of identity at Optimal.
Which stage is most organizations at?
Between Traditional and Initial for the identity pillar, more often than their own self-assessments suggest. The usual reason is not the mainstream user population but the exceptions: a system that MFA never reached, or a group of users on a weaker method because the standard one does not work for them. Your stage is set by the weakest population you cover, not the strongest.
Does the maturity model require phishing-resistant MFA?
It is what the Advanced stage of the identity pillar expects, rather than a blanket requirement at every stage. Separately, US federal agencies are subject to OMB memorandum M-22-09, which sets a phishing-resistant MFA requirement directly. For most private-sector organizations phishing-resistant MFA is a stage-progression goal rather than a legal obligation, though several compliance frameworks are moving in the same direction.
Is a push notification good enough for the Advanced stage?
No. A standard approve-or-deny push notification is not phishing-resistant, because an attacker-in-the-middle proxy can relay the sign-in in real time and the user approves a prompt that looks legitimate. Number matching reduces accidental approvals and is a meaningful improvement over plain push, but it does not make the method phishing-resistant in the cryptographic sense, because there is still no binding between the credential and the domain. The methods that qualify are FIDO2, including security keys and passkeys, and PKI-based smart cards.
How do I advance the identity pillar without a large project?
Two moves cover most of the available progress. First, close the coverage gaps, which usually means putting MFA in front of the systems it never reached, most often the desktop sign-in and on-premises applications. Second, move privileged accounts to a phishing-resistant method. Privileged accounts are the highest-value targets and the smallest population, which makes them the fastest measurable stage progress available. Neither requires network re-architecture.
What about users who cannot use a phone?
Give them a different strong method rather than a weaker one. Security keys, hardware tokens, passcode grids and offline-capable methods all provide a second factor without requiring the user to hold a phone. This matters more than it appears, because an exception granted to this group tends to become permanent, and a permanent exception on a weak method is what caps your maturity stage regardless of what the rest of the organization is using.