Zero Trust Isn’t a Product You Buy. It’s an Architecture You Document — and Keep From Drifting.

Zero trust on Azure is a set of architectural decisions — about identity, segmentation, device trust, and least privilege — that you have to design, document, and then keep accurate as the environment changes. It is not a product you switch on, and it is not a maturity badge you earn once. The recurring failure is treating it as either: buying the tools that enable zero trust, configuring some of them, and assuming the architecture now exists because the licences do. The architecture exists only when the design is deliberate and the documentation of that design is current. Both parts drift.

CISA’s guidance frames zero trust as a journey for exactly this reason — it is the continuous work of moving an architecture toward a model where no implicit trust is granted by network location, and every access decision is evaluated against identity, device, and context. That guidance is written for US federal agencies, but the architectural substance is the same one a NIS2 or DORA examiner in the Netherlands is now asking Dutch organisations to evidence. The framing to localise is the obligation, not the model.

Key takeaways

• Zero trust is an architecture, not a purchase. Microsoft Entra, Conditional Access, and microsegmentation are the components that enable it; the architecture is the deliberate design that connects them, plus the documented reasoning.
• The evidence a supervisor wants is the design rationale — why this segmentation, why these Conditional Access policies, why these trust boundaries — not a screenshot of a feature being enabled.
• Zero trust architecture drifts like any other. A Conditional Access exclusion added under delivery pressure, a new workload stood up outside the segmentation model, a trust boundary quietly widened — each erodes the documented design without anyone deciding to.
• Under the Cyberbeveiligingswet (the Dutch transposition of NIS2) and DORA, the relevant question is not “do you have zero trust products” but “can you show the architecture, the reasoning, and that it still reflects what is running.”
• The defensible position is a documented zero trust architecture with a maintenance loop — not a maturity score captured once and left to age.

The category error: tools that enable versus an architecture that exists

Walk into most Azure environments that describe themselves as “doing zero trust” and you will find the enabling components present and partially configured. Conditional Access policies exist. Microsoft Entra ID handles authentication. Some microsegmentation is in place. Privileged Identity Management is licensed. Every one of those is a zero trust enabler, and a team can point at all of them and reasonably believe the architecture is in place.

It is not — not yet — because zero trust is not the sum of its enabling features. It is the deliberate design that decides where the trust boundaries sit, what each access decision evaluates, how identity and device posture combine, and why. Conditional Access with a policy that enforces MFA but excludes a service-account group containing human accounts is not zero trust; it is a feature that is switched on with a hole in it. The hole is an architectural decision — usually an undocumented, unintentional one — and zero trust lives precisely at the level of those decisions.

The category error costs you in the audit, not the breach. An examiner does not ask whether Conditional Access is enabled. They ask what your access model is, why it is designed that way, and where the exceptions are. “We have Conditional Access” is a feature answer to an architecture question.

What “document the architecture” actually means here

Documenting a zero trust architecture is not writing a policy document that says you follow zero trust principles. It is recording the design decisions specifically enough that someone — an auditor, a new architect, your own team in eighteen months — can see what was decided and why.

Concretely, for an Azure environment, that means the trust boundaries are mapped: which network segments exist, what crosses them, and what is explicitly denied. It means the Conditional Access design is documented as a model, not just a list of enabled policies — what each policy is protecting, what it evaluates, and which exclusions exist and why each one was accepted. It means the identity architecture is written down: how privileged access is granted just-in-time through PIM and Conditional Access, how device trust feeds the access decision, where least privilege is enforced and where it was knowingly relaxed. And it means each significant decision carries its reasoning, in the form of an architecture decision record, so the why survives the person who made it.

This is the artifact that holds up under scrutiny. Not because it proves the architecture is perfect — it usually surfaces accepted compromises — but because it shows the design was deliberate and the reasoning is available. A documented accepted risk is a defensible position. An undocumented one is just a gap nobody noticed.

Why a zero trust architecture drifts

Here is the part a point-in-time maturity score misses. You can design a clean zero trust architecture, document it properly, and score well — and the architecture begins drifting away from the documentation the moment the environment continues to change, which is immediately.

The mechanisms are mundane. A platform engineer adds a Conditional Access exclusion to unblock a deployment at 17:00 on a Friday, intending to remove it Monday, and the exclusion is still there at the next audit — a hole in the access model that the documentation does not reflect. A new workload is stood up quickly and lands outside the segmentation design, reachable from a network it should never have been reachable from. A trust boundary widens by one rule, then another, until the segmentation that the architecture document describes is not the segmentation that is running. None of these is a decision to abandon zero trust. Each is configuration drifting away from the intended design, and the cumulative effect is an architecture that no longer matches its own evidence.

A Zero Trust maturity assessment is the right way to establish where you stand — it scores each pillar against concrete signals and gives you a target state to design toward. But a score captured once is a baseline, not a control. It tells you where you were on the day it ran. Six months later the gap between the documented architecture and the running one is invisible until someone — ideally you, not an examiner — goes looking. The maturity assessment tells you where to get to. The maintenance loop is what keeps you there.

The Dutch regulatory frame: design rationale, not feature inventory

Under the Cyberbeveiligingswet and, for financial entities, DORA, the supervisory question about access control and segmentation is an architecture question. NIS2 Article 21 requires access control and asset management measures that are appropriate and proportionate to the risk — and a Dutch supervisor evaluates the actual design and its evidence, not a list of Microsoft products in your tenant. The relevant standard is whether your architecture is defensible and demonstrable, which is precisely the standard zero trust documentation is built to meet.

This is why localising CISA’s “journey” framing is the right move rather than citing it directly. The continuous-improvement model is sound and transferable; the obligation it should be attached to, for a Dutch reader, is the Cyberbeveiligingswet and DORA, not a US TIC initiative. The architecture is the same. The supervisor asking for evidence of it is Dutch, and the deadline is real. (For the broader Article 21 control set this sits inside, see the NIS2 Article 21 Azure controls.)

Building the maintenance loop

A defensible zero trust architecture has three properties: it is designed deliberately, it is documented with its reasoning, and the documentation is kept current against what is actually running. The first two are a project. The third is a loop, and the loop is what most organisations are missing.

The loop is a recurring comparison between the documented architecture and the live environment: have new Conditional Access exclusions appeared, has anything been deployed outside the segmentation model, has a trust boundary widened, has privileged access stopped flowing through just-in-time activation? Each of those is a design-level regression, and catching it is a different exercise from catching a misconfigured resource — it requires assessing the architecture as a system, not scanning resources individually.

This is the work Platform Architecture Authority (PAA) is built to make repeatable. PAA reads your Azure configuration through Resource Graph, assesses the access, identity, and segmentation design against the Well-Architected Framework, maps it to NIS2, DORA, and ISO 27001 Annex A, and generates the architecture decision records and the gap analysis — so the documented zero trust architecture exists as structured evidence rather than a slide, and re-running it shows where the live environment has drifted from it. PAA does not make the access decisions or write the security policy; a human owns the design and the accepted risks. What it does is make sure the architecture and its evidence stay in sync, which is the part that quietly fails on its own. PAA is read-only.

FAQ

Can I buy zero trust as a product? No. You can buy the components that enable it — Microsoft Entra, Conditional Access, microsegmentation, PIM — but zero trust is the deliberate architecture that connects them and the documented reasoning behind the design. Enabling the features is necessary and not sufficient; the architecture exists only when the design is intentional and recorded.

What evidence does a NIS2 supervisor want for access control? The design rationale, not a feature inventory. What your access and segmentation model is, why it is designed that way, where the exceptions are and why each was accepted — mapped to the relevant controls. A list of enabled Microsoft products is a feature answer to an architecture question.

How does a zero trust architecture drift? Through ordinary change: a Conditional Access exclusion added to unblock a deployment and never removed, a workload stood up outside the segmentation model, a trust boundary widened one rule at a time. None is a decision to abandon the model; together they pull the running architecture away from its documentation until the evidence no longer matches reality.

Isn’t a zero trust maturity assessment enough? A maturity assessment tells you where you were the day it ran. It is a useful baseline and a poor control, because the architecture drifts continuously afterward and a one-time score does not catch design-level regressions. The defensible position is a documented architecture plus a maintenance loop that re-checks the design against what is actually running.

The question worth asking your team this week is narrow and revealing: when did the document that describes our access and segmentation model last match what is actually deployed? If the honest answer is “at the last assessment, and I’m not sure since,” the architecture has been drifting in the dark — and that gap is the one a supervisor is most likely to find first.