iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The trusted computing base (TCB) is the total set of a computer system’s protection mechanisms—hardware, firmware, and software—that work together to enforce its security policy. In practical terms, it includes every component the system’s security claim depends on: if a component or a necessary dependency fails, the system may no longer be able to enforce that policy.
What is the trusted computing base?
NIST defines the TCB as the “totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination responsible for enforcing a security policy.” NIST’s glossary entry cites terminology in CNSSI 4009-2022 and NIST Special Publications; definitions should be read in the context of their source.
The key idea is the system’s security policy: the rules that specify which actions or access are permitted. The TCB is not simply a list of components labeled “secure.” It is the set of mechanisms on which enforcement of those rules depends.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What components belong in a TCB?
There is no universal component list. Depending on the system’s design and the policy it must enforce, the TCB can include hardware, firmware, and software. A component’s name or position in the software stack does not determine whether it belongs.
#1 Best Overall
To assess a boundary, follow the enforcement dependencies:
- State the security policy the system is meant to enforce.
- Identify the mechanisms that enforce it, including the mechanisms that control security-sensitive access.
- Trace what those mechanisms depend on, including lower-level hardware, firmware, or software.
- Ask whether the system could still enforce the stated policy if each component or dependency failed or were compromised. If not, that component belongs in the security trust argument.
This dependency-based approach follows the National Academies’ explanation: a component is trusted for a particular security purpose when the system’s ability to meet its security specification depends on that component working correctly. Its dependencies matter as well. The National Academies’ discussion of trust and system dependencies provides that broader explanation.
Is the security kernel the same as the TCB?
No. The security kernel is a core part of the TCB, not another name for the whole thing. NIST describes it as the hardware, firmware, and software elements of a TCB that implement the reference monitor concept. NIST’s security-kernel entry specifies three properties: it mediates all access, is protected from modification, and can be verified as correct.
The reference monitor is a useful way to understand the kernel’s role: security-sensitive access should pass through a mechanism that applies the policy. The mechanism must be protected, and it should be sufficiently small or simple to analyze. The TCB may include additional mechanisms and dependencies needed for the policy to hold.
How is the TCB different from everything an organization must trust?
The TCB has a specific focus: protection mechanisms that enforce a computer system’s security policy. A system’s broader success may also depend on people and facilities. For example, the National Academies discusses security officers who set levels and power that supports availability. Those are operational trust dependencies, but they are not automatically part of the TCB as defined by NIST. Include them in the TCB only when the system’s stated security boundary explicitly treats them as part of its protection mechanisms. The National Academies’ examples distinguish these wider dependencies from system components.
What does “trusted” mean here?
“Trusted” describes what a security claim depends on; it does not prove that a component is invulnerable, error-free, or worthy of trust in every context. A TCB identifies the mechanisms and dependencies that must work correctly for a particular policy to be enforced. The claim is therefore only as strong as its boundary assumptions and the evidence that those components behave as required.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to compare TCBs in two systems
Compare systems against the same security policy rather than treating one fixed list of components as universally required. These questions organize the comparison:
- Boundary: Which hardware, firmware, and software mechanisms enforce the policy?
- Dependencies: Which lower-level components must work for those mechanisms to remain effective?
- Access mediation: Does a security kernel or reference monitor mediate the relevant accesses?
- Protection and verification: Is the mechanism protected from modification, and can it be verified as correct?
The Department of Defense’s Trusted Computer System Evaluation Criteria offers historical context for the TCB’s role in supporting a security policy and isolating protected objects. Its discussion describes a TCB that may refer to a reference-validation mechanism, such as a security kernel or front-end security filter, or, in some systems, the entire trusted computer system. This is useful conceptual history, not current compliance guidance. The historical criteria text explains that broader usage.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
