AC-25: Reference Monitor

Page header

View the full NIST SP 800-53 framework index.

What this control requires

AC-25 requires your organization to implement a reference monitor that enforces access control over every subject-to-object interaction. This requirement shapes how your operating system enforces access control policies at the architectural level, not through policy configuration alone.

In practice, you need a reference validation mechanism that meets three properties simultaneously. It must be always invoked, meaning no subject can access any object without the mechanism evaluating the request. It must be tamper-proof, meaning adversaries can’t compromise or disable its enforcement logic.

Specifically, the mechanism must also be small enough to be subject to complete analysis and testing. Your security team needs to verify the mechanism does exactly what it claims, with no latent flaws hiding in untested code paths.

Specifically, the distinction between subjects and objects shapes how this requirement applies. Subjects are the active entities, including individuals, devices, or processes acting on their behalf. Objects are the passive entities, including records, buffers, files, communication ports, and inter-process pipes.

In practice, the reference monitor enforces access decisions based on identity and group membership, applying a rule set that the access control policy defines. Every interaction between a subject and an object must be mediated without exception.

Why it matters

Most organizations treat access control as a configuration problem, something handled by identity providers and role-based policies. AC-25 challenges that assumption. The requirement goes deeper than policy configuration; the enforcement mechanism itself must be verifiably correct, not just the policies it implements.

The result is real audit exposure. Failure to maintain this control may lead to certification withdrawal or regulatory findings. When assessors evaluate AC-25, they’re looking for evidence that your enforcement mechanism can’t be circumvented, corrupted, or left untested.

In practice, a system that relies on scattered enforcement points with no unified validation layer will struggle to demonstrate compliance.

Where this breaks down further is visibility. Unlike a misconfigured firewall rule that generates blocked-traffic logs, a bypassed validation mechanism produces no evidence of its own failure. Access requests that should have been denied simply proceed without scrutiny.

Where this exposure becomes acute is in federal authorization contexts and frameworks that map to NIST SP 800-53. Without a demonstrably tamper-proof and always-invoked enforcement mechanism, the entire access control family of controls loses its foundation.

What attackers exploit:

• Validation gaps where certain access paths bypass the enforcement mechanism entirely, allowing unauthorized subject-to-object interactions
• Tamper vulnerabilities in the reference validation mechanism itself, enabling adversaries to modify enforcement logic or disable policy evaluation
• Excessive mechanism complexity that prevents complete analysis and testing, leaving latent flaws undetected in enforcement code
• Process isolation weaknesses that allow subjects to interact with objects through inter-process pipes or shared buffers outside the mediated path
• Insufficient monitoring of the reference validation mechanism’s integrity, allowing silent degradation of enforcement

How to implement

For your organization

The core implementation challenge with AC-25 isn’t writing access control policies. It’s proving that the mechanism enforcing those policies can’t be bypassed, disabled, or left partially untested.

In practice, that means starting by identifying every access path between subjects and objects in your system architecture. Map how individuals, devices, and processes interact with records, buffers, communication ports, files, and inter-process pipes. Any path not mediated by your reference validation mechanism is a compliance gap.

Specifically, design or select a reference validation mechanism that satisfies the three required properties. For the always-invoked property, implement mandatory access control at the kernel or hypervisor level, ensuring no system call that mediates subject-to-object interaction can skip validation.

Specifically, tamper-proofing calls for hardware-backed integrity protections, code signing, and secure boot chains to prevent modification of the enforcement mechanism. For the smallness property, keep the trusted computing base minimal and well-defined so your team can perform exhaustive analysis.

In practice, assessors need to see not just that the mechanism exists, but that you’ve tested it comprehensively. This means maintaining test coverage reports, formal verification artifacts where applicable, and records of penetration testing specifically targeting the reference validation mechanism.

Common mistakes:

• Assuming application-layer access controls satisfy AC-25 when the operating system’s enforcement mechanism hasn’t been validated
• Deploying a reference validation mechanism that’s too large and complex for complete analysis, undermining the smallness property
• Failing to re-verify the mechanism after system updates, patches, or configuration changes
• Treating AC-25 as a documentation exercise rather than an architectural design requirement

For your vendors

When your vendors operate systems that process your data, their access control architecture directly affects your risk posture. AC-25 compliance isn’t something you can verify through a questionnaire alone, but targeted questions and evidence requests help you assess whether vendors take reference monitor requirements seriously.

Specifically, ask vendors to describe the reference validation mechanism in their system architecture. Request documentation showing how the mechanism mediates all subject-to-object access. Vendors should be able to explain what prevents a process from accessing a file, buffer, or communication port without the mechanism’s evaluation.

But documentation alone isn’t sufficient. Request direct evidence of the three core properties, starting with architecture diagrams for the always-invoked property showing the enforcement mechanism’s position in the access path, confirming no bypass routes exist.

Specifically, for tamper-proofing, request documentation of integrity protections such as secure boot, code signing, or hardware-backed enforcement. For smallness, ask for the scope of the trusted computing base and any formal analysis or verification testing performed against it.

In practice, evaluating completeness means looking at their testing approach. Vendors should provide test coverage reports, penetration test results targeting the enforcement mechanism, and records of re-verification after system changes. A vendor that can’t demonstrate comprehensive testing of their reference validation mechanism likely can’t assure the completeness required by AC-25.

Red flags:

• Vendors who conflate role-based access control configuration with reference monitor implementation
• Inability to identify the specific enforcement mechanism or describe its boundaries
• No evidence of formal analysis, code review, or systematic risk assessment of the validation mechanism
• System architectures where the trusted computing base is too expansive for meaningful verification

Evidence examples

Cross-framework mapping

No cross-framework mappings have been identified for this control.

Related controls

• AC-03 — Access Enforcement: establishes the foundational access enforcement requirement that the reference monitor’s validation mechanism implements and verifies
• AC-16 — Security and Privacy Attributes: defines the security attributes that the reference monitor uses to make access decisions about subjects and objects
• SA-08 — Security and Privacy Engineering Principles: provides the engineering principles, including least privilege and minimized trusted computing base, that guide reference monitor design
• SA-17 — Developer Security and Privacy Architecture and Design: requires developers to produce and maintain a security architecture that includes the reference validation mechanism’s design specification
• SC-03 — Security Function Isolation: ensures the reference validation mechanism is isolated from non-security functions, supporting the tamper-proof property
• SC-11 — Trusted Path: establishes trusted communication channels between users and the system, complementing the reference monitor’s always-invoked mediation
• SC-39 — Process Isolation: enforces process separation that prevents subjects from bypassing the reference monitor through shared memory or inter-process communication
• SI-13 — Predictable Failure Prevention: addresses proactive measures to prevent reference validation mechanism failures that could degrade access control enforcement

Frequently asked questions

What is NIST SP 800-53 AC-25?

AC-25 requires organizations to implement a reference monitor, a tamper-proof, always-invoked validation mechanism small enough for complete analysis, that enforces access control policies over all subjects and objects. The reference validation mechanism evaluates every access request between active entities (individuals, devices, processes) and passive entities (records, files, buffers, communication ports) based on identity and group membership. This control focuses on the architectural integrity of the enforcement mechanism itself, not just the policies it applies. You can review the full NIST 800-53 compliance checklist for additional context on access control requirements.

What happens if AC-25 is not implemented?

Without a reference monitor, your access control enforcement lacks a verifiable architectural foundation, meaning access decisions may be bypassed, tampered with, or incompletely tested. Audit findings become likely because assessors can’t confirm that every subject-to-object interaction passes through a validated enforcement mechanism. For organizations pursuing federal authorization, this gap can delay or block certification. The risk extends beyond compliance because latent flaws in an unverified enforcement mechanism remain invisible until exploited.

How do you audit AC-25?

Auditing AC-25 requires evidence that the reference validation mechanism is tamper-proof, always invoked for every subject-to-object access, and small enough for complete verification. Review system design documentation to confirm the mechanism’s position in all access paths, then examine test coverage reports and formal analysis artifacts to verify completeness of testing. Check audit records for evidence that the mechanism is actively mediating access requests, and review configuration baselines to confirm integrity protections like secure boot and code signing remain in effect.

What are the three properties of a reference monitor?

A reference monitor must be always invoked, tamper-proof, and small enough for complete analysis and testing. The always-invoked property ensures no subject can access any object without the validation mechanism evaluating the request. Tamper-proofing prevents adversaries from compromising or disabling the enforcement logic. The smallness property ensures the mechanism’s codebase is compact enough that security teams can exhaustively analyze and test it, verifying with assurance that no latent flaws exist in the enforcement code.