What is the difference between a reference monitor and a security kernel?

The reference monitor is a concept: an abstract machine that mediates every access by every subject to every object, checked against the security policy. The security kernel is the implementation: the actual hardware, firmware and software inside the trusted computing base that realises that concept in running code. One is a design requirement and the other is the thing that satisfies it, which is why a system can be said to have a security kernel but is only ever said to implement the reference monitor concept. Answer options that treat the reference monitor as a specific software product tend to be distractors.

What are the three properties of a reference monitor?

A reference monitor must provide complete mediation, meaning it is invoked on every access with no path that bypasses it. It must be tamper-proof, meaning it is protected from modification and sits inside the boundary it guards rather than outside it. And it must be verifiable, meaning it is small and simple enough that its correctness can actually be analysed and demonstrated. The three are often summarised as always invoked, tamper-proof and verifiable, and the third is the reason a small trusted computing base matters.

What are protection rings?

Protection rings are a hardware-enforced privilege hierarchy in which code runs at a numbered level and privilege increases toward the centre. In the classical four-ring model, ring 0 holds the operating system kernel and is the most privileged, ring 1 holds operating system services, ring 2 holds device drivers, and ring 3 holds user applications and is the least privileged. Most production operating systems, including Windows and Linux, use only ring 0 and ring 3, but the four-ring model is the one a CISSP candidate is expected to be able to describe.

What is the difference between kernel mode and user mode?

Kernel mode, also called supervisor state, is the processor state in which ring 0 code executes and privileged instructions are permitted, including direct access to memory and hardware. User mode, also called problem state, is the processor state in which ring 3 code executes, where privileged instructions are refused and any such operation must be requested from the operating system through a system call. The two name pairs describe the same distinction from different angles: the ring is where code sits, and the mode is what the processor will let it do.

Why should a trusted computing base be as small as possible?

Everything inside the trusted computing base has to be trusted, so everything inside it has to be verified, and verification effort grows with size and complexity. A smaller trusted computing base means fewer components to analyse, fewer places a flaw can hide, and a smaller attack surface, which together allow a higher level of assurance. Assurance is the degree of confidence that a system's security controls work as intended, and it is earned through evidence rather than asserted, which is why minimality is treated as a design goal rather than an optimisation.

LONG GUIDE · SECURITY ARCHITECTURE · 20 MIN READ

Trusted Computing Base Explained: Reference Monitor, Rings and Security Kernel for CISSP

02 SEPT 2026 · BY Gagan V Singh

WATCH THE VIDEO

Trusted Computing Base, Protection Rings, and the Reference Monitor | CISSP Domain 3 · watch on YouTube

The trusted computing base is the total combination of hardware, firmware and software in a system that is responsible for enforcing that system’s security policy. It is the part that has to work perfectly, because if any piece of it fails or is subverted, every protection built on top of it fails with it. Trusted here does not mean safe or known to be good, and that single distinction is where most of the confusion about this topic begins.

The idea matters because a security model on its own enforces nothing. The Bell-LaPadula model describes which reads and writes are permitted between security levels, but a set of rules written on paper cannot stop a process from touching memory. Something has to sit between every request and every resource, apply the rules, and be trustworthy enough that its verdict means something. That something is the trusted computing base, and the concept that describes its behaviour is the reference monitor. If the model is the rulebook, this is the machinery that reads it.

Concentric diagram of a trusted computing base. At the centre a hardware core labelled processor and TPM, surrounded by a ring 0 band labelled kernel. A dashed teal circle around both is labelled security perimeter. Outside it a faint outer ring holds ordinary user applications, which are outside the boundary. To the right, three stacked panels list what sits inside the line: hardware meaning the processor and the Trusted Platform Module, firmware protected by code signing, and software meaning the security kernel, anti-malware and the host firewall. — Source: Learn Security Management

What is the trusted computing base?

The trusted computing base, usually shortened to TCB, is the total combination of protection mechanisms within a computer system, including hardware, firmware and software, responsible for enforcing a security policy. The definition comes from the US Department of Defense Trusted Computer System Evaluation Criteria, DoD 5200.28-STD (1985), the document known as the Orange Book. That standard has been superseded for evaluation purposes by the Common Criteria (ISO/IEC 15408), but its vocabulary survived intact, which is why terms coined for a 1980s evaluation scheme are still the terms in use.

What makes the trusted computing base definition useful is that it is about responsibility, not location. A component belongs to the TCB if the system’s security depends on it behaving correctly, and sits outside if the system’s security survives it misbehaving. A word processor is not in the TCB, because a corrupt word processor is a bad day rather than a compromised machine. The memory manager is, because a corrupt memory manager voids every isolation guarantee on the machine.

The security perimeter is the boundary, not the contents

The imaginary line drawn around the TCB is the security perimeter, and the two terms are routinely swapped: the trusted computing base is the set of components, while the security perimeter is the boundary separating them from everything else. The perimeter is where trusted and untrusted stop being labels and become enforced, because anything crossing it has to be mediated.

What trusted actually means here

Trusted is a technical term here, and it does not mean trustworthy. It means depended upon. A kernel flaw can switch off every protection layered above it, so the kernel is trusted whether or not anyone has ever verified it.

Key concept: trusted is a statement about consequence.

Calling a component trusted does not assert that it is secure. It asserts that if it fails, the system’s security fails with it. This is why minimising the trusted computing base is a security objective in its own right: it reduces the number of components whose failure would be catastrophic.

Hardware, firmware and software: the three strata of a TCB

Each of the three words in the definition earns its place, and a scenario question will often turn on recognising that all three are in scope rather than just the software.

Hardware is the physical layer: the processor, its memory management unit, and dedicated security silicon such as the Trusted Platform Module. It is inside the boundary because the isolation the rest of the system relies on is ultimately enforced by circuitry.

Firmware is the low-level code driving that hardware directly, including UEFI firmware and device microcode. It is inside because it runs before the operating system and can therefore undermine anything that runs afterwards. Its own protection is typically code signing, a cryptographic check that the firmware came from the expected manufacturer and has not been altered since.

Software is every program with a security enforcement job: the security kernel, the access control subsystem, and defensive components such as anti-malware and a host-based firewall. Note what is absent. Ordinary applications are not in the TCB however important they are to the business, because the security policy does not depend on them.

Why trust has to start in hardware

Trust cannot begin in software, and the reason is a regress rather than a preference. Every piece of software is loaded by some earlier piece of software, so asking software to vouch for software is asking one stranger to vouch for another, indefinitely. The chain has to terminate in something no software loaded and no software can rewrite.

The chain terminates in the hardware root of trust: the processor’s own circuitry, fixed at manufacture, together with dedicated security hardware such as a TPM. A TPM is a secure cryptographic co-processor holding keys that never leave it, and it can record a measurement of code before that code runs. A measurement is a cryptographic hash: identical for identical code, completely different if a single bit changes. The rule the design rests on is measured before trusted.

A horizontal chain of four boxes. Silicon, the hardware root of trust, measures firmware, which measures the bootloader, which measures the kernel, with each connecting arrow labelled measures. A line in green beneath the chain reads that every hash is appended to the TPM and the registers can never be overwritten, so the machine keeps evidence of exactly what started. To the right of the kernel a dashed teal vertical line labelled security perimeter closes the chain, and beyond it a faint outlined box labelled user applications, ring 3, is marked in red as never measured, only loaded and believed. — Source: Learn Security Management

Code signing and measuring answer different questions

Code signing and measurement are constantly conflated, and the cleanest way to hold them apart is to state the question each one answers.

Code signing answers: who published this code, and has it been altered since they signed it? It asserts origin and integrity, and it depends on trusting the signer. Measuring answers a different question: what exactly is this code, bit for bit, right now? It makes no judgement, records a fact, and leaves the interpretation to whatever compares that record against an expected value later.

Measured boot is built on the second question. Each stage’s hash is extended into platform configuration registers inside the TPM, which are append-only, so the record of how the machine started cannot be quietly rewritten. Secure boot is built on the first: it refuses to run code whose signature does not verify. Real systems commonly use both, and a scenario describing a record of what ran is describing measurement, while one describing a refusal to run something is describing signature verification.

Either way the chain stops at the perimeter. Applications outside it are loaded and believed, so trust out there is inherited rather than measured, which is why a separate mechanism is needed for whatever those applications ask for while the system is running.

What is a reference monitor?

The reference monitor is an abstract machine that mediates all access by subjects to objects, checking each request against the security policy and permitting it only if the policy allows. The concept originates in James P. Anderson’s Computer Security Technology Planning Study, ESD-TR-73-51 (1972), and has survived every architectural fashion since because it states a requirement rather than a design.

Mediation diagram. A subject box on the left, described as the active party, a user or a process, connects by an arrow labelled requests to a highlighted central box labelled reference monitor carrying the sub-line always invoked. A second arrow labelled the verdict continues from it to an object box on the right, described as the passive party, a file, device or memory. Above the reference monitor a box labelled security policy feeds down into it by a teal arrow, described as the rules the gate checks against. Along the bottom three boxes give the three properties: always invoked, checked on every access; tamper-proof, protected inside the boundary; and verifiable, small enough to prove correct. — Source: Learn Security Management

Two words in the definition carry precise meanings a well-written question can turn on. A subject is the active party in an access: a user or a process, whatever is doing the asking. An object is the passive party: a file, a device, a region of memory. The same entity can be a subject in one interaction and an object in another, so the terms describe roles rather than kinds of thing.

The security policy is the set of rules the monitor checks against, and it is not a document in a compliance folder: it is the machine’s enforceable access rules, expressing which subjects may do what to which objects, whether those rules come from labels and clearances under mandatory access control, as in Bell-LaPadula, or from an access control list.

The three properties: complete mediation, tamper-proof, verifiable

Three conditions have to hold together. Dropping any one makes the other two decorative.

Complete mediation means the monitor is invoked on every access, with no path reaching an object without passing through it. This is what always invoked refers to: a gate with a way round it is not a gate.

Tamper-proof means the monitor is protected against modification, which in practice means it sits inside the perimeter it enforces. A gatekeeper an attacker can edit is a gatekeeper working for the attacker.

Verifiable means it is small and simple enough for its correctness to be demonstrated rather than assumed. This is the property that ties the reference monitor to the size of the TCB, and the reason the two are taught together.

Reference monitor vs security kernel: concept against implementation

Concept against implementation is the distinction most likely to decide a close question, and it is a clean one once stated plainly: a concept cannot stop anything by itself, so something has to run the gate. That something is the security kernel, the hardware, firmware and software elements of the TCB that implement the reference monitor concept in executing code.

	Reference monitor	Security kernel	Trusted computing base
What it is	A concept: an abstract machine	An implementation: real code and circuitry	A scope: the set of all components security depends on
What it does	States the requirement that all access be mediated	Enforces that requirement at run time	Contains the security kernel and everything else that must be trusted
Can you point at it?	No, it is a design requirement	Yes, it is identifiable software and hardware	Yes, as an enumerable set of components
Its defining test	Complete mediation, tamper-proof, verifiable	Correctly realises those three properties	Everything inside is depended upon; everything outside is not
Relationship	Realised by the security kernel	A subset of the trusted computing base	The boundary that contains both

The nesting fits in one line: the security kernel implements the reference monitor concept, and the security kernel is part of the trusted computing base. A scenario describing something checked on every access is describing the concept; one describing the component doing the checking is describing the security kernel.

Protection rings and CPU privilege levels

Protection rings give the layers their formal names and, more importantly, put the separation in hardware rather than in policy. The scheme is a privilege ladder in which privilege increases toward the centre.

Protection rings drawn as four concentric bands around a silicon core, numbered 0 at the centre through 3 at the outside, with an arrow running inward from the outer band to the core labelled more privilege. To the right, four rows name each ring in turn: ring 0 the kernel, the most privileged, running in kernel mode or supervisor state; ring 1 operating system services, privileged but not touching hardware directly; ring 2 device drivers; and ring 3 user applications, the least privileged, running in user mode or problem state. A line below records that Windows and Linux use ring 0 and ring 3 only. — Source: Learn Security Management

Ring 0 to ring 3, and why modern systems use two

Ring 0 holds the operating system kernel and is the most privileged level: it executes privileged instructions and addresses memory and hardware directly. Ring 1 holds operating system services, privileged but no longer touching hardware directly. Ring 2 holds device drivers. Ring 3 holds user applications and is the least privileged, which is where a browser, an email client and any malware arriving with them all run.

In practice, mainstream operating systems collapse this. Windows and Linux use ring 0 and ring 3 only, running drivers in ring 0 alongside the kernel, largely because processor architectures that lacked four usable levels made the intermediate rings impractical to rely on. The collapse is a real trade-off: a faulty driver in ring 0 is a kernel-level fault. The four-ring model nonetheless remains the one a candidate is expected to be able to describe, and questions in this area tend to be set on the classical scheme rather than on any particular operating system.

Kernel mode and user mode, supervisor state and problem state

Two pairs of names describe the processor’s own state, and both appear in CISSP material.

Kernel mode, also called supervisor state, is where ring 0 code runs. Privileged instructions are permitted.
User mode, also called problem state, is where ring 3 code runs. Privileged instructions are refused, and anything requiring them must be requested from the operating system.

The ring says where code sits in the hierarchy. The mode says what the processor will allow it to do. They are two views of one arrangement, and a question naming either pair is asking about the same separation.

How a system call crosses the boundary

A privilege ladder explains nothing about how work gets done, because ring 3 code constantly needs things only ring 0 can provide. Reading a file requires touching a disk, and an application may not touch a disk. The mechanism that resolves this is the system call: the defined interface through which user code asks the operating system to act on its behalf.

Walking the sequence once makes complete mediation concrete. An application in ring 3 issues a system call requesting a file. The request reaches the single controlled entry point into the trusted side rather than the resource itself, and is held there while the security kernel evaluates it against the policy: this subject, this object, this operation, permitted or not. If the policy permits it, the kernel does the work on the application’s behalf and returns the result across the boundary. The application never touches the disk at any point.

The same gate denies the malicious request

Now run malware through the identical path. It issues a request from ring 3 for direct access to kernel memory, takes the same route to the same entry point, and is evaluated by the same mechanism.

The critical detail is what it is evaluated against. The policy is not a list of known malicious programs, and the security kernel has no opinion about intent. It is the same set of access rules that permitted the earlier request, and no rule in it grants ring 3 code direct access to kernel memory, so the answer is denied by the same process that permitted the first.

CISSP Exam Note

The symmetry is the teaching point. The gate does not recognise good software by instinct, and it is not a detection control: it evaluates every subject against the policy and returns whatever the policy requires. A scenario in which a control separates malicious from benign by signature or behaviour is describing anti-malware, not a reference monitor.

Skipping a ring raises a privilege fault

An honest application that tries to reach ring 0 directly, bypassing the defined entry point, fails just as firmly. The processor raises a privilege fault the moment code attempts an operation outside its ring, and that fault comes from its own circuitry rather than from any software check.

Hardware enforcement and policy evaluation are two different controls, and confusing them is a common error:

The hardware decides where a crossing is possible at all. Rings are enforced by the processor. There is one legal entry point, and there is no software path around that fact.
The policy decides whether a request that reaches the gate is allowed. That is the security kernel’s evaluation, and it is a software decision.

The same hardware enforcement provides process isolation: each process gets its own protected region of memory and the processor keeps it there, so one ring 3 application cannot read or modify another’s memory directly. Together with least privilege, that is what makes the outer ring survivable despite containing entirely untrusted code.

Why a small TCB means higher assurance

Everything inside the perimeter must be trusted, so everything inside it must be verified. Verification is what makes size a security property rather than an engineering preference: analysing a small, well-defined kernel is feasible, and analysing an entire modern operating system to the same standard is not.

A small TCB means fewer components whose correctness is load-bearing, fewer places a flaw can hide, and a smaller attack surface. What that buys is assurance: the degree of confidence that a system’s security controls work as intended. Assurance is evidence-based rather than asserted, which is why the Orange Book graded systems by evaluation class in the first place.

Two perimeters drawn side by side at very different sizes. The small one, labelled small TCB, is traced all the way round by an unbroken teal line that returns to the dot it started from, and the words inside it read inspection finishes, high assurance. The large one, labelled large TCB, is traced by the same teal line but the line reaches only about a quarter of the way round before its arrowhead trails off, leaving most of the perimeter as a faint dashed outline, and the words inside it read in red that the same walk never finishes, low assurance. — Source: Learn Security Management

Layering, abstraction and data hiding

Three design principles keep the structure tractable, and they are frequently listed together because they describe one arrangement from three angles.

Layering means each ring interacts only with its immediate neighbours rather than reaching across the hierarchy, so a fault stays contained within a level. Abstraction means each layer presents a simplified interface upward, offering operations rather than the mechanism behind them. Data hiding means a layer’s internal state is not visible outside it, so higher layers cannot depend on, or corrupt, details they were never given.

Layering, abstraction and data hiding sit alongside defence in depth, which answers a different question. Layering is about how a system is decomposed; defence in depth is about placing independent controls so one failure is not total.

Where the model breaks down

The classical picture is a teaching model, and a candidate who can say where it stops matching reality understands it better than one who can only recite it.

The four-ring model is not what ships. Two rings are the norm, which means the isolation between operating system services, drivers and the kernel that the model implies does not exist on the systems most people use. A driver bug is a ring 0 bug.

Virtualisation added a level below ring 0. A hypervisor runs beneath the guest kernel and is more privileged than something the model calls the most privileged level. It is often referred to informally as ring -1, which is a useful shorthand and not part of the classical scheme. The consequence matters more than the label: in a virtualised environment, the guest’s trusted computing base sits on top of another trusted computing base it cannot inspect.

Trust outside the perimeter is inherited, not verified. Measurement covers start-up. Everything loaded afterwards is believed, which is why run-time mediation exists at all and why a measured boot alone proves nothing about what a system is doing an hour later.

A verified TCB is only as good as its verification. Assurance is a statement about the evidence gathered, not a guarantee. Hardware side channels in particular sit awkwardly here: an attack that infers protected data from timing or power consumption never crosses the gate, so it never presents the reference monitor with a request to deny.

Conclusion

The trusted computing base answers a question that sounds philosophical and turns out to be entirely practical: how much of this machine has to be trusted? The design answer is as little as possible. Draw the boundary deliberately, anchor it in hardware that no software can rewrite, force every crossing through one mediated point, and keep the contents small enough that the claim can actually be checked.

Held that way the vocabulary stops being a list to memorise, because each term answers a different question: the trusted computing base is the scope, the security perimeter is its boundary, the reference monitor is the requirement, the security kernel is the code that meets it, and protection rings are the hardware that makes the whole arrangement enforceable rather than advisory.

If you want to pressure-test the distinctions that decide these questions, particularly reference monitor against security kernel and hardware enforcement against policy evaluation, the LSM CISSP practice tests drill exactly this material in scenario form, with explanations that state why the near-miss option fails rather than only which answer is right.

Quick reference for the CISSP exam

The definition in one sentence

The trusted computing base is the total combination of hardware, firmware and software responsible for enforcing a system’s security policy, and the security perimeter is the boundary drawn around it.

The three reference monitor properties

Complete mediation (always invoked, no path around it), tamper-proof (protected inside the boundary it enforces), and verifiable (small and simple enough to demonstrate correct). All three must hold together.

Reference monitor against security kernel

The reference monitor is the concept and the security kernel is the implementation. The security kernel is part of the trusted computing base; the reference monitor is a requirement that the security kernel satisfies.

The ring vocabulary

Ring 0 is the kernel and the most privileged; ring 3 is user applications and the least privileged; privilege increases inward. Ring 0 runs in kernel mode, also called supervisor state. Ring 3 runs in user mode, also called problem state. Rings are enforced by hardware, not by policy.

Layering, abstraction, data hiding, assurance

Layering means each level deals with its neighbours. Abstraction means each level exposes an interface rather than a mechanism. Data hiding means internal state stays internal. Assurance is the degree of confidence that controls work as intended, and it rises as the trusted computing base gets smaller.

Spotting the topic in a scenario

A question about what must be trusted, or about where a boundary is drawn, is about the trusted computing base. A question about something being checked on every single access points to the reference monitor. A question about the component performing the check points to the security kernel. A question about an application being unable to execute a privileged instruction points to rings and processor modes, and the enforcement in that case is hardware.

Frequently asked questions

What is the trusted computing base?: The trusted computing base is the total combination of hardware, firmware and software within a system that is responsible for enforcing that system's security policy. It is defined by responsibility rather than by location: a component is inside the trusted computing base if the system's security depends on it behaving correctly, and outside if it does not. The boundary drawn around it is called the security perimeter, and everything within that boundary must work exactly as intended, because a failure or subversion anywhere inside it undermines every protection built on top.
What is the difference between a reference monitor and a security kernel?: The reference monitor is a concept: an abstract machine that mediates every access by every subject to every object, checked against the security policy. The security kernel is the implementation: the actual hardware, firmware and software inside the trusted computing base that realises that concept in running code. One is a design requirement and the other is the thing that satisfies it, which is why a system can be said to have a security kernel but is only ever said to implement the reference monitor concept. Answer options that treat the reference monitor as a specific software product tend to be distractors.
What are the three properties of a reference monitor?: A reference monitor must provide complete mediation, meaning it is invoked on every access with no path that bypasses it. It must be tamper-proof, meaning it is protected from modification and sits inside the boundary it guards rather than outside it. And it must be verifiable, meaning it is small and simple enough that its correctness can actually be analysed and demonstrated. The three are often summarised as always invoked, tamper-proof and verifiable, and the third is the reason a small trusted computing base matters.
What are protection rings?: Protection rings are a hardware-enforced privilege hierarchy in which code runs at a numbered level and privilege increases toward the centre. In the classical four-ring model, ring 0 holds the operating system kernel and is the most privileged, ring 1 holds operating system services, ring 2 holds device drivers, and ring 3 holds user applications and is the least privileged. Most production operating systems, including Windows and Linux, use only ring 0 and ring 3, but the four-ring model is the one a CISSP candidate is expected to be able to describe.
What is the difference between kernel mode and user mode?: Kernel mode, also called supervisor state, is the processor state in which ring 0 code executes and privileged instructions are permitted, including direct access to memory and hardware. User mode, also called problem state, is the processor state in which ring 3 code executes, where privileged instructions are refused and any such operation must be requested from the operating system through a system call. The two name pairs describe the same distinction from different angles: the ring is where code sits, and the mode is what the processor will let it do.
Why should a trusted computing base be as small as possible?: Everything inside the trusted computing base has to be trusted, so everything inside it has to be verified, and verification effort grows with size and complexity. A smaller trusted computing base means fewer components to analyse, fewer places a flaw can hide, and a smaller attack surface, which together allow a higher level of assurance. Assurance is the degree of confidence that a system's security controls work as intended, and it is earned through evidence rather than asserted, which is why minimality is treated as a design goal rather than an optimisation.