Zero trust is not something anybody sold you. It is seven tenets your architecture either satisfies or does not.
The NIST publication defines it as a model in which trust is never granted by default and has to be continually re-established. An assessment measures your architecture against those published tenets rather than against any vendor description of its own product, and that is precisely what makes the result something you can put in front of a board, an examiner or an underwriter.
- 7 tenetsThe published definition of the architecture
- 6 assumptionsAbout the network a ZTA is built on
- Per sessionHow resource access should be granted
- No implicit zoneThe private network is not trusted
The tenets describe the ideal, and the publication says so in as many words.
That one acknowledgement is what makes any of this assessable rather than aspirational, and it changes how the results ought to be read.
- The wording is that these represent the ideal goal, while acknowledging that not every tenet will be fully implemented in its purest form under any given strategy. An assessment therefore produces a position along a spectrum rather than a pass or a fail.
- That matters commercially, because this gets sold as a binary condition some product will deliver for you. It is an architectural direction carrying measurable characteristics, and knowing precisely where you sit against each tenet is considerably more useful than any certificate would be.
- It also breaks the paralysis. Companies postpone this work for years because full implementation looks unattainable. Improving three tenets meaningfully changes where you stand, and the assessment tells you which three are worth the effort in your particular estate.
- And it makes the budget conversation survivable. A board asked to fund this quite reasonably wants to know what will be different afterward. Tenet by tenet, with where you are today and where you intend to be, is an answer they can weigh and then hold you to.
Eight things an assessment establishes about your architecture.
Trust is never implicit
The whole model centers on protecting resources and on the premise that trust is never granted by default and has to be re-established continually. Every architectural decision either supports that premise or quietly undermines it, and most estates contain a generous mixture of both.
Network location alone does not imply trust
A request coming from a machine sitting on your own network has to satisfy exactly the same requirements as one arriving from a coffee shop. Any estate still treating the office network as inherently trustworthy fails this tenet outright, whatever else has been deployed alongside.
Access is granted per session
Trust in whoever is asking gets evaluated before access is granted, and what is granted is the minimum required to finish the task. Being authenticated and authorized for one resource confers nothing at all toward a different one, and that is exactly where most estates part company with the model.
Policy is dynamic, not static
Access follows a policy that moves, taking in the observable state of the identity asking, the application or service involved, and the device making the request, and it may weigh behavioral and environmental factors too, such as where somebody is, what time it is, and whether an attack is currently underway.
Asset posture is measured continuously
Every asset you own or are associated with gets its integrity and posture measured, because nothing is inherently trusted. Anything found compromised or unmanaged can be treated differently, up to and including refusing it every connection.
Authentication is a cycle, not an event
A continuous loop: obtain access, scan and assess what is threatening, adapt, and keep re-evaluating trust for as long as the conversation continues. What that expectation covers includes managing identities, credentials and access, managing assets, and multifactor authentication.
Everything is a resource
Every data source and every computing service counts as a resource, and a company may well classify personally owned devices as resources too, wherever those devices can reach company-owned ones. That framing materially changes what belongs inside the scope of the architecture.
Telemetry feeds the policy
As much information as possible gets collected about the current state of the assets, the network and the communications passing over it, and that information is used both to improve the posture and to give context to an access decision. Telemetry here is an input to a decision, not a report somebody files.
Six assumptions a zero trust architecture is built on.
Assumption
The private network is not an implicit trust zone
- What it rules out
- Treating the office LAN as safe
Assumption
Every asset behaves as though somebody hostile is already on the network
- What it rules out
- Unauthenticated internal connections
Assumption
The device may belong to somebody else entirely and be beyond your ability to configure
- What it rules out
- Assuming managed endpoints everywhere
Assumption
No resource is inherently trusted
- What it rules out
- Server-to-server trust by network position
Assumption
Subject credentials alone are insufficient for device authentication
- What it rules out
- Username and password as the whole check
Assumption
Not all enterprise resources sit on enterprise infrastructure
- What it rules out
- Perimeter thinking for cloud services
Assumption
Remote subjects cannot fully trust their local network
- What it rules out
- Trusting home and public networks
Assumption
Assets keep a consistent posture when they move
- What it rules out
- Different rules on and off the network
Four things that make a zero trust assessment useful.
The assessment runs against the published tenets rather than any vendor model
Seven tenets and six network assumptions, each given a position with evidence behind it. A vendor maturity model is built around what that vendor sells, which makes it genuinely useful for planning a purchase and entirely unsuitable for assessing an architecture.
We look for implicit trust zones specifically
The publication states plainly that the zone of implicit trust must be as small as it can be for enforcement to be specific. Finding those zones and measuring them is the most direct route to seeing where an estate diverges from the model.
We accept that full implementation is not the goal
The tenets are described as an ideal, with an explicit acknowledgement that not all of them will be implemented in their purest form anywhere. An assessment treating anything short of perfection as a failure produces a report nobody can do anything with.
We map existing investment to the tenets it supports
Most companies have already bought several products that genuinely move one or two tenets forward. Showing which products those are, and which tenets nothing at all currently touches, usually turns the conversation away from spending more and toward sequencing better.
Four phases across roughly eight to twelve weeks.
- 01Weeks 1 to 3
Establish the current architecture
Where identity gets decided, where policy is evaluated, where it is enforced, and what the company genuinely knows about the posture of its assets. The published logical components give that a structure comparable from one estate to another.
- Policy decision and enforcement points identified
- Identity and asset management inventory documented
- Implicit trust zones located and sized
- Telemetry sources mapped against policy inputs
- 02Weeks 4 to 6
Assess against the tenets and assumptions
All seven tenets given a position with evidence behind it, and all six network assumptions tested against how the estate is genuinely built rather than how it was drawn. What comes out is a picture rather than a score, since the tenets describe an ideal.
- Position per tenet with supporting evidence
- Network assumptions tested against the design
- Contradictions identified where design fights the model
- Quick wins separated from structural work
- 03Weeks 7 to 9
Prioritize by risk and feasibility
No two estates should spend equally on every tenet. Unauthorized movement sideways is called out in the publication as among the biggest challenges, so the tenets constraining it usually rank near the top, but the ordering follows your own architecture rather than a template somebody wrote.
- Tenets prioritized by risk reduction and feasibility
- Dependencies between improvements sequenced
- Existing investments mapped to tenets they support
- Target position defined per tenet
- 04Weeks 10 to 12
Roadmap and governance
A plan that is both funded and sequenced, alongside a way of measuring progress that is not somebody vendor dashboard. This work stretches across years, which makes how you measure it matter every bit as much as the first round of changes.
- Roadmap with sequencing and owners
- Measurement approach per tenet defined
- Board-level summary framed around the tenets
- Reassessment cadence agreed
Six situations that prompt an assessment.
A regulated firm asked to evidence its architecture
Examiners, auditors and frameworks from NYDFS Part 500 through to CMMC now routinely ask how access decisions get made and whether sitting on a particular network confers any trust. An assessment against the published tenets is a far stronger answer than a list of products with the phrase somewhere in their marketing material.
A board asking what the program delivered
These programs consume real budget across several years. A position against each tenet, taken before and after, gives a board something to weigh that is neither an inventory of products nor a reassurance from the team who spent the money.
An organization that suffered lateral movement
Unauthorized movement sideways is identified in the publication as among the biggest challenges, and the tenets are shaped specifically against it. Following an incident that involved somebody moving between systems, those tenets provide a structured way to frame the remediation, and one your insurer will recognize immediately.
A business moving substantially to cloud services
Not every resource a company depends on sits on infrastructure that company owns, and anything moving between environments ought to carry the same policy and posture with it. Migrating to the cloud is where assumptions about a perimeter break most visibly and most expensively.
An operation with unmanaged and third party devices
A device on your network may belong to somebody else entirely and be beyond your ability to configure, and the model assumes exactly that from the outset. Estates carrying contractors, visitors and operational technology need policy that accounts for those devices rather than a growing pile of exceptions that route around the problem.
A team whose policy cannot see device posture
Policy is meant to weigh the observable state of the device making the request. Where an access decision rests on identity and nothing else, that is a specific and entirely fixable gap rather than a vague shortfall in maturity.
How US organizations describe their zero trust position.
| Feature | Assessed against the tenets | Bought a zero trust product | Perimeter architecture |
|---|---|---|---|
Position known per tenet | Evidenced | Assumed | Not applicable |
Internal network treated as trusted | No | Often still yes | Yes |
Access granted per session | Assessed | Partially | No |
Device posture in policy | Yes | Sometimes | No |
Implicit trust zone size known | Measured | Not considered | Large |
Decision and enforcement separated | Mapped | Vendor dependent | Not applicable |
Lateral movement constrained | Deliberately | Partially | Poorly |
Roadmap tied to risk | Yes | Product driven | None |
Board can evaluate progress | Tenet by tenet | By spend | Not discussed |
Effort to reach | Weeks to assess, years to build | Procurement | None |
Ask who takes the decision, who carries it out, and where the record of it ends up.
The logical components give an assessment something concrete to test against, and a great many estates cannot answer those three questions cleanly at all.
- The policy engine holds the final decision on whether a given subject reaches a given resource, and it both makes that decision and records it as approved or refused. In a real estate that decision is usually scattered across several systems with no single record of it anywhere.
- The policy administrator opens or closes the path between subject and resource by instructing the enforcement points, carrying out whatever the engine decided. Where nothing in the estate performs that role, revoking access tends to be theoretical rather than actual.
- The enforcement points are where any of this becomes real. Moving them nearer the resource is what shrinks the zone of implicit trust, and the publication states explicitly that the zone must be as small as it can be for enforcement to be specific rather than approximate.
- The components talk to one another on a control plane kept separate from the one carrying application data. An estate where policy and data share a path has a structural weakness that no quantity of policy configuration will ever compensate for.
Five steps, anchored on published text throughout.
- 1
Map decision, administration, and enforcement
Where the final access decision gets made and recorded, what actually opens and closes communication paths, and how close enforcement sits to the resources themselves. Those three roles give the assessment a structure comparable from one estate to the next.
- 2
Locate and size the implicit trust zones
Every region where things are trusted purely by virtue of having passed the last enforcement point. The publication says that zone must be as small as possible, so locating the large ones tells you precisely where the architecture strays furthest from the model.
- 3
Assess each tenet with evidence
What counts as a resource, securing communication regardless of where it originates, granting access per session, policy that moves, posture measured continuously, authentication enforced dynamically and strictly, and telemetry feeding back into the posture. Assessed on evidence rather than on what somebody says about themselves.
- 4
Test the six network assumptions against the design
Whether the internal network is still treated as inherently trustworthy, whether unmanaged devices have been accounted for at all, whether somebody credentials alone are being relied on to authenticate a device, and whether posture actually travels with an asset that moves.
- 5
Sequence a roadmap the business can fund
Ordered by how much risk each removes and how achievable it is, with everything already bought mapped against the tenets it genuinely supports, a target position set for each tenet, and a way of measuring progress that does not depend on one vendor dashboard staying green.
What organizations ask about zero trust.
Fifteen questions that reveal your real position.
Trust and location
- Is the office network treated as trusted?Location alone should not imply trust.
- Do internal connections authenticate?Assume an attacker is present.
- Is traffic encrypted internally?Most secure manner available.
- How large is the implicit trust zone?It should be as small as possible.
- Do servers trust each other by subnet?No resource is inherently trusted.
Access decisions
- Is access granted per session?Not once per login.
- Does one resource grant imply another?It should not.
- Does policy use device posture?A named policy input.
- Is MFA in place for enterprise resources?An expected component.
- Is trust re-evaluated during a session?A constant cycle.
Visibility
- Do we measure asset posture continuously?All owned and associated assets.
- Can we deny an unmanaged device?A documented option.
- Does telemetry feed policy?Not just reporting.
- Is every access decision logged?The engine makes and logs it.
- Can we revoke a live session?The administrator executes it.
Ask whether a request from your office network is treated differently from the same request elsewhere.
If it is, network location is still conferring trust, and that is the second tenet. It is also the most common place an estate departs from the model.
Related Services
Explore more solutions that work great with this service
Access Rights Review and Certification
Recurring access certification your auditors accept
Learn moreMicrosoft Entra
Identity and access management solutions
Learn moreMITRE ATT&CK Coverage Assessment
Detection coverage assessment for US organizations mapped to MITRE
Learn moreTenant Security Baseline
Documented controls mapped to CIS
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn more