Infrastructure Trust Framework: Completing Zero Trust

Zero Trust verifies who is asking. It never checks whether the infrastructure on the other side is fit to be trusted right now. This page maps the framework that closes that gap.

The gap Zero Trust leaves open

A verified identity can log in from a compromised laptop. A trusted admin can reach production from a host with an unpatched kernel and an exposed management port. Zero Trust waves both through. It answers who, not whether the environment is safe to act on.

That is the gap this framework exists to close. NIST SP 800-207 defines Zero Trust around continuous verification of subjects and their access. It treats device and asset posture as an input to policy — but it stops short of a portable, computed verdict on infrastructure health. Most deployments never build that piece. They verify the identity and assume the environment.

The Augustine Infrastructure Trust Framework treats infrastructure as a first-class trust dimension. It sits alongside Zero Trust, not on top of it. This page is the map. The field notes linked throughout go deeper on each piece. We unpack the gap itself in Zero Trust tells you who, it can't tell you whether.

One equation

The framework reduces to a single idea:

Identity Trust (Zero Trust) × Infrastructure Trust = Complete Trust Decision

Zero Trust governs who may act. Infrastructure Trust governs whether the environment is fit to be acted on. Neither is complete alone.

Note the operator. It is multiplication, not addition. A perfect identity times a zero-trust environment is still zero. A trusted admin on a compromised host should not get a passing grade for good credentials. The equation forces both factors to hold at once.

The decision that matters is computed where the two meet — at the moment of access, on every request. Not at onboarding. Not in last quarter's audit. At request time, against the facts as they stand now.

Two volumes: ITA and ITCM

The framework is published in two parts. Each answers a different question.

• ITA — the Infrastructure Trust Architecture. The product-agnostic, vendor-neutral architecture. It defines the principles, the trust signal, and the decision-and-enforcement model. ITA complements Zero Trust and modifies nothing in NIST 800-207. It answers what a trust verdict is and how it is decided.
• ITCM — the Infrastructure Trust Conveyance Mechanism. How a derived trust verdict travels in-band — carried with the traffic, not looked up after the fact. Any enforcement point on the path can read it and act. ITCM answers how the verdict reaches the place that enforces it. The enabling mechanism is patent-pending; this framework describes its purpose, not its internals.

Why in-band matters: an out-of-band lookup adds a round trip and a second system that can fail, lag, or disagree. If the verdict rides with the request, the enforcement point never has to ask a third party what it already holds. That is the design goal of ITCM.

Underneath both volumes sits an honest scoring model — how raw telemetry becomes a defensible verdict, and when it refuses to.

The signal: a Trust Assertion

The architecture's output is a Trust Assertion (TA) — a small, scoped, time-bound, confidence-aware verdict about one entity. It is designed to be read alongside an identity claim at decision time.

Break down the properties:

• Scoped. It speaks about one entity, not a whole fleet. One host, one verdict.
• Time-bound. It carries an expiry. A verdict from an hour ago is not assumed true now.
• Confidence-aware. It reports how sure it is. Thin telemetry yields a lower confidence, not a false green.

The TA is the portable unit the whole framework moves around. ITA produces it. ITCM conveys it. Enforcement points consume it. More on the TA as a signal in the Trust Assertion, and on what's inside the score in what the trust score actually measures.

Four commitments that make it trustworthy

The framework takes positions most scoring systems skip:

• Supportability, not age. A maintained four-year-old system can be healthier than an abandoned new one. We score whether software is supported and defended — never the date on the asset tag. A patched, vendor-supported host beats a shiny box running an end-of-life OS. Deep dive: supportability, not age.
• Unknown is an answer. When coverage is too thin to conclude, a device reads Unknown — not a flattering default. A false green is worse than no green. It tells you to go look. Unknown is an answer.
• Catastrophic findings disqualify. An unsupported OS or an exposed management surface caps the verdict, regardless of otherwise-clean vitals. A weighted average is the wrong instrument for a gunshot wound. One KEV-listed exploit should not be averaged away by good uptime.
• Trust is a trajectory. A verdict has an expiry; it is re-derived continuously as the facts move. The dangerous host is the one you trusted correctly and never looked at again — right at design time, wrong by Tuesday.

How it runs in practice

Trust is read continuously, decided against policy, enforced within human-governed bounds, and proven by closing the loop. The evidence is a by-product of the remedy, not a separate fire drill.

A concrete pass through the loop:

• Read. Telemetry from a host says its management port is exposed to a broad network range.
• Decide. Policy treats an exposed management surface as a catastrophic finding. The Trust Assertion caps.
• Enforce. The enforcement point on the path reads the capped TA and denies or quarantines the session — within bounds an operator set in advance.
• Prove. The action and its cause are logged as evidence. When the audit asks, the record already exists.

Human-governed bounds matter here. The framework does not hand the kill switch to an autonomous scorer. Operators set the thresholds; the machine acts inside them. See continuous, observed, enforced, compliance evidence, not a fire drill, and a worked example in anatomy of a trust decision.

Where to start

Adopt it the way the architecture intends — incrementally. You do not rip and replace.

• Stage one: visibility. Generate trust signals and watch. No enforcement yet. Learn what your fleet actually looks like.
• Stage two: planning. Let the signals inform decisions — patch order, segmentation, risk triage.
• Stage three: enforcement. Let verdicts shape access, within governed bounds.

Stop at any stage without losing the thread. Each stage stands on its own.

See how SAUTERA scores infrastructure trust → — or read the trust & security story for the full ITA / ITCM model.

SAUTERA™ is the reference implementation of the Augustine Infrastructure Trust Framework. Infrastructure Trust + Identity Trust — the complete trust decision.

The takeaway

Zero Trust verifies who. It does not verify whether the infrastructure is fit to be trusted right now. The Augustine Infrastructure Trust Framework closes that gap:

• The equation: Identity Trust × Infrastructure Trust = a complete decision, computed at every request.
• ITA defines the architecture and the verdict; ITCM conveys that verdict in-band to any enforcement point. Both complement NIST 800-207 without changing it.
• The Trust Assertion is the portable, scoped, time-bound, confidence-aware signal the framework moves around.
• Score supportability, not age; let Unknown be an answer; let catastrophic findings disqualify; treat trust as a trajectory with an expiry.

Start with visibility. Add planning. Then enforce — one stage at a time.

See how SAUTERA scores infrastructure trust →