AC-25 Reference monitor: requirements and evidence

What AC-25 reference monitor requires and why assessors find it hard to prove

AC-25 requires a reference monitor for defined access control policies, and the mechanism must be tamperproof, always invoked, and small enough to be analyzed and tested so that its completeness can be assured. If an audit or system owner has been told AC-25 applies, or has chosen to add it, the first job is to decide which access control policies the monitor will cover, since the control is only meaningful against a named policy set. AC-25 is a design-level control. SP 800-53B Release 5.2.0 does not select it in the low, moderate or high baselines or in the privacy baseline, so it reaches a system only through tailoring or an overlay. That means the decision to adopt it, and the justification recorded in the system security plan, sits with the organization that owns the system.

The risk AC-25 addresses is an access decision that is bypassed, altered or skipped. A system can have correct policies in AC-3 and AC-24 and still leak access if a component can route around the code or service that evaluates a request, if a privileged administrator can edit the decision logic without detection, or if a new integration calls a resource directly. Because the three properties interact, a monitor that is always invoked but writable by administrators does not meet the intent, and a tamperproof component that some request paths never reach does not either. Assessors therefore look at the design documentation and the mechanisms that implement access enforcement, then ask how each request path reaches them.

Proving completeness is the hard part because it is a negative claim: the assessor must show there is no path that avoids the monitor, not just that the expected path works. The SP 800-53A procedure for AC-25 uses one determination statement and the examine, interview and test methods, with objects including the access control policy, system design documentation, configuration settings and audit records, plus interviews with personnel who hold access enforcement responsibilities. Before engaging an assessor, confirm with the organization's own architects which components can make or enforce access decisions, which administrative paths can change them, and how small the monitor's code and configuration surface really is. Those answers determine whether the evidence can be produced at all.

Which systems, policies and teams AC-25 reaches once you choose to adopt it

AC-25 is not selected in any SP 800-53B baseline, so the work begins with a deliberate decision to add it. The cards below cover the scoping choices that determine how far a reference monitor reaches, from the policies it enforces to the people who can touch it, and each choice belongs in tailoring documentation.

Policies the monitor must enforce

AC-25 applies to defined access control policies, so the first decision is which policies the monitor enforces. Start from the access control policy and the access enforcement rules that AC-3 and AC-24 already describe, and decide whether one monitor covers all of them or only a named subset. Record each policy in the system security plan so an assessor can trace every rule to a mechanism. Confirm which policy parameter values your organization assigns to AC-25, since the control has one organization-defined parameter that must be set before testing begins.

Systems and data stores behind the monitor

Decide which systems and data stores route their access decisions through the reference monitor. A monitor that covers the application but not the database, file share or object store behind it leaves a gap that an assessor will find. Map each in-scope system and data store against the enforcement path, and note any system that bypasses the monitor because it is a shared service or a legacy component. Those bypasses need documented justification and compensating controls, or they should be removed from scope.

Administrators with reach to the mechanism

The reference monitor is only as trustworthy as the people who can change it. List every administrator, platform engineer and service account that can modify the monitor's policy, configuration or code, and compare that list against the privileged access controls in AC-6. Separate the people who write access rules from the people who approve them where your separation of duties model requires it. Confirm that changes to the monitor are logged and reviewed, because a tamperproof design still depends on who holds administrative rights.

Third parties with access to enforcement

Vendors, managed service providers and contractors who maintain the monitor, host it or hold credentials to it extend its effective boundary. Identify each third party, what they can read or change, and whether their access is governed by the external system terms described under AC-20 or by contract. Ask each supplier how they would detect or prevent tampering with the monitor from their side. Write these relationships into the system security plan and the supply chain documentation, since assessors test the whole path, not only the internal team.

Baseline and overlay tailoring record

AC-25 is not selected in the low, moderate, high or privacy baselines, so adopting it means tailoring a baseline or applying an overlay. Record the decision in the tailoring documentation, stating which baseline you started from, that AC-25 was added, the rationale, and the policies and systems it covers. Keep the same record for any related control that the monitor depends on, such as AC-3, SA-8 or SI-13, so the reasoning for the design is visible to an assessor. Revisit the tailoring record when the system scope changes.

Dependencies on related controls

The SP 800-53 catalog links AC-25 to AC-3, AC-16, SA-8, SA-17, SC-3, SC-11, SC-39 and SI-13. Each link is a dependency that can weaken the monitor if it is missing. For example, a monitor that enforces attributes depends on AC-16 attribute handling, and a monitor that isolates its own processing depends on SC-3 and SC-39. Review each related control when you scope AC-25 so that the design, configuration and evidence for each one are assigned to a named owner before assessment begins.

How an assessor tests AC-25 under SP 800-53A

This table breaks down the single SP 800-53A determination statement for AC-25 by assessment method, the objects an assessor examines, interviews or tests, the evidence to prepare and the findings that commonly stop a reference monitor from passing. Read it as a preparation checklist: each row is something the assessor will ask to see, and the common findings show where the design argument usually breaks down.

Assessment element	What the assessor does	Evidence to prepare	Common findings
Determination statement	Decides whether the reference monitor for defined access control policies is implemented as the control requires, including that it is tamperproof, always invoked and small enough to analyze and test	A written statement mapping each property (tamperproof, always invoked, analyzable and testable) to the system design element that provides it	No single statement ties the three properties together, so the assessor cannot tell which mechanism is the monitor
AC-25_ODP parameter	Checks that the organization assigned the AC-25 organization-defined parameter, which sets the access control policies the monitor must enforce	The completed parameter value in the system security plan and the policy document it refers to	Parameter left at the template default or described only in general terms, such as all access
Examine: access control policy and access enforcement procedures	Reads the policy and procedures to see whether they require a reference monitor and say how enforcement is carried out	Current access control policy, procedures addressing access enforcement, approval and review records	Procedures describe enforcement by application teams without naming the monitor component
Examine: system design documentation and configuration settings	Traces how requests reach the monitor, what protects it from modification and how its configuration is controlled	Architecture diagrams, data flow diagrams, configuration baselines and change records for the monitor	No diagram shows the path from requester to enforcement point, or configuration can be changed outside change control
Examine: system audit records and system security plan	Confirms the monitor's decisions and changes produce records and that the plan describes the same design	Sample decision or denial logs, audit configuration for the monitor, and the plan section for AC-25	Plan describes a monitor that the design diagrams do not show, or audit records omit denied requests
Interview: personnel with access enforcement responsibilities	Asks owners how they know every access request passes through the monitor and who can change its rules	Named owners, responsibility assignments and documented escalation paths for monitor changes	Owners cannot describe how the monitor is kept current or who approves policy changes
Interview: system and network administrators	Asks administrators about direct access to the enforcement mechanism, bypass routes and emergency changes	Administrator access lists, privileged access approvals and emergency change procedures	Administrators hold rights to disable or edit the monitor without a recorded approval
Test: mechanisms implementing access enforcement functions	Attempts requests that should be denied, tries to skip the monitor and checks that changes to it are blocked or logged	Test plans, test results, bypass attempt records and evidence of tamper protection on the monitor	Bypass paths such as direct database or API access skip the monitor, or testing covered only the happy path

Sequence to design and prove an AC-25 reference monitor

This sequence turns the AC-25 requirement into a documented, testable mechanism: a defined set of access control policies, a complete map of access paths routed through the monitor, tamperproofing and change control, a reviewable design, completeness testing, and records in the system security plan. Each step ends with a named output that an assessor can examine.

Define the policies the monitor enforces
Start by listing the access control policies the reference monitor must enforce, drawn from the access control policy and the authorization decisions your systems already make. Record each policy as a numbered entry with its subjects, objects, permitted operations and the owner who approves it. Set the AC-25 organization-defined parameter at this point, because it fixes the scope the monitor must cover. The step is complete when the policy register is approved by the people who own access enforcement and the AC-25 parameter value is recorded in the system security plan. Confirm with your assessor which policy sources they will accept as the basis for the register.
Inventory and route every access path
Enumerate every path by which a subject can reach a protected object, including user interfaces, APIs, service-to-service calls, administrative consoles, batch jobs, database connections, and direct storage access. Mark each path as either routed through the monitor or documented as out of scope with a reason. Paths that bypass the monitor are the most common gap an assessor finds, so treat this inventory as the core artifact. The output is an access path inventory that maps each path to its enforcement point, and a sign-off that no path reaches a protected object without passing through the monitor. Review it again whenever a new interface or integration is added.
Design tamperproofing and restrict change
Specify how the monitor and its policy data are protected from modification. Define who can change the mechanism, the policy store and the configuration, how those changes are requested and approved, and how the platform prevents administrators from disabling enforcement silently. Separate the monitor's code, configuration and policy into distinct controls with their own access lists, and log every change. Confirm the design against your configuration management and audit records. The output is a tamperproofing section of the design document, plus a list of privileged roles with write access to the monitor and its policies, reviewed by the access control owner.
Keep the mechanism small and document the reasoning
Limit the monitor to access decisions and enforcement, moving other logic out so that the component can be read and analyzed in full. Document the size and boundaries of the mechanism, the dependencies it relies on, and why each included function is needed for enforcement. Explain the trade-offs you accepted, such as where decisions are cached or delegated, and how those choices keep the mechanism analyzable. The output is a design document that describes the component boundary, its interfaces and its rationale, reviewed by a security engineer who did not write it. Ask your assessor what level of design detail they expect before you finalize it.
Test completeness and bypass attempts
Build a test plan that checks each entry in the access path inventory against the policy register. Include positive tests, where authorized requests succeed, and negative tests, where unauthorized requests fail. Add deliberate bypass attempts, such as direct object access, stale tokens, alternate endpoints, misconfigured service accounts, and attempts to modify the policy or monitor configuration. Run the tests in a representative environment, record the results and resolve every failure or document a risk acceptance. The output is a test report that shows the paths tested, the results and any open findings, which the assessor can examine alongside the test methods named in SP 800-53A.
Record the design and test results in the SSP
Bring the outputs of the previous steps into the system security plan so the AC-25 implementation is described in one place. The entry should state the policies, the AC-25 parameter value, the location of the access path inventory, the design document, the tamperproofing controls and the test report. Link each claim to its evidence and name the role responsible for maintaining it. Assign a review trigger for changes to access paths, policies or the monitor itself. The output is an updated SSP section that an assessor can trace from the requirement to the evidence. Confirm the expected format with the authorizing official or assessor, since local templates vary.

Evidence that passes AC-25 and how to keep it current between assessments

An assessor testing AC-25 looks for proof that the reference monitor exists, that it is always invoked and that it has been tested against bypass. The cards below list each artifact that supports that proof, with the routine that keeps it accurate between assessments.

Access control policy and enforcement procedures

The policy defines the access control policies the reference monitor enforces, and the procedures describe how enforcement is implemented and operated. Assessors examine both to confirm the monitor is tied to named policy rules rather than to ad hoc settings. Review the policy on the schedule your organization sets, and revise it whenever a new access control policy or enforcement point is added so that the policy and the monitor's configured rules never drift apart.

Design documentation for always-invoked enforcement

AC-25 depends on showing that every access request passes through the monitor. Design documents should map each access path to the monitor and identify any component that could bypass it. Update the diagrams whenever architecture changes, and treat any new interface, service or integration as a design change that must be re-reviewed before it goes live.

Configuration baselines and monitor change records

Keep a documented baseline of the monitor's settings, versions and rule sets, along with records of each approved change. Assessors check that changes to the monitor move through change control with review and approval. Tie every monitor modification to a change ticket, and compare the running configuration against the approved baseline on a recurring schedule to catch unauthorized edits.

Access path inventory

An inventory lists every route by which a subject can reach a protected object, including administrative consoles, APIs, batch jobs and service accounts. Its purpose is to show that no route sits outside the monitor. Reconcile the inventory against network and system discovery results when new services are deployed, and retire entries when systems are decommissioned.

Audit records of enforcement decisions

Logs of allow and deny decisions show the monitor was invoked and how it responded. Assessors sample these records to check that decisions are captured with the subject, object, action and outcome. Confirm that log collection covers every enforcement point, review denials for patterns, and check that log integrity and retention meet your audit policy.

Bypass and tamper test results

Testing shows whether the monitor can be bypassed or altered in practice. Test cases should attempt direct access to protected resources, privilege escalation, and modification of the monitor's rules or code by unauthorized users. Re-run the full test set after any significant change to the monitor, its platform or the systems it protects, and record which findings were fixed and retested.

System security plan entry

The system security plan records how AC-25 is implemented, who is responsible for it and how the reference monitor fits the overall access design. Assessors compare the plan to the design documents and test results. Update the entry whenever the monitor, its policies or its responsible roles change, and confirm it still matches what the systems actually do.

What meeting AC-25 costs in money and effort

This table lists the cost components of building and evidencing a reference monitor for AC-25, who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the table to shape a written scope and quote rather than to budget from it.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Engineering time to design and justify the monitor	Internal architects, or an implementation partner preparing design documentation	One-time, with revisions when policies or paths change	Number of defined access control policies and the size of the monitor. Reusing an existing, self-hosted enforcement component with a documented design lowers effort; a bespoke mechanism raises it.
Enforcement and policy platform tooling or licenses	Software vendor or open-source project, plus any support contract	Recurring if commercial licenses or support apply; open-source components carry maintenance effort instead	Choice of self-hosted open-source enforcement components versus commercial products, and the number of protected resources. Confirm licensing terms and support tiers in writing.
Access path inventory	Internal system owners, with partner support to trace paths through the system	One-time build, then recurring updates whenever a new interface, API or integration is added	Number of access paths into the protected resources, including administrative, service and external interfaces. Automated discovery from configuration and logs reduces manual tracing.
Mediation and bypass path verification	Internal engineers or a testing provider for design review or penetration testing	Recurring at each significant change, plus periodic independent review	Number of routes that could reach protected data without passing the monitor, and how often the architecture changes. Fewer, well-documented entry points reduce scope.
Evidence upkeep	Internal compliance and security staff, with partner support for artifacts	Recurring, tied to each assessment cycle and each change to the monitor	Level of automation in collecting configuration snapshots, test results and audit records. Self-hosted tools that export evidence on a schedule reduce manual effort.
Auditor or assessor sampling	The independent assessor or the organization's authorizing official, depending on the program	Recurring with each assessment or authorization cycle	Number of policies, mechanisms and samples the assessor selects. Clear design documents and repeatable test scripts shorten sampling.
Scope and requirements definition	Internal risk and compliance owners, with a partner preparing a fixed-scope proposal	One-time at the start, with updates when tailoring or overlays change	Whether AC-25 is added through baseline tailoring or an overlay, since SP 800-53B does not select it in any baseline. Ask for a written scope that names the policies and resources covered.

In-house team, implementation partner and auditor roles for AC-25

The organization owns AC-25 in full. SP 800-53 Rev. 5 asks for a reference monitor for defined access control policies, so the organization must first decide whether it needs AC-25 at all. The control is not selected in any SP 800-53B baseline, so adoption is a tailoring decision that should be recorded in the system security plan. Leadership also owns the risk acceptance for any gap between the monitor's design and the policy it enforces.

Adoption decision: Decide whether AC-25 is in scope through baseline tailoring or an overlay, and record the rationale.
Policy definition: Define the access control policies the monitor must enforce and set the organization-defined parameter values.
Design authority: Own the architecture, including what the monitor mediates, its trust boundary and how it is protected from tampering.
Risk acceptance: Accept, mitigate or transfer any residual risk, in writing, with a named owner.
Internal evidence review: Read the evidence package before the assessor does, and confirm that it reflects how the system actually runs.

Confirm with your own assessor which of these artifacts they expect to see first, because the policy and design documents are examined directly under the control.

Where organizations fall short on AC-25 and how to close each gap

AC-25 sits outside the SP 800-53B baselines, so the gaps tend to start with a missing decision and spread into design, administration and evidence. Each card names one gap an assessor is likely to find and a concrete way to close it before the assessment starts.

No recorded decision to adopt AC-25

Because SP 800-53B Release 5.2.0 does not select AC-25 for the low, moderate or high baselines or the privacy baseline, many systems never consider it. Record a tailoring decision in the system security plan that either adopts AC-25 with its organization-defined parameter values or explains why the defined access control policies do not need a reference monitor. Assessors will look for that decision before they look at any mechanism.

Enforcement paths that bypass the monitor

A reference monitor only helps if every access request reaches it. Secondary APIs, batch jobs, replicated data stores and administrative consoles often authorize requests on their own. Map each enforcement path for the defined policies, then confirm through configuration review and traffic testing that none of them grant access without the monitor's decision.

Monitor too large to analyze

The control requires a mechanism small enough to be analyzed and tested so its completeness can be assured. A monitor that mixes policy logic with business features or lacks design documentation fails that test in practice. Keep the monitor's scope narrow, document its interfaces and decision logic in the system design documentation, and confirm that the design can be reviewed by a person who did not build it.

Administrators change policy without controls

If system and network administrators can edit policy objects, attribute values or monitor configuration without review, the monitor can be altered without anyone noticing. Put policy changes under the same approval, change control and audit logging used for other security-relevant configuration, and limit who holds the rights to modify them. Assessors interview these administrators, so their answers must match the logs.

No testing for bypass or tampering

Assessors test the mechanisms that implement access enforcement, which includes whether the monitor can be bypassed or modified. Teams often test only that allowed users get access and denied users do not. Add negative tests that attempt direct data access, policy file modification, and disabled or reordered checks, and keep the results with the assessment evidence. Independent security testing can supply these tests, but the organization owns the results.

Evidence not refreshed after changes

A passing test from last year does not show that the monitor still works after an upgrade, a new integration or a policy change. Set a trigger for re-running the bypass and tamper tests after each relevant change, and record the date, version and result of each run in the assessment report. Stale evidence is one of the most common reasons an assessment finding stays open.

AC-25 reference monitor questions buyers ask before hiring help

Does AC-25 apply if my system is not in a baseline?

Yes, it can apply, but only if your organization chooses to select it. SP 800-53B Release 5.2.0 does not select AC-25 for the low, moderate or high baselines or for the privacy baseline, so a system categorized at any impact level will not require it by default. You can add it by tailoring a baseline or by adopting an overlay that includes it, and an assessor will then test it against the parameter you define. Decide by asking whether your access control policies are sensitive enough that you need assurance that the mechanism enforcing them cannot be bypassed or altered. Your contract, authorizing official or internal risk owner should record that decision in the system security plan, with the rationale.

How much effort does a reference monitor take to implement?

The effort depends on how many access decisions your system makes and how many distinct enforcement points it has, not on a fixed figure. Work usually grows with the number of applications, APIs, databases, administrative paths and network points that enforce the same policy, because each must route through one mechanism that is always invoked. Other drivers include how much of the existing access logic is already centralized, how small and reviewable the mechanism can be made, and how much design documentation and test evidence must be produced for the assessment. NIST does not estimate implementation effort, so ask for a scope-based estimate that lists the enforcement points in writing.

What does the work need from our internal team?

Your team owns the access control policy, the decisions it encodes and the sign-off on the design. Expect to provide the following in a form the work can use:

Written access control policies and the authorization rules they produce
Inventory of every system component that enforces access to protected information
Administrators who can explain current enforcement paths and configuration settings
Named staff for interviews, since SP 800-53A lists personnel with access enforcement responsibilities and system administrators as interview objects
Access to test environments and audit records so the mechanism can be exercised and its logs reviewed

Can an in-house team implement AC-25 without a partner?

Yes, an in-house team can implement it if it has the design skills, time and access to every enforcement point. The hard parts are usually architectural: centralizing decisions so the mechanism is always invoked, protecting it from tampering, and keeping it small enough to analyze and test. Teams that already run a central policy engine or identity-aware gateway have a head start. A partner is most useful when the enforcement points are spread across many platforms, when the design must be documented to assessor expectations, or when you need a fixed-scope delivery with written deliverables. Whichever route you take, the organization remains accountable for the control.

What can an implementation partner not do for AC-25?

An implementation partner cannot issue the assessment result. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms and prepares the systems and evidence an assessor will examine, interview and test. Only an independent assessor or the authorizing body reaches the finding that AC-25 is satisfied, and only the organization can accept the residual risk and decide whether the control is selected at all. A partner also cannot guarantee that an assessment will pass. Ask any partner to state this division of responsibility in the written scope.

What should we ask for in a written quote?

Ask for a quote that follows from a written scope, not a generic price. The scope should name the systems and enforcement points covered, the access control policies in use, the design documents and test evidence to be delivered, and the assessment objects the work is meant to support. It should separate one-time work, such as design, implementation and documentation, from recurring work, such as monitoring, upgrades and retesting. Confirm who performs interviews and walkthroughs, what happens if the scope changes, and which deliverables are handed over. DeployOpen does not publish a price list, and a quote follows from that written scope.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares the systems, design documentation and evidence that an assessor would examine for AC-25. Your organization owns the reference monitor requirement and the policy it enforces, while an independent assessor decides whether the control is met.

How we scope

Confirm which defined access control policies the reference monitor must mediate, and which systems and resources fall inside that boundary.
Record the organization-defined parameter for AC-25 and the owner who approves it in the written scope.
Agree the related controls to examine, such as AC-3, AC-24, SA-8 and SC-3, so the scope matches the system security plan.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts. Ongoing support is available as a retainer.

How we build

Design or review the enforcement point so that every access request to the in-scope resources passes through it without a bypass path.
Harden the mechanism for tamperproof operation, limiting administrative access, protecting its configuration and logging changes to it.
Test completeness by attempting access paths that skip the mechanism, then keep the results as test evidence for assessors.

How we hand over

Deliver design documentation that describes the mechanism, its scope, its trust boundary and the reasons it is small enough to analyze.
Provide configuration baselines, test scripts and results, and the audit records that show the mechanism was invoked for access decisions.
Map each artifact to the SP 800-53A examine, interview and test objects for AC-25, so your assessor can trace evidence to each item.

How we support

Keep the reference monitor documentation current when platform versions, policies or the system boundary change.
Repeat completeness testing after upgrades or patches, and record each retest in the same evidence set.
Support your assessor with questions on design and test results. Only the independent assessor issues findings or reports.