This documentation describes AuthBox v0.3.0-133-g71cb5564.

Zero trust, with the evidence

Zero trust is easy to claim and hard to check. This page reads AuthBox against the seven tenets of NIST SP 800-207, Zero Trust Architecture (August 2020), §2.1 — the public, stable statement of what the phrase means — one tenet at a time, naming the mechanism that serves each and the part of the architecture that rules it. Every line on the product's own page that says this is pinned twice: to the tenet's own words in the document, and to the numbered rulings that make the mechanism true, each enforced by a test. Below the tenets is what the product does not do, said at the same length, and below that the DoD zero-trust register, pillar by pillar.

The seven tenets

Tenets 1 to 4: resources, channels, sessions and policy

1. All data sources and computing services are considered resources. In AuthBox a resource is whatever sits behind a door: a web application, an object store, an SSH host, a stream of labeled records. Nothing on the other side of a door is reachable except through a decision, and every route a door or the daemon mounts declares what a caller must be or hold, or the process refuses to start (the architecture's topology and request lifecycle, §4 and §6.2–6.4; plans 039, 045, 131 and 160).

2. All communication is secured regardless of network location. Mutual TLS is the only way to authenticate, on every listener, inside the perimeter or out; a request without a verified client certificate never reaches a handler. The only plain listeners are the first boot's wizard, on loopback behind a one-time token, and the static site, which carries no decision and no credential (§2, §7; plan 186 §2.7). Every listener offers a post-quantum hybrid key exchange by default.

3. Access to individual enterprise resources is granted on a per-session basis. Every request is decided, not every session: there is no session to ride. A long-lived connection is revalidated against the current trust anchors and revocation lists on an interval, and one whose certificate has been revoked stops being served mid-stream. The credential profiles are measured in hours, so a lost certificate ages out as well as being revoked (§6, §6.1; plan 059).

4. Access to resources is determined by dynamic policy. The decision reads the identity pair on the certificate, a mission the caller holds and whose window is open, and the attributes the deployment's dictionary declares — clearance, compartment, recorded key custody — in a stated precedence. A grant's window and its mission's are re-checked on every decision, so access lapses when the afternoon ends rather than when somebody remembers (§8.1, §8.3, §9.1; plan 060). The same evaluation answers over a standard AuthZEN surface, so the answer an application asks for is the answer enforcement would give.

Tenets 5 to 7: posture, enforcement and what is collected

5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. This is where AuthBox is narrowest, and says so. The one fact about an asset it holds is the custody of a key: an attestation statement is verified against the key being enrolled, recorded as an attribute a policy can require, and held across renewal, so a key a device proved was born in hardware cannot quietly move to software (§12.4, §12.10, §12.13). Hosts carry SSH certificates the same deployment signs. Device health and patch state are somebody else's system.

6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. The certificate is the login; there are no passwords. Enrollment is invitation-gated, a revoked certificate is refused at the handshake, and an operation nobody declared a requirement for is denied to everybody — omission fails closed (§7, §9.1.5, §12.1; plan 009).

7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. Every permitted request carries a signed receipt the service behind the door can check offline; every permit and every deny is a record in a hash-chained, countersigned log naming the clause that decided it; a transparency log a courier can carry out holds the chain's heads; revocations and lapses leave as shared signals to the systems that need them; and the topology view shows which authorities a box holds and how fresh each is (§13, §13.5, §13.6, §13.10, §11.4).

Where it decides, and where it enforces

Beyond the tenets, the architecture is the one 800-207 §3 draws. The daemon is the policy decision point: it holds the directory, the missions and the policy, and answers over the same evaluator whether the question arrives as a request to it, as a standard AuthZEN call (plan 053) or through a door. The doors are the enforcement points: each terminates the caller's certificate, decides, forwards to a service that knows nothing about certificates, and attaches the receipt.

What few products meet is the disconnected case the reference architecture describes. A door decides from a signed bundle the daemon publishes, not by calling the daemon per request, so with the link to the writer broken the door still decides — from data whose freshness it bounds, refusing to pretend past its budget. The edge fleet scenario stands that up, and the fleet evaluation shows it from the images: stop the writer and the replica keeps answering.

What it does not do

A zero-trust page that said less than this would be the slide the register exists to not be.

• Device posture. The only device fact AuthBox holds is attested key custody. There is no device health, compliance or patch engine; the Device pillar's rows are custody, and the register's coverage of that pillar is small on purpose.
• Analytics. AuthBox feeds a SIEM — a signed audit export the SIEM can prove it received, shared signals, metrics — and is not one. There is no behavioral risk scoring, and every Visibility and Analytics row in the register is assists.
• A door enforces only where traffic goes through it. A door is a choke point for the traffic routed to it, and nothing else. In Kubernetes a pod placed beside the door can reach the service around it unless the cluster's own network policy forbids it; the who decides page writes that caveat down. A bypass is not an eavesdrop: the door never sees traffic it does not carry, and claims nothing about it.
• Network segmentation. Macro and micro segmentation of the network itself belong to the network; AuthBox decides per request at the doors it runs.

The register, pillar by pillar

The DoD zero-trust register (docs/plans/062) maps every DoD zero-trust activity the product genuinely serves to the requirements and settings that make it true, and fails the build on a row with no evidence. Its full page, row by row, is the DoD zero-trust mapping in the accreditation package; what follows is rendered from the same register on each build, with the provenance that decides what it may say.

Provenance: every identifier, name and level in the register is checked on each build against the DoD Zero Trust Capabilities and Activities document, revision 25-T-1465, verified 2026-10-13.

AuthBox is the mechanism for 22 of those activities and supplies a piece of the other 24; the register cites 160 numbered requirements and 80 settings, and a row with no evidence cannot exist in it.