The set that must work
A trusted computing base is the complete set of hardware, firmware, software, configuration, people, and procedures whose failure can violate a stated security property. "Trusted" describes dependency. It does not mean that a component is honest, secure, verified, or owned by the same team.
The TCB changes with the claim. A gateway confidentiality claim can depend on the gateway binary, host kernel, TLS library, key service, configuration path, administrators, and build system. The upstream application's object-authorization claim adds application code, database mappings, and its policy data.
Find the real TCB
Start with one precise property and trace every way it can fail. Include code that makes or enforces decisions, stores secrets, supplies trusted identity or time, configures the control, updates it, observes failure, and restores it. Include lower layers that can read or change a higher layer.
A component outside the request path can still be in the TCB. A deployment system can replace the binary. A logging agent can read credentials. A backup operator can restore old policy. A DNS or certificate authority can redirect or impersonate a service.
Reduce and structure trust
Remove unused code, privileges, parsers, plugins, interfaces, and administrator paths. Separate mechanisms by purpose and privilege. Keep policy inputs narrow and authenticated. Use small enforcement components, memory-safe implementations, immutable deployment inputs, and independent checks where they reduce a specific failure.
Structure the remaining TCB so each part has a clear claim and interface. A small but opaque component is not automatically easier to trust. Assurance requires design evidence, implementation review, tests, provenance, configuration control, and deployed-state evidence.
Failure and residual risk
Architecture diagrams often omit firmware, host agents, service accounts, CI systems, break-glass access, and recovery. Cloud service boundaries can hide provider TCB components rather than remove them. Formal proof can cover a model and implementation while still depending on hardware, boot, toolchain, configuration, and operational assumptions.
Adding a security product can enlarge the TCB if it receives broad credentials or a bypass path. Replicating a trusted component can improve availability and increase the number of places where compromise breaks the property.
Pomerium boundary
Pomerium is part of the TCB for access claims that depend on its authentication, policy decision, session, or proxy enforcement. The relevant deployment also includes configuration, signing keys, identity sources, host and runtime isolation, administrators, and the network boundary that prevents direct upstream access. Pomerium is not the complete TCB for an upstream application's object permissions or data handling.
Evaluation checklist
- What exact security property defines membership in this TCB?
- Which lower layer, administrator, update path, identity source, clock, key, or recovery action can break the property?
- Which component can be removed, narrowed, isolated, or replaced by a simpler interface?
- What evidence supports each remaining trust assumption in the deployed system?
- Does a claimed external service remove trust, or only move it to a provider boundary?
