Assessing Zero Trust Maturity on Microsoft Azure and Microsoft 365
An Azure Zero Trust assessment scores six pillars with concrete Microsoft signals — Conditional Access, Intune, EIDSCA — mapped to NIS2. For security architects.
Marc Dekeyser |
Azure Zero Trust Assessment: Scoring Maturity Across the Six Pillars
An Azure Zero Trust assessment scores an organisation’s maturity across the six pillars of the Microsoft Zero Trust model — identity, endpoints, applications, data, infrastructure, and network — using concrete configuration signals from Microsoft Azure and Microsoft 365 rather than self-attestation. Done properly, an Azure Zero Trust assessment produces a per-pillar maturity rating tied to named controls, which maps cleanly onto NIS2 expectations.
Zero Trust is often discussed as a philosophy — “never trust, always verify.” For an assessment to be useful it has to become measurable. That means translating each pillar into specific signals you can read from a tenant: a Conditional Access coverage percentage, a device-compliance ratio, the presence or absence of microsegmentation. Maturity is then a function of those signals, not of intent.
Key takeaways
- The Microsoft Zero Trust model has six pillars: identity, endpoints, applications, data, infrastructure, and network.
- Maturity is assessed per pillar against concrete signals — Conditional Access coverage, Microsoft Intune device compliance, Microsoft Purview data classification — not against a checklist of intentions.
- The EIDSCA (Microsoft Entra ID Security Config Analyzer) provides a control set for scoring the identity pillar objectively.
- Zero Trust maturity maps onto NIS2 Article 21 risk-management and access-control expectations.
- A maturity model is only useful with a defined target state; “traditional, advanced, optimal” needs a per-pillar target, not a universal one.
What are the six pillars of the Microsoft Zero Trust model?
The six pillars of the Microsoft Zero Trust model are identity, endpoints, applications, data, infrastructure, and network — each a domain where access is verified explicitly, granted with least privilege, and assumed to be operating under breach. An Azure Zero Trust assessment examines each pillar separately because maturity is rarely uniform; most organisations are advanced on identity and traditional on data.
Each pillar has a distinct verification surface. Identity verifies who is asking. Endpoints verify the health of the device asking. Applications verify that access to each application is governed. Data verifies that information is classified and protected wherever it travels. Infrastructure verifies that workloads are hardened and monitored. Network verifies that segmentation limits lateral movement.
The mistake is to treat Zero Trust as an identity project. Identity is the entry pillar, and the most mature in most tenants, but a strong identity posture over unclassified data and a flat network is a partial implementation.
How do you measure maturity per pillar?
You measure maturity per pillar by reading specific configuration signals from Microsoft Azure and Microsoft 365 and scoring them against a defined target, rather than asking whether the organisation “does Zero Trust.” Each pillar has signals that are observable and countable.
| Pillar | Concrete signal | Source |
|---|---|---|
| Identity | Conditional Access coverage of users and apps; phishing-resistant MFA; legacy auth blocked | Microsoft Entra ID |
| Endpoints | Percentage of devices marked compliant; enrollment in Microsoft Intune | Microsoft Intune / Microsoft Entra ID |
| Applications | App registrations governed; consent policies; app access via Conditional Access | Microsoft Entra ID |
| Data | Sensitivity labels applied; DLP policy coverage; classification rate | Microsoft Purview |
| Infrastructure | Defender for Cloud secure score; workload hardening; just-in-time VM access | Microsoft Defender for Cloud |
| Network | Microsegmentation; private endpoints; network security group rules; no flat networks | Microsoft Azure networking |
A maturity rating per pillar — commonly traditional, advanced, optimal in Microsoft’s model — falls out of these signals. The identity pillar is optimal when Conditional Access covers all users and all applications with phishing-resistant authentication strength, legacy authentication is blocked, and Privileged Identity Management eliminates standing privilege. It is traditional when MFA is optional and legacy protocols are open. The identity controls in detail are covered in Conditional Access and PIM as compliance evidence.
The endpoints pillar is measured by the proportion of devices marked compliant by Microsoft Intune and required compliant by Conditional Access. A tenant where 30 percent of devices are unmanaged and access is granted anyway is traditional, regardless of how strong the identity pillar is.
The data pillar is the one most organisations under-rate. Maturity here means Microsoft Purview sensitivity labels are applied — automatically where possible — and data loss prevention policies cover the regulated data categories. An organisation can classify nothing and still claim “Zero Trust” on the strength of its identity posture. The data signal exposes that.
What is the EIDSCA and how does it score the identity pillar?
The EIDSCA — the Microsoft Entra ID Security Config Analyzer — is a control framework that defines specific, checkable Microsoft Entra ID security settings, giving the identity pillar an objective scoring basis rather than a subjective rating. EIDSCA enumerates configuration controls across authentication methods, authorization, and tenant settings, each with a defined secure value.
This matters because “is your identity posture good” is not assessable. “Is the authentication methods policy configured to disallow SMS as a primary method,” “is security defaults disabled in favour of explicit Conditional Access,” “is user consent to applications restricted” — these are. EIDSCA turns the identity pillar into a set of pass-or-fail controls, each tied to a documented Microsoft setting and its API path.
An identity-pillar maturity score built on EIDSCA is reproducible. Run it twice and you get the same answer; run it after a change and you see the delta. That reproducibility is what makes it audit-grade rather than opinion.
How does Zero Trust maturity map to NIS2?
Zero Trust maturity maps to NIS2 because the technical and organisational measures NIS2 Article 21 requires are, in substance, the Zero Trust pillars under different names. NIS2 asks for access control, asset management, cryptography, and security in operations — the same ground the identity, endpoints, data, and infrastructure pillars cover.
A worked mapping: Article 21(2)(i) access control and asset management corresponds to the identity and endpoints pillars — Conditional Access, device compliance, least privilege. Article 21(2)(h) cryptography and encryption corresponds to the data pillar — sensitivity labels and protection. Article 21(2)(e) security in network and information systems corresponds to the infrastructure and network pillars — workload hardening and segmentation. The Azure-specific NIS2 controls are detailed in NIS2 Article 21 Azure controls.
The value of expressing NIS2 readiness as Zero Trust maturity is that it gives you a roadmap, not just a gap list. A pillar at traditional maturity is both a NIS2 weakness and a defined next increment. The maturity model orders the work.
FAQ
Is Zero Trust a product I can buy from Microsoft? No. Zero Trust is an architecture model, not a product. Microsoft provides the components — Microsoft Entra ID Conditional Access, Microsoft Intune, Microsoft Purview, Microsoft Defender for Cloud — but Zero Trust maturity is a property of how those components are configured together across the six pillars, not a licence you activate.
Which Zero Trust pillar do organisations score lowest on? Data, most commonly. Organisations invest in identity first because the tooling is visible and the wins are clear, but data classification through Microsoft Purview sensitivity labels lags. A mature identity pillar protecting unclassified, unlabelled data is the most common imbalance an Azure Zero Trust assessment finds.
Can I assess Zero Trust maturity without Microsoft Intune? Partially. The endpoints pillar depends on device-compliance signals that Microsoft Intune provides; without it, you cannot require or measure device health, so that pillar caps at a low maturity. The other five pillars can be assessed, but an endpoints gap weakens the overall posture because access is granted to unverified devices.
What does EIDSCA actually check? EIDSCA checks specific Microsoft Entra ID configuration settings against documented secure values — authentication method policies, user and group settings, consent and authorization controls, tenant-wide security options. Each control has a defined API path and expected value, which makes the identity-pillar assessment reproducible and suitable as audit evidence.
Where the assessment lands
Platform Architecture Authority reads the six-pillar signals across Microsoft Azure and Microsoft 365 — Conditional Access coverage, Microsoft Intune compliance ratios, Microsoft Purview classification rates, EIDSCA identity controls, network segmentation — and returns a per-pillar maturity rating with the NIS2 clauses each pillar answers. It is read-only and generates the remediation steps to raise a pillar’s maturity; the judgment about which pillar to prioritise for your threat model is where a senior architect adds what the tool does not. A maturity model without measurement is a slogan. Measure the pillars.
Score what you can read.
