Minimize a Trusted Computing Base

System and boundaries

Choose one claim. Example: only an authenticated employee with the production-reader role can open the production dashboard, and no direct network path can bypass the decision.

State the protected resource, action, subject, security property, adversary capability, allowed failure, and required evidence. Draw the complete path from identity proof and group lifecycle through policy configuration, request routing, decision, enforcement, upstream identity, object authorization, logs, and recovery.

Mark a component as trusted when its failure can violate the claim. Include:

• Identity provider, group and account lifecycle, device evidence, and clocks.
• DNS, certificates, keys, secret stores, and cryptographic libraries.
• Gateway code, configuration, policy engine, session state, and enforcement process.
• Host kernel, runtime, image, control plane, network policy, and direct upstream boundary.
• CI, artifact registry, deployment identity, update mechanism, and administrators.
• Logging, monitoring, backup, restore, break-glass, and incident response.
• Upstream code and data systems for any object-level claim.

Use a different TCB map for each security property. Availability can depend on components that do not hold confidentiality authority. Audit integrity can depend on storage and clocks outside the live access decision.

Request and decision flow

For every step, record input, authority, decision, output, enforcement, evidence, and fallback. Ask who can change each item and whether that change is independently visible.

Trace alternate flows: cached session, retry, background job, direct IP, service account, administrative endpoint, health route, disaster mode, restored backup, old client, and maintenance tunnel. A component that does not process the normal request can still break the claim through one alternate path.

Convert trust into explicit interface contracts. A policy evaluator receives authenticated, typed inputs and returns a bounded decision. A key service permits one operation for one workload identity and purpose. A deployer can replace a binary but cannot also erase independent deployment evidence.

Failure domains

Group trusted components by shared failure: same host, kernel, administrator, credential, provider, control plane, build system, region, key, or recovery path. Two checks in one process under one mutable configuration are not independent defenses.

Test at least these failures:

• Identity source returns stale or attacker-controlled group state.
• Policy distribution is delayed, rolled back, or only partly applied.
• The gateway is correct but the origin is reachable around it.
• A compromised upstream reads gateway credentials or configuration.
• CI or registry serves a different artifact than the reviewed one.
• Break-glass operation bypasses normal identity or evidence.
• Recovery restores an old policy, key, account, or vulnerable image.

Reduce and restructure the trusted set

For each trusted component, choose one action: remove it, move it outside the property, reduce its privilege, narrow its interface, separate it, make it replaceable, or improve its evidence.

Remove unused parsers, plugins, network paths, credentials, and administrator roles. Put high-authority operations in small components. Prefer short-lived scoped credentials to shared secrets. Separate policy administration from enforcement. Keep the origin unreachable except through intended enforcement. Use immutable artifacts and authenticated configuration. Make recovery consume the same approved state and produce evidence.

Do not call trust removed when it moved to a cloud provider or hardware vendor. Name the new provider claim, interface, evidence, and exit or recovery plan.

Assurance evidence

Build an assurance case for each remaining assumption:

1. Claim and boundary.
2. Component or process that supports it.
3. Design rationale and interface.
4. Implementation and configuration evidence.
5. Positive, negative, failure, bypass, and recovery tests.
6. Deployed-state and lifecycle evidence.
7. Residual risk and owner.

Assurance depth must match privilege and consequence. A formally verified component still has explicit assumptions about hardware, boot, toolchain, configuration, and integration. A managed service still needs identity, policy, audit, version, availability, and recovery evidence.

Design tradeoffs and residual risk

A smaller TCB can improve review, isolation, and failure analysis. It can add processes, protocols, credentials, deployment units, and operational complexity. A narrow privileged helper can become a confused deputy. Independent controls can create inconsistent state.

Keep the smallest structure that supports the required property and assurance. Record residual provider, administrator, hardware, side-channel, availability, and recovery trust. Recalculate the TCB after every material architecture or operating change.

Pomerium boundary

Pomerium can be the route-level policy decision and enforcement mechanism for traffic that must pass through it. The surrounding TCB includes identity and policy inputs, Pomerium configuration and keys, runtime isolation, network boundary, deployment system, operators, and upstream authorization. Pomerium documentation describes its component roles. It cannot prove that an origin has no bypass or that an upstream enforces its own object rules.

Exercise

Select one production route and one precise claim. Produce a TCB graph with components, people, credentials, interfaces, and alternate paths. Mark shared failure domains and the owner of each assumption.

Remove or narrow at least three trusted elements. Then run one bypass test, one compromised-component simulation, one stale-policy test, and one recovery test. Collect evidence that the claim still holds in the deployed environment.

Evaluation checklist

• Does the TCB start from a testable property rather than a product or network diagram?
• Are identity, build, deploy, host, key, administration, evidence, and recovery paths present?
• Can each trusted component name the exact failure that would violate the claim?
• Did each claimed trust reduction remove authority or only move it to an unnamed dependency?
• Are shared failure domains, alternate paths, negative tests, recovery, and residual risk explicit?