AuthBox
Need-to-know, from one box to the whole network

Access by mission. Data by marking.
Everywhere you run.

AuthBox is the identity and authorization server for organizations that hand out access by need-to-know. A certificate says who you are; a mission says why you are here; a marking says what may leave.

How it fits

It plugs into the enterprise you already run — a directory over LDAP, provisioning over SCIM, single sign-on over SAML and OIDC, your own certificate authority — or stands up a new organization in a box. One box runs alone or airgapped; many chain into a federation, each deciding for itself. Every decision is denied by default and signed.

Start here See the evidence Request a demo
AuthBox — secure by design, connected by nature.
Issuer
CN=demo-org rehearsal issuing,O=example,C=US
Subject
CN=Gallagher Jana B jbgalla1,OU=D11,O=example,C=US
Clearance
SECRET · compartment CONTINENTAL
Missions
field-operations, read-directory
Mutual TLSCMVP #5247fips140=onlyDeny by default

An identity is the (issuer, subject) pair on a certificate — nothing else. The example is fictional: O=example.

How it works

One question, asked the same way everywhere.

How AuthBox works, on one page: the entity, the mission, the marking, the door and the receipt, and the one rule that joins them.
Secure by design — the refusals

The safest features are the ones it doesn't have.

Most of what makes AuthBox trustworthy is what it declines to do, and each refusal below is pinned by a test.

passwords.

Mutual TLS is the only login.

How it holds

A client without a certificate this deployment issued or trusts never completes the handshake.

phone-home.

Nothing reaches out to us — not for updates, not for revocation.

How it holds

Not for a typeface either. The only addresses it dials are ones you configured.

silent allow.

An operation that declares no requirement denies everybody.

How it holds

A mission that does not exist is refused exactly like one the caller may not know exists.

trusted peer by default.

Another authority is adopted by signed bundle, or not at all.

How it holds

A partner's certificate can complete a handshake and still be refused at authorization. Handshake is not entitlement.

Isolation ∕ chained

One box, or a federation of them. Same binary.

One server by itself: the console, the certificate authority, the directory and the signed log in one box, and people to log in as.AUTHBOXCADIRLOGconsole

Alone.

See the poster
One box: the directory and its policy decision point, the certificate authority, the console and LDAPS, the signed audit chain — every capability in one sealed instance, no network required.
Chained: headquarters publishes a signed bundle to a region, which republishes it to an enclave; every hop keeps the origin and each keeps deciding for itself.HQREGIONENCLAVEorigin survives every hop

Chained.

See the poster
Chained: HQ publishes a signed bundle, a region adopts and republishes it, an enclave adopts it; a partner's trust anchor is appended to the pool without its data being believed; origin survives every hop and freshness is budgeted.
The shapes people deploy

Choose the shape first. It is the same binary in every one.

Eleven deployments, each a topology this product stands up and proves. One rule runs through all of them: a door per authority, never a door per process.

Who decides, and where the door goes →
One proxy: a subject's request passes a door that decides and signs a receipt before it reaches a service that knows nothing about certificates.DOORSERVICEno certs

One proxy

A door in front of a service that knows nothing about certificates.

How it works

The service need not change: the caller's identity arrives verified, and every request carries a receipt, a signed record of the decision that let it through.

One authorizing proxy in front of three services: the caller's certificate ends at the proxy, which decides and forwards; the same proxy fronts one service, many services told apart by name, or a whole Kubernetes cluster, reading its routes from Service annotations
Read the scenario →
An edge fleet: a central server publishes signed bundles to doors at the edge, and each door decides from the bundle it holds.AUTHBOXcenterdecidesdecidesdecides

Edge fleet

Doors at the edge deciding from signed bundles; the center may be unreachable.

How it works

One AuthBox in the middle, proxies and read-only replicas at the edges. Each decides from the bundle it holds, so an outage at the center is not one at the door.

A central AuthBox publishes signed bundles outward to three edge boxes — two proxies and a read-only replica — each of which decides there; thin dotted arrows carry receipts back to the center
Read the scenario →
Your own certificate authority for a team: the root stays on one host, and certificates go out by invitation.one hostCAinvited

Team CA

Your own certificate authority, issuing by invitation, revoking by list.

How it works

For a team with no PKI. The first boot stands up the authority and asks for your vocabulary, companions and corporate services; the root never leaves the host.

One host: the first-boot wizard on the loopback address leads to a certificate authority, then to invitations, then to a console — every step on the same machine, and the root never leaves it
Read the scenario →
Two organizations that trust each other: each keeps its own authority, and a signed bundle carries one's people to the other, where they are decided.org Aorg Bdecided here

Federation

Organizations adopt each other's signed authority; a person issued there is decided here.

How it works

For organizations that must work together and cannot merge their directories. Each keeps its own authority, and every record carries its origin.

A chain of authorities: headquarters publishes a signed bundle to a region, which republishes to an enclave, and every bundle carries an origin mark; a side lab on the other diagonal keeps its own authority, with its root appended to the trust pool rather than its data adopted
Read the scenario →
Your organization: the directory, the PKI and the mail relay you already run feed one server that adopts what they say, and doors decide from it.dirPKImailAUTHBOXadopts

Existing organization

Your directory, PKI and mail relay in; decisions out.

How it works

For an organization that already has all three. AuthBox adopts what they say and owns none of it.

Three sources on the left — a directory of people and groups, a PKI with its root and CRL, and a mail relay — send arrows into a central AuthBox marked adopts, never owns; from there, arrows carrying small envelope marks fan out to two edge proxies, each deciding locally, and one of the proxies stands in front of a service
Read the scenario →
A card from another authority: the certificate a person already carries, issued by a PKI this box never ran, admitted at the door by the policy it asserts.cardDOORAUTHBOXissues none

Smart cards

Sign in with the card you already carry; this box issues nothing.

How it works

For people who hold a PIV or CAC card. The door admits the card’s sign-in certificate, refuses its signature certificate, and checks the issuer’s own list.

The card at the door: a person presents the card's certificate; the door admits it only with the authentication policy, refuses the same card's signature certificate, checks it against the issuer's own list — fetched ahead of time from the address the certificate names — and the decision leaves a record an administrator can place in a group.A CARD FROM ANOTHER AUTHORITYAND WHAT THE DOOR LEAVESTHEIR ID CAa PKI this box never ranTHEIR LISTwhere the card pointsfetched ahead, never in the handshakethe cardPIV auth policyDOORits signature certificate: refusedAUTHBOXissued nothingRECORDfirst seenan admin adds a group
Read the scenario →
The card you already carry: a real CAC or PIV card, admitted at the door under its own authority's certificates, whose revocation lists the box fetches.your cardDOORAUTHBOXfetches their lists

Your own card

A real CAC or PIV card, under its own authority; the box issues nothing.

How it works

The image carries the DoD and Treasury PKIs’ certificates as issuer sets and fetches their lists; bring your card and you are recorded.

Read the scenario →
The agent as a card: the credential this box issued to your computer, shown to the operating system as a smart card in a reader, so the browser and ssh present it at the door as they would a real one.AGENTits own credentialREADERvirtualDOOR

The agent as a card

Your computer’s credential, shown to Linux as a smart card.

How it works

For a person with no card: a PIV card behind a PIN you set; the key stays in the store.

Read the scenario →
A labeled feed: one producer sends records through a door that reads each label and never the body; a record reaches only the service cleared for it.feedclearednot cleared

Labeled feed

Each record reaches only the services cleared for its label; the door never opens one.

How it works

For a feed with two destinations cleared to different levels. The door decides on each record's label alone.

One producer holds a single long-lived connection to a front door, which reads the label on each record and never its body; two arrows leave the door, each carrying a signed batch receipt, to two ingest services — one cleared for SECRET, one cleared for CONFIDENTIAL — and a record labeled SECRET reaches the first and never the second, where the refusal is recorded
Read the scenario →
Classified records: an application labels every answer, and the door hands a record whole to a reader cleared for it and refuses it to one who is not.APPSCU

Classified records

The application labels every answer; the door refuses whole what the caller is not cleared for.

How it works

For an application whose records are not all for one audience. It never decides anything itself.

Two people ask the same front door for the same six records; the application behind the door answers each request with a label naming that record's classification and never decides anything itself; the door compares the label against what each person is cleared for, so the person cleared for everything receives all six records with a receipt naming what was compared, and the person cleared only to the lowest level receives two of them and a plain refusal for the rest, with the reason only in the log
Read the scenario →
Sealed records: a file sealed once can be copied anywhere and read by nobody; a key door releases the key only to a person cleared for it.copiesKEY

Sealed records

A file that stays classified after it is copied: a door holds the key.

How it works

For records that must stay classified after they leave you. Anybody can copy one and nobody can read it without that key.

One classified file is sealed once and then copied everywhere — a laptop, a backup, a partner's share — and every copy is unreadable on its own; two people ask a key door for the key that opens it, and the door asks the same directory that decides everything else here: the cleared person receives the key and reads the file, the person who is not cleared is refused and holds only ciphertext, and the door itself never sees the file and keeps no copy of any key
Read the scenario →
Logging in: a person asks the server for a certificate that expires in hours, and it opens the accounts this deployment's policy allows on each host.SSH CAhostnode

SSH

Host and user certificates from one authority; a login is a decision.

How it works

Who may log in to which machine, and as which account, is this deployment's own policy. No key is copied anywhere.

One person holding a single key asks AuthBox, which reads the same groups and missions as everything else and works out which accounts they may use; the certificate it returns expires in hours and is renewed while they work; it opens the deploy account on two servers and the node-admin account on a cluster node, each of which needed only two lines added to the configuration it already had, and the root account is refused
Read the scenario →
A certificate for a service: the key is born on the service that uses it, and the server issues the certificate for the names its project owns.AUTHBOXissuesSERVICErenewed

A certificate for a service

A service's own certificate; the key is born where it is used and never handed over.

How it works

For a web server, a test site or a mission’s API. The project owns the identity.

A project admin creates a service identity from the workspace; AuthBox derives the name, bounds it to the hostnames the project published and mints one enrollment token, issuing no key of its own; the key is then born in one of three places — an ACME client on the server itself, the door that fronts the site, or the courier, which hands it over once and forgets it — and a download of a key AuthBox generated is not offered at all
Read the scenario →
Where it runs: the same binary on a laptop with the cable out, in a compose file, or across a cluster.laptopcomposecluster

Where it runs

A laptop with the cable out, one host, a compose file, a cluster; the same binary in all of them.

Read the scenario →
Capabilities — shipped and tested

What's in the box.

Every capability below is in the binary today, each proven by a named test. Nothing here is a roadmap.

Directory

Entities, projects, missions

Authorization is membership, intersected with a mission, intersected with attributes.

How it works

People, services and projects; a mission is a named job someone holds. A mission or a record you are not cleared for is absent rather than forbidden.

PKI

Certificate authority

Issues, renews, rotates and revokes.

How it works

A partner's root is appended to the trust pool, its data never adopted.

Federation

Signed authority bundles

One writer's truth, carried to doors that decide offline.

How it works

Snapshots published on a cadence, each with a freshness budget, and origin that survives every hop.

Console

Server-rendered, scripting optional

Every page works with JavaScript off.

How it works

WCAG 2.1 AA and Section 508, checked rather than asserted.

Portal

The person's own door

For the people the console is not for: their own missions, requests and agreements.

Questions

Ask before a door does

Would this person pass, and why not. Can they? →

Access

Just-in-time grants

Brokered through approvers, granted for a window.

How it works

Live only once the requester accepts with their own key.

Policy

Obligations over a population

Standing conditions — training currency, a signed MOU — reported across a group as a fleet.

Audit

A provable decision record

Every permit and every deny in a hash-chained, countersigned log, with the clause that decided it.

Integrations — what it works with

It fits what you already run.

Each is in the binary, switched on by a setting, and proven by a named test. What your systems send is verified before it is read; what AuthBox decides never leaves as a claim.

Sign-in for your applications

OpenID Connect and SAML

What it covers

Your web applications log people in with the certificate they already hold. An OpenID Connect provider with PKCE and certificate-bound tokens; a SAML 2.0 identity provider for the applications that speak nothing newer. SAML, explained →

Provisioning

SCIM, LDAP and Active Directory

What it covers

Joiners and leavers arrive from the system that already knows them: a SCIM 2.0 adapter pulling from a directory or pushed from Okta or Entra, an LDAP connector for Active Directory. Each runs outside and produces one signed bundle.

Certificates and hardware

ACME, EST, OCSP, CRLs, HSMs

What it covers

Enroll servers over ACME with device attestation, or devices over EST. Revocation over OCSP and CRLs. Keys in a PKCS#11 hardware module, and post-quantum ML-DSA certificates beside the classical set.

Policy and signals

AuthZEN, Rego, Cedar, CAEP

What it covers

Ask the decision as an API (OpenID AuthZEN), export the policy as Rego or Cedar for your engine, and let other systems learn of revocations and lapses as shared signals (CAEP). Or take those answers in your own API's shape, from your OpenAPI document and a mapping proved at load.

Data and labels

OpenTDF, STANAG 4774

What it covers

Classified responses labeled per request and sealed to a key access service that releases a data key only to a caller cleared for it; NATO confidentiality labels translated at the seam rather than re-modeled.

Object storage

S3, sealed, per mission

A separate add-on that holds the files so AuthBox never does. A bucket is a mission ↓

Shell and infrastructure

SSH, Kubernetes, DNS

What it covers

An SSH certificate authority for your hosts and cluster nodes, SSH through the door by name, an ingress mode that follows your Kubernetes Services, and authoritative DNS with DNSSEC for a federation's names. SSH, explained →

Operations

Prometheus, your SIEM, PostgreSQL

What it covers

Metrics in Prometheus form, structured logs, a signed audit export your SIEM can prove it received, a transparency log, and a store on files, PostgreSQL or MySQL.

Every setting behind these, and the test that proves each one, is in the support matrix.

Object storage — a separate add-on

A bucket is a mission.

An S3-compatible store beside the box, where the address is the marking.

The store's levels: an address names a level, a project and a mission, and a mission is a shelf; at a sealed level an object is ciphertext, opened by the key door only for a holder of that mission.THE LEVELSAND THE SHELVES ON EACHA LEVELgenerala missiona missionA HIGHER ONEgenerala missiona missionA SEALED ONEgenerala missiona missionKEY DOORholdersonly
ONE ADDRESS AND WHAT DECIDES EACH PART OF IT /s/us.authbox.store/general-s/plan.txt LEVEL PROJECT MISSION KEY dictionary group DN the portal you nothing here was configured twice · nothing here is a policy beside the object
Address

The address is the marking

How it works

A level, a project, a mission — read off the address, not out of a policy written beside it.

Shelves

A bucket is a mission

How it works

Author one in the portal and its storage exists, held by exactly its holders.

At rest

Sealed per mission

How it works

An object at a sealed level is ciphertext, opened by the key access door only for a holder of that mission.

Mutual TLS only, no presigned links, one bound per object — and the store never writes a mission.

How a shelf works

Its own binary and image, deployed beside the box. The general shelves are seeded missions, held by everyone this authority holds, and a copied volume opens for nobody.

The file store, a level deeper: the key access door, the object store, and a shelf sealed per mission.
Filing a file → How a sealed file travels →
The posters

Every picture, one product.

How AuthBox works — the model on one page One box — every capability in one place Chained — a federation of boxes, same binary The front door — marked routes and streams Missions, projects, brokerage and agreements Login with AuthBox — OIDC, SAML, SCIM, LDAPS PKI — certificates, custody and the SSH authority The file store — sealed per mission Federation — bundles, regions, enclaves and names Evidence — the audit chain, receipts and the register
Next to what you already run

Four things it is mistaken for.

THE SAME REQUEST MEETS AND AFTERWARDS IT CAN PROVE SERVICE MESH workload to workload WHICH WORKLOAD CALLED not who was behind it IDENTITY PROVIDER at sign-in WHO SIGNED IN, ONCE at the start, then it stops INGRESS CONTROLLER terminates and routes NOTHING ABOUT WHO it forwards, by design AUTHBOX per request THIS REQUEST, DECIDED a receipt anyone can check

Each is the better tool for the job it was built for, and this replaces none of them. The difference is the axis above: what can be proved afterwards, by somebody who was not there.

How it compares, one by one →
Evidence — not assertion

Every claim is a numbered ruling with a test behind it.

AuthBox is built for the people who sign the authorization to operate.

Cryptography
FIPS 140-3

In the FIPS build: Go's native FIPS module, CMVP certificate #5247, under fips140=only. Non-approved algorithms cannot be selected.

Rulings
746+

Numbered requirements, each enforced by a named test; 991 declared mutations, applied by the gate to prove they bite.

Posture
Deny

By default, everywhere. An undeclared operation denies everybody, so nothing is permitted by omission.

Package
OSCAL

The control catalog as a component for a FedRAMP-shaped system security plan.

The FIPS build is the default; the open build is the same product without that claim.

How a build proves itself

Every normative decision is a numbered ruling in a register with the test that enforces it, so a rule refactored away fails the build. The register is public; the source it cites goes to a licensee on request.

The FIPS build's mode is compiled in, and the process refuses to start under any other; the operator guide's two postures page says which build to take.

A release says how it was built, and the media verifies itself. A signed in-toto statement carrying SLSA Provenance v1 rides with the artifacts, sealed by one offline key, and the verifier on the media checks it offline.

Nothing is fetched while it builds, and every piece of somebody else's code carries its license and a reason in a register the gate checks.

Evidence, a level deeper: the audit chain, the receipts a caller keeps, and the proved register behind every claim.

The evidence register, capability by capability →

See a day of it →

Everything a deployment changes is data →

Zero trust — the evidence, not the slide

Seven tenets. Seven mechanisms.

NIST SP 800-207's tenets, each pinned to the rulings that prove it here.

WHERE IT DECIDES AND WHERE IT ENFORCES THE DECISION POINT the AuthBox daemon · AuthZEN signed bundle writer unreachable: the door still decides SUBJECT a certificate THE DOOR enforcement point + receipt SERVICE knows nothing EVERY DECISION LEAVES A SIGNED RECORD
  1. All resources sit behind a door, reached only through a decision.
  2. Secured regardless of network location: mutual TLS is the only login.
  3. Granted per-session and per request; live connections revalidated.
  4. Dynamic policy: identity, a mission in its window, clearance and compartment.
  5. Integrity and security posture: a key's attested custody, recorded and enforced.
  6. Dynamic and strictly enforced before access: an undeclared operation denies everybody.
  7. Collects as much information as each decision yields: signed receipts, a chained log.

What it does not do: no device posture beyond attested key custody; your SIEM fed, not replaced; and a door enforces only where traffic passes it — in Kubernetes, a pod beside it can bypass it.

Pillars
7 of 7

Of the DoD framework's.

Activities
46

22 provided by AuthBox itself.

Target level
36 of 91

Of the framework's Target activities.

Rulings cited
160

Each with a named test.

Tenet by tenet, pillar by pillar →

Get it running

Pull one image and run it. Offline by design.

authboxus/authbox-eval -evaluate stands up a box with a console and four people to log in as, in one command. The image prints the recipe for the rest — a front door, the companions, a fleet, a federation — and with -website serves this site offline.

Source to a licensee on request, images to anybody.

A deployment of your own

For your own deployment, the released authboxus/authbox's first-boot wizard writes your configuration and starts the box on it. Production ships as images, a static binary, or systemd, compose and Kubernetes manifests; an airgapped install copies it in by hand.

Start here Browse the documentation