03.01.02 Access enforcement: requirements and evidence

What 03.01.02 access enforcement requires in practice

Access enforcement asks whether your systems technically block access that your own policy forbids. If a contract or a DFARS clause requires NIST SP 800-171, 03.01.02 is the requirement where the access control policy has to show up as actual system behavior. The risk it addresses is unauthorized access to CUI through the system itself: a user who was never approved, or whose approval was withdrawn, can still open a file, query a database or call an API because nothing in the platform enforces the decision. A written policy that says only approved people may see CUI does not satisfy the requirement on its own. The assessor will look for the mechanisms that make the policy true, such as role-based permissions, file system ACLs, application roles and service accounts that grant only what the approved authorization list allows.

What makes this hard is consistency. Most environments enforce access in several places at once: the operating system, directory services, each business application, file shares, collaboration tools, databases and cloud services. Each one has its own permission model, its own default settings and its own administrators. A group that is approved in the directory may still have broad rights in a legacy application, or a service account may bypass the rules entirely. Before work begins, inventory every system that stores or processes CUI and record how each one decides who gets access. Then confirm, with a sample of real accounts, that a denied request is actually denied. Open-source identity components such as authentik, which can act as the identity provider for applications over OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, can centralize that decision, but only where each application is configured to delegate sign-in to them.

Two related points help set scope. The Rev. 2 wording of this requirement (3.1.2) was treated by NIST as an editorial-only change in its change analysis, so organizations already assessed against Rev. 2 are not starting from scratch on the substance. NIST also states that withdrawn requirement 03.13.03 is addressed by 03.01.02 together with 03.01.01, 03.01.03 through 03.01.07, so enforcement evidence you collect here can support those requirements too. Confirm the exact mapping and any contract-specific wording with your contracting officer or assessor before you rely on it.

Which systems and access paths fall under access enforcement

Access enforcement applies wherever a system grants or denies logical access to CUI or to the resources that protect it. The components below are where that enforcement usually lives, and the scoping choices for each decide how much evidence an assessor will ask you to produce.

Operating systems and hosts

Every server, workstation and virtual machine that stores, processes or administers CUI enforces access through its local file permissions, logon rights and privilege settings. Assessors commonly sample these hosts to confirm that the permissions match the approved authorization list. Check whether local administrator groups are documented and whether accounts outside the CUI boundary can reach these hosts over the network.

Directories and single sign-on

A central directory or identity provider often decides who can authenticate to many applications at once, so it is the main point of enforcement for the whole environment. Identify which group memberships grant access to CUI and who can change them. FreeIPA, for example, provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, so its group policy becomes part of your evidence.

Applications and delegated sign-in

Each application that displays or processes CUI must either enforce its own roles or delegate sign-in and authorization to a shared provider. Confirm which applications rely on local accounts, which use the identity provider, and which bypass it entirely. authentik can act as an identity provider through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, but each application still needs its role mapping checked.

Databases and data stores

Database roles, schema grants and service accounts often grant broader reach than the application that sits in front of them. Assessors will look for CUI tables that can be read directly by analysts, reporting tools or backup jobs outside the approved authorization list. Document each role, its members, and which service accounts can query CUI without a named human owner.

Cloud consoles and shared SaaS

Cloud administrative consoles and third-party SaaS products that hold CUI are a scoping decision in their own right. A provider that stores CUI is generally part of the assessed environment, so confirm with your contracting officer or sponsor how that provider is treated, and what its tenant administrators can see. Ask whether shared corporate tenants or shared services fall inside your boundary before you finalize access rules.

File shares and enclave boundaries

File shares, collaboration sites and backup targets are where CUI is most often copied without anyone deciding to. If you limit CUI to a dedicated enclave, every path into it, including file shares and administrative jump hosts, must enforce access at the enclave edge. Confirm that no share outside the enclave can mount or replicate CUI, because a single unmanaged share can pull the whole environment into scope.

How an assessor tests access enforcement under SP 800-171A

This table maps each assessment method in SP 800-171A Rev. 3 for 03.01.02 to the objects an assessor reviews, the samples they usually pull and the findings that tend to appear. Read it as a preparation checklist: each row names what to have ready before the assessment begins.

Assessment method	Objects the assessor reviews	Common findings to prevent
Examine	Access control policy and procedures, procedures for access enforcement, system design documentation and the list of approved authorizations (user privileges)	Procedures that describe enforcement in general terms without naming the systems or roles they cover
Examine	System configuration settings that control access to CUI and system resources	Settings that differ from the approved list, or defaults left in place on applications and services
Interview	Personnel with access enforcement responsibilities, system administrators and personnel with information security responsibilities	Administrators who cannot explain how approvals are recorded or who can change them
Test	Mechanisms that implement the access control policy, such as directory groups, application roles and file permissions	Access paths that bypass the mechanism, such as shared accounts, local admin logins or direct database access
Sample comparison	Granted access for a selection of users and resources, compared with the approved authorization for each	Authorizations that exceed the approved list, or access granted without a recorded approval
Sample comparison	Systems in the CUI boundary, including cloud services, SaaS applications and remote access paths	Systems outside the documented boundary that still hold or expose CUI with uncontrolled access
Change evidence	Records of authorization changes, reviews and removals over the assessment period	Reviews that were planned but not performed, or removals that were never applied in the system

Sequence for enforcing approved access to CUI

The sequence turns the access control policy into enforced rules on every system that holds or reaches CUI, and leaves a record that an assessor can examine, interview against and test. Each step produces an artifact that the next step depends on, so gaps surface before an assessment rather than during it.

Define the approved authorization list
Start by listing who may reach CUI and which system resources they may use, with the role or privilege behind each entry. The organization owns this list, usually drawn up by the data owner and the security lead, and it becomes the reference point for every later step. The step is done when each entry names a user group, a resource and an approving owner, and when the list is reviewed against the current access control policy. An assessor will examine this list first, because the requirement is judged against it.
Confirm the access control policy and procedures
Check that the access control policy and the procedures for access enforcement state the approved authorizations, who approves changes and how exceptions are recorded. Rev. 3 discusses 03.01.02 alongside the policy and procedures requirement in 03.15.01, so the policy must exist and be current before enforcement is judged. The organization owns the policy text. An implementation partner can help draft or align the procedures, but the approvals are the organization's. Confirm any organization-defined parameters that the policy depends on, such as review intervals or approval roles, and record the values chosen. The step is done when the policy, procedures and parameter values are approved and version-controlled.
Document how each system enforces access
For each operating system, application, service and identity source that holds or processes CUI, write down the mechanism that enforces the approved list. Typical mechanisms include file system permissions, database roles, application role checks, directory group membership and identity provider policies. Record where the authorization decision is made and where it is stored. Where an application delegates sign-in to a central identity provider, such as authentik acting through OAuth2, OpenID Connect, SAML, LDAP or proxy providers, document which provider and group mapping control access. The step is done when every in-scope component has a written enforcement description that an assessor could follow without help from the administrator.
Configure enforcement on each component
Implement the documented rules in each system, using the mechanisms identified in the previous step. Configure directory groups, role mappings, resource permissions and deny-by-default settings so that access exists only where the approved list allows it. Keep configuration in version control or a change record so the settings can be exported and compared later. Where a directory such as FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, confirm which hosts and services actually honor its policy. The step is done when the configuration matches the documented design and the change records show who made each change and when.
Test enforcement with negative cases
Verify that enforcement blocks what it should block, not only that approved users can still work. For each resource, attempt access as a user who is not on the approved list, as a user whose role was removed, and as a user from an adjacent group. Include direct attempts that bypass the application, such as reaching a file share or database without going through the front end. Record the account used, the resource, the expected result and the actual result. Failed negative tests are findings to fix and retest, not notes to file. The step is done when every resource has at least one denied test with captured output, and every failure has a documented fix.
Review assignments and remove accumulated access
Run a periodic review of who holds which assignments, because enforcement that matches the approved list on day one can drift as people change roles. Access certification campaigns, such as those in midPoint, have designated reviewers decide within a set timeframe whether to keep, change or revoke each access item, which also helps counter access accumulation and supports segregation of duties. Set the review frequency in the policy and record the reviewer, decision and any revocation. The step is done when the review produces signed decisions, and the revocations are reflected in the systems tested in the previous step.
Capture evidence for each step
Gather the outputs of every earlier step into one evidence set organized by the assessment objects in SP 800-171A Rev. 3 for 03.01.02: the access control policy and procedures, the approved authorization list, the system design and configuration settings, the negative test results, and the review records. Name each artifact with its date and owner. Map interview preparation to the people who run enforcement, including system administrators and personnel with information security responsibilities, so they can explain their steps consistently. Confirm with the assessor, before the assessment, which format they expect. The step is done when an assessor could trace one approved user from the authorization list, through the policy, the configuration and the test, to the review record.

Why enforcement must be tested, not only documented

An access authorization list on paper does not satisfy 03.01.02 on its own. The requirement asks that the system enforce approved authorizations, so an assessor will look past the policy and the approval records to the mechanism that actually stops an unauthorized user from reaching CUI or a system resource. Under SP 800-171A Rev. 3, the examine objects include the list of approved authorizations and the system configuration settings, but the test object is the mechanism implementing the access control policy. Expect the assessor to ask who can open a CUI share, which role grants that right, and what happens when a user outside the approved list tries the same action.

Identity federation and enforcement are different things, and the difference matters in an assessment. A federated sign-in tool proves who the user is and passes identity to an application, but the application or the operating system still has to check the authorization before granting access. authentik can act as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Neither tool, by itself, shows that every CUI resource refuses unapproved requests. Confirm in your own environment which resources bypass the identity provider, such as local accounts, database logins or direct file share paths.

Periodic review is the evidence that keeps enforcement aligned with the approved list over time. midPoint access certification campaigns let designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, which counters access accumulation as people change roles. Retain campaign records, reviewer decisions and revocations as evidence. Before relying on any of these tools, confirm with the vendor documentation and a test in your environment that the connectors, group mappings and resource enforcement behave as your access control policy requires. Your assessor will test the result, not the tool's feature list.

Evidence that passes access enforcement and how to keep it current

An assessor testing 03.01.02 examines documents, interviews administrators and tests the mechanisms directly, so the evidence has to agree with what the system actually does. The six artifacts below cover each of those three lines of inquiry, and each one goes stale unless someone owns a refresh step tied to a change or a review cycle.

Access control policy and procedures

The policy states who may approve access to CUI and system resources and how enforcement is meant to work. Rev. 3 discussion of 03.01.02 points to 03.15.01 for policy and procedures, so the document should be traceable to that family as well. Check that the policy names owners, the approval path and the review trigger, and that the procedures describe the enforcement points in your actual environment. Record the version, approver and date of each revision.

List of approved authorizations

This is the record of user privileges that the system is expected to enforce, and SP 800-171A names it as an examine object. An assessor will compare it against live directory groups, role bindings and application permissions. Keep it generated from the identity source where possible, and reconcile it on every joiner, mover and leaver event. A static spreadsheet that drifts from the directory is the most common reason this artifact fails.

System design and configuration exports

Export the configuration that proves enforcement is switched on: identity provider application bindings, LDAP or Kerberos policy, authorization rules, and file or database permission settings. Store exports with a timestamp and the change ticket that produced them. Repeat the export after every change to the identity or access layer, and diff it against the previous version so the reviewer can see what moved and why.

Sample access tests with results

Test mechanisms directly: attempt access as a user without approval, as a user with approval, and as a user whose role was removed. Record the account used, the resource, the expected result and the observed result. Repeat the sample set after major changes and keep the raw output. Tests should cover the applications and services that hold CUI, not only the directory, because enforcement is only as strong as the weakest application that trusts it.

Interview-ready administrator procedures

Assessors interview personnel with access enforcement responsibilities and system administrators. Each administrator should be able to walk through how a request is approved, provisioned, verified and revoked without reading from a script. Keep a short runbook per enforcement point, name the backup administrator, and rehearse the walkthrough after staff changes. Confirm that the runbook matches the configuration export, since interviews often expose gaps between documented and actual practice.

Access review records

Periodic certification campaigns show that someone checked whether existing access still fits the approved authorizations. Records should name each reviewer, the scope, the decision to keep, change or revoke, and the date the revocation was completed. In midPoint, access certification campaigns record these decisions with designated reviewers and a set timeframe. Schedule reviews at an interval your policy defines, and retain the completed campaign output with the revocation evidence.

What meeting 03.01.02 costs in money and effort

This table breaks the cost of enforcing access authorizations for CUI into one-time and recurring components, names who is paid for each, and shows what drives it up or down. Use it to shape the questions you put to an implementation partner, an assessor or a consultant before you sign a written scope.

Cost component	Who is paid or who bears the cost	One-time or recurring	What drives it up or down
Policy alignment with the access control policy	Your staff, with optional consultant time for drafting and mapping to 03.01.02 and 03.15.01	One-time, then reviewed periodically	Number of policy documents already in place and how many roles must be defined
Inventory of systems that enforce access	Your engineers, or an implementation partner under a fixed scope	One-time, refreshed when systems change	Number of operating systems, applications, services and cloud accounts holding CUI
Configuration of enforcement across systems	Platform engineers or an implementation partner; open-source licenses usually carry no fee	One-time build, then ongoing change work	Number of identity sources, integration points and applications that must delegate sign-in
Testing of enforcement mechanisms	Your security team or a testing firm, and an assessor reviews the results	One-time for the assessment, repeated on change	Number of test cases per system and whether negative tests of denied access are included
Access reviews and certification campaigns	Your access owners and managers, with platform engineers for tooling	Recurring, on the frequency you set in policy	Number of users, roles and privileged accounts, and how often roles change
Evidence collection and refresh	Your compliance lead and system owners	Recurring, before each assessment or SPRS update	How much evidence is generated automatically in logs and configuration exports
Assessor or consultant time for the assessment cycle	Independent assessors or consultants, paid by you	Recurring at each assessment cycle	Scope of the CUI boundary and the number of systems in scope for 03.01.02
Open-source software licenses	No license fee for the open-source platforms named on this page, but hosting and staff time still apply	Recurring hosting and support cost only	Choice of hosting, support model and whether you buy vendor support or retainers

Who owns access enforcement and who can help

Your organization owns the access control policy and every authorization that the system enforces. Under 03.01.02, the system must enforce approved authorizations for logical access to CUI and to system resources, so the decisions about who may reach what sit with your leadership and system owners, not with an outside party. Assessors will expect named people with clear responsibility for enforcement, and they will interview them.

Policy and approved authorizations: Maintain the access control policy and the list of approved authorizations (user privileges) that the examine method looks for.
Enforcement design: Decide which applications, services and operating systems hold CUI and must enforce the policy, and document the design.
Configuration ownership: Keep accountable administrators who approve and track configuration settings that enforce access.
Review and evidence: Run periodic access reviews and keep the records that show who approved what.
Interview readiness: Make sure system administrators and personnel with access enforcement duties can explain how enforcement works.

Confirm internally who signs off on the authorization list and who answers assessor interviews before any outside help is engaged.

Where access enforcement usually fails an assessment

Assessors testing 03.01.02 Access enforcement look for proof that the system itself blocks unauthorized access, not just that a policy exists. The gaps below are the ones that most often turn a clean policy into a finding, and each one has a closing action the organization can complete and show as evidence.

Enforcement in one system only

Access checks are configured in the main application, but the database, file share, admin console or API can still be reached directly by users or service accounts. An assessor who tests a second path to the same CUI will see the enforcement as incomplete. Map every route to CUI, including reporting tools and backups, and confirm each one applies the same authorization decision. Record the mapping in the system security plan.

Approved lists that do not match reality

The list of approved authorizations is the document an assessor compares against live permissions. When group memberships, inherited roles or old project grants differ from that list, enforcement looks like it is working only on paper. Export effective permissions from each system, compare them with the approved list, and resolve every difference before the assessment. Keep the export and the reconciliation as dated evidence.

Shared and generic accounts

Shared logins such as a common operations or vendor account bypass per-user enforcement, so the system cannot tell who did what with CUI. Assessors often find these during interviews with system administrators. Identify every shared or generic account, move each use to a named account or a documented service identity, and disable the shared credential where possible. Confirm the change in the account inventory.

Authorization enforced by convention

Some applications rely on menus hiding functions, or on staff remembering not to open a folder, rather than on server-side checks. The display of a restriction is not the same as its enforcement. Test each sensitive function with a user who lacks the authorization and record the denied result. Where the application cannot enforce the rule, document the compensating control and its limits.

Central identity provider not in the path

Applications that keep their own local user stores can drift from the directory, so a removed authorization still works inside the app. Where an identity provider is the source of sign-in, such as authentik acting as provider for OAuth2, OpenID Connect, SAML, LDAP or proxy access, confirm each application actually delegates sign-in to it. Then check that local fallback accounts are disabled or tightly controlled.

No recorded tests or review cycle

An assessor will ask how the organization knows enforcement works and keeps working. Without test records or periodic reviews, the answer is an opinion. Schedule access certification campaigns in which designated reviewers keep, change or revoke each access item within a set timeframe, as midPoint supports, and keep a negative test log showing denied attempts. The review records are the strongest evidence for this requirement.

Questions about 03.01.02 access enforcement

How much effort does access enforcement take to implement?

The effort depends on how many systems hold CUI and how many of them already enforce role-based authorizations centrally. No researched figure for effort is available here, so treat any number you see from a vendor or consultant as unverified until it is tied to a written scope. In practice the work falls into three parts: documenting the access control policy and the approved authorizations (the list of user privileges an assessor will examine), configuring each operating system, application and service so it enforces those authorizations, and collecting evidence that the configuration works. The first two parts are where most of the time goes, and they scale with the number of systems in the CUI boundary. Ask any provider to break its estimate down by system and by evidence item.

Can our team meet 03.01.02 without outside help?

Yes, a team with administrators who understand their own systems can do this internally, provided they have time and a clear owner for the policy. The requirement itself is short: it asks that the system enforce approved authorizations for logical access to CUI and system resources, in line with the access control policy. Outside help is most useful where the team lacks experience with identity federation, directory services or evidence collection, or where an assessor's examine, interview and test steps need to be rehearsed beforehand. Whatever you decide, the organization still owns the control. An implementation partner can prepare systems and evidence, but only an independent assessor can report on the result.

What does the work require from our staff and systems?

The work needs four inputs before any configuration starts:

An access control policy that names who approves access to CUI and how approvals are recorded.
A current list of approved authorizations, meaning the user privileges granted on each system.
System design documentation and configuration settings that show where enforcement happens.
Named people responsible for access enforcement, including system administrators and the information security owner, who can be interviewed.

SP 800-171A Rev. 3 expects these items to exist and to match what the system actually does. Gaps between the documented authorizations and the live configuration are the most common reason evidence fails review, so reconcile them early.

How long does 03.01.02 take to put in place?

No duration is supplied for this requirement, so this page does not give one. The timeline depends on scope, existing identity infrastructure and how many systems must be reconfigured, and any estimate should come from a written scope. Ask a provider to state the dependencies: whether policy approval is needed before technical work starts, whether changes must go through a change window, and how long evidence collection takes after configuration is complete. Also confirm whether your contracting officer or assessor expects a particular sequence across the 17 Rev. 3 families, since access control interacts with account management, least privilege and remote access.

Does the Rev. 2 3.1.2 wording change the work for 03.01.02?

The technical work does not change. NIST's Rev. 2 to Rev. 3 change analysis traces 03.01.02 to Rev. 2 requirement 3.1.2 and classifies the change as not significant, meaning editorial only. Organizations that already meet 3.1.2 under Rev. 2 are in substantially the same position under Rev. 3, though the Rev. 3 assessment procedure has its own determination statements and should be read directly. Rev. 3 also points to the policy and procedures requirement in 03.15.01 for the underlying documents. Confirm with your contracting officer which revision applies to your contract, because the revision in force decides which assessment you prepare for.

How does CMMC scoring treat 3.1.2 on a plan of action and milestones?

CMMC Level 2 assesses Rev. 2 requirement 3.1.2 as AC.L2-3.1.2, and under the 32 CFR 170.24 scoring methodology it carries 5 points. Under 32 CFR 170.21, that requirement cannot be placed on a plan of action and milestones to reach Conditional status. In practice, this means access enforcement must be working before an assessment, not documented as a future fix. Treat it as a must-pass item in your readiness plan. Confirm current CMMC phase timing and contract requirements with the contracting officer, since they can change independently of the technical control.

Can DeployOpen certify that our access enforcement meets 03.01.02?

No. DeployOpen plans, implements, integrates and hardens self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. For 03.01.02, that means DeployOpen could help configure enforcement in systems such as identity providers and directories, and help assemble the policy, authorization list and configuration evidence. The organization owns the control, and an independent assessor or certification body must reach the conclusion. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen prepares access enforcement evidence

DeployOpen works on 03.01.02 Access enforcement as an implementation partner. We prepare the systems that enforce approved authorizations for logical access to CUI, and the evidence an assessor will examine, interview and test against. The organization keeps ownership of its access control policy and its control decisions, and an independent assessor reaches the conclusion.

How we scope

Engagements are fixed-scope, with systems, applications and services in the 03.01.02 boundary agreed in writing before work starts.
We map which operating systems, applications and services enforce access to CUI, and which rely on an external identity source.
Scope records the access control policy, approved authorization lists and named owners the assessor will ask to see.

How we build

We configure identity and access components so that each in-scope application delegates sign-in and authorization to a central, documented source.
Where open-source identity tools such as authentik or FreeIPA are used, we configure providers and directory policy to match the approved authorizations.
We test enforcement directly, confirming that a user without an approved authorization is denied access to CUI in each in-scope system.

How we hand over

Deliverables include configuration records, design documentation and test results that show how enforcement works for each in-scope system.
We provide a list of approved authorizations exported from the system, so the organization can show who holds access to what.
Documentation is written for the examine, interview and test steps an independent assessor uses, with the organization's own staff trained to explain it.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can repeat enforcement tests after changes to identity providers, applications or access policy, and update the evidence set.
Confirm with DeployOpen during scoping how access certification reviews and assessment support will be covered in the written scope.