Zero Trust secures execution.
IOM governs admissibility.
Zero Trust answers one question well: is this actor allowed to act? IOM answers the question that comes first — should this action happen at all, and is it what the architecture intended? Identity is necessary. It is not sufficient.
A perfectly authenticated actor can still execute an illegitimate change: a valid credential making a change no blueprint authorized, into an environment it was never meant to touch. Zero Trust verifies the who. IOM verifies the whether.
Zero Trust verifies identity.
IOM verifies legitimacy.
What admissibility adds, upstream of execution
- ✓Intent, not just identity. A change is checked against what the architecture declared — not only against who requested it.
- ✓Legitimacy before access. The action is evaluated for whether it should occur, before credentials ever reach the resource.
- ✓Blast radius as a control. The downstream impact is known and bounded before execution — not investigated after a breach.
- ✓Evidence by default. Every admitted and rejected action is recorded against the intent that authorized it.
IOM does not replace Zero Trust — it sits above it. Identity proves who is acting; admissibility proves the action is legitimate. Together they secure both the actor and the act.
Authority is declared, not assembled.
Understanding governs execution.
An IOM maintains a living model of state, intent, and legitimacy — and validates every change against it before execution. The loop is continuous, built from six components working as one.
See the full mechanism — the operating loop and six components →
Architects buy the standard. CIOs buy the economics.
Authority established before execution removes cost that is otherwise paid after it. We don’t publish a single ROI figure — the inputs are yours. Here is the lever, the mechanism, and the number you already track.
| What it reduces | Mechanism | Measure it by |
|---|---|---|
| Audit preparation | Continuous, queryable evidence instead of manual collection | Hours per audit cycle |
| Change failures | Pre-execution validation against intent and blast radius | Change-failure rate & rollbacks |
| Migration time | A living model of what exists and what depends on it | Time-to-cutover |
| Repatriation cost | Model-based moves instead of per-workload rediscovery | Effort per workload moved |
| AI enablement | Agents act within authoritative, enforceable boundaries | Share of actions safe to automate |
| Documentation effort | Documentation generated from the model, not maintained by hand | Hours maintaining docs |
A versioned, vendor-neutral specification
The IOM Standard uses RFC 2119 normative language (MUST, MUST NOT, SHOULD, MAY) to define unambiguous conformance criteria. It specifies what an IOM must provide, what it explicitly does not, and how implementations are evaluated — against the published standard, not a vendor's interpretation.
Seven mandatory requirements
Authoritative state modeling · explicit intent & blueprint governance · continuous reconciliation · pre-execution validation · explicit ownership & blast-radius awareness · automated evidence · AI-safe reasoning substrate.
See conformance requirementsEvaluate any IOM solution against the standard
A neutral, capability-based framework for assessing any solution that claims IOM capability — the criteria to require, the questions to ask, and the claims that don't qualify. No products named, no rankings.
Demonstrated, not described
Ask any solution to demonstrate each mandatory capability against your own infrastructure. If any is absent, it is not a conformant IOM.
Three ways to participate
The IOM Standard grows stronger with practitioner input. Whether you want to apply IOM in your organization, contribute to the standard's evolution, or endorse it as an industry initiative, there is a place for you.
Get the IOM starter kit
A practical guide to evaluating your organization's infrastructure governance maturity, mapping existing tools against IOM requirements, and planning a structured adoption path.
View the starter kitJoin the working group
Working group members contribute to standard refinements, conformance criteria development, and implementation guidance. Membership is open to qualified practitioners and organizations.
Apply for membershipSign the standard
Organizations and practitioners who have reviewed and validated the IOM Standard can endorse it as co-signatories — adding institutional credibility to the community initiative.
Become a co-signatory