AC-3 Access enforcement: requirements and evidence

What AC-3 access enforcement asks a system to do

If an assessment, a baseline selection or an engineering ticket has brought you to AC-3, the short answer is this: AC-3 requires the system to enforce approved authorizations for logical access to information and system resources, in line with the applicable access control policies. The control is not about whether a policy exists or whether access is approved on paper. It asks whether the system itself stops an unauthorized request and allows an authorized one. AC-3 is selected in the low, moderate and high security control baselines in SP 800-53B Release 5.2.0. It is not selected in the privacy baseline, although the privacy baseline does include AC-3(14) on individual access.

The risk AC-3 addresses is a gap between authorization decisions and system behavior. An organization may have a sound role model, approved access requests and a clear policy, yet an application still grants a user a record, an export or an administrative function that nobody approved. That gap usually sits in the enforcement layer, not the policy layer. Your first task is to find every place where a decision is made: the identity provider, the directory, the application's own permission checks, the database, the file share and the API gateway. Each one that grants access must honor the same approved authorization, or the control is only partly met.

AC-3 is hard for predictable reasons. Enforcement is spread across many applications, each with its own roles or permission model. Role data is often inconsistent between the corporate directory, the HR system and application databases, so the same person may hold different rights in different places. Some applications enforce access only in the user interface, which an assessor will not accept as enforcement. Before you size the work, ask your team to list each system that grants access to sensitive data and to confirm which of them enforce decisions in the back end. That inventory is the starting point for both an assessment and a remediation plan.

Which systems, data and teams AC-3 applies to

AC-3 applies wherever information or system resources are accessed, so scoping starts with the impact level and then follows the enforcement chain. The cards below cover the decisions that change where enforcement lives and who must prove it works. The baseline selects AC-3 itself at the low, moderate and high levels but no enhancements, so scope determines where the control is implemented, not which enhancements to add.

Impact level selects the baseline

The system's security categorization determines whether the low, moderate or high SP 800-53B baseline applies. AC-3 is selected at all three levels, so the impact decision does not change whether AC-3 applies. It changes the surrounding controls that depend on it, such as the enhancements in other families and the depth of testing. Confirm the categorization in the system security plan before scoping enforcement points, because it sets the boundary every other card depends on.

Systems and data stores holding protected information

Enforcement must exist wherever protected information is stored or processed, including databases, file shares, object storage, backups and reporting platforms. Inventory each store and record which mechanism enforces authorizations on it, whether an operating system permission, a database role or an application check. Stores reached only through an application are often missed, so ask the team to trace data flows from source to every copy.

Applications that delegate sign-in

Applications that hand authentication to a central identity provider still need their own authorization decisions. Sign-in delegation proves who the user is, not what they may do inside the application. Map each delegating application's roles and claims to the approved authorizations, and confirm which application checks enforce them. An identity provider such as authentik can issue OAuth2, OpenID Connect or SAML assertions, but it does not make decisions inside the application.

Applications that make their own decisions

Some applications authenticate users and also decide what each user may see and change. These applications carry the enforcement burden directly, so assessors examine their role models, permission checks and audit records. Ask the owner to document where each decision is made, which data it protects and how a change to a permission reaches the check. Test a sample of restricted actions with a non-privileged account to confirm the decision holds.

Directory and provisioning chain

Access decisions depend on accounts and group memberships that are created, changed and removed upstream. Synchronization from a directory such as FreeIPA or Active Directory, and provisioning tools such as midPoint, move those attributes into target systems. A stale group or a failed deprovisioning job can leave access enforced against the wrong data. Identify which tool writes each attribute, how often it reconciles, and which system is authoritative when two sources disagree.

Third parties operating enforcement

Managed service providers, hosting companies and software vendors may run parts of the enforcement chain, such as administrator consoles or hosted identity services. Their controls still count toward your AC-3 evidence, so the contract and service documentation must state who configures each enforcement mechanism. Ask each third party for the access list for its administrative accounts and for the logs it can produce on request. Where a third party cannot show enforcement, treat that segment as out of compliance until it does.

Role-based, attribute-based, mandatory and discretionary enforcement explained

The access control models behind AC-3 answer one question: on what basis does the system decide that a request is allowed? Role-based access control grants access by job function. Under AC-3(7), the system enforces access according to roles assigned to users, so a payments analyst receives the permissions of that role and nothing more. Attribute-based access control, described in AC-3(13), goes further by evaluating attributes of the user, the resource, the action and the environment, such as department, data classification, device posture or time of day. Roles work well when access follows stable job functions. Attributes fit decisions that depend on context, such as allowing access to a record only when the requester's region matches the record's region.

Mandatory access control is the model in which a central policy assigns labels to subjects and objects, and users cannot change those labels or pass access on to others. Discretionary access control lets the owner of a resource decide who else may use it. Dual authorization, the enhancement that requires two authorized people to approve a sensitive action before it completes, is a separate mechanism that adds a second approver rather than a model in its own right. For most commercial systems the practical choice is between role-based and attribute-based enforcement, with mandatory controls typically needed where labeled classifications are required by policy. Confirm with your policy owner which of these your authorization decisions must reflect before you choose a product.

Two catalog facts shape the scope of this work. AC-3 has 15 numbered enhancements in SP 800-53 Release 5.2.0, but AC-3(1) and AC-3(6) are withdrawn, leaving 13 current enhancements. SP 800-53B selects no AC-3 enhancements for the low, moderate or high baselines, so the enhancements matter mainly where your authorizing official or contract adds them through tailoring. The privacy baseline includes AC-3(14) for individual access, which requires the system to let individuals access their own personal information, so privacy-scoped systems need that path tested as well. Ask your assessor which enhancements your system is expected to implement and record each choice in the system security plan with its rationale.

How an assessor tests AC-3 access enforcement

This table maps the single AC-3 determination statement and its examine, interview and test objects to what an assessor does, the evidence requested and the findings that commonly appear. Read each row as one assessment method, and expect the test row to carry most of the weight in an assessment.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine: list of approved authorizations (user privileges)	Compares the documented authorizations for information and resources against the access control policy, checking that each approval has an owner and a basis.	Current authorization matrix or role-to-permission list, approval records, and the policy version in force during the assessment period.	Authorizations are documented but stale, or approvals exist for accounts that no longer have a business need.
Examine: system audit records	Reviews logs of access grants, denials and permission changes to confirm that enforcement decisions match approved authorizations.	Audit records of access decisions, denied-access entries, and records of privilege changes over a sampled period.	Logs are missing for denied requests, or sampled access grants cannot be traced to an approval.
Interview: personnel with access enforcement responsibilities	Asks system owners and access administrators how authorizations are applied, changed and removed, and how they handle exceptions.	Walkthrough of the enforcement process, responsibility assignments, and examples of recent exception handling.	Staff describe a process that differs from the written procedure, or exceptions are granted informally.
Interview: system and network administrators	Confirms with administrators which enforcement mechanisms they operate and whether they can override them directly.	Administrator access lists, description of configuration ownership, and records of manual overrides.	Administrators hold undocumented override rights or can change enforcement settings without review.
Test: mechanisms implementing the access control policy	Attempts access with accounts holding different authorizations to see whether the system grants or denies each request as the policy requires.	Test plan, test accounts and their intended permissions, and recorded results showing allowed and denied actions.	Enforced permissions are broader than the approved authorizations, or a mechanism was never tested against the policy.

Implementing AC-3 in sequence, with the output of each step

This sequence turns the AC-3 requirement into a working enforcement design: each step produces a record that the next step depends on, so an assessor can trace an approved authorization from the policy to the mechanism that enforces it.

Inventory systems and resources that need enforcement
Start by listing every system, application, database, file share, API and administrative console that holds information or exposes functions needing logical access control. Name the owner of each resource and note its impact level, since the SP 800-53B low, moderate and high baselines select AC-3 for each of them. Involve system owners and the team that runs the directory, because they usually know resources that never reached the asset register. The output is a resource inventory with an owner and a system boundary for each entry. The step is done when every item in the system security plan's boundary has an owner and an entry.
Define the authorization model and approved authorizations
Decide which model governs each resource: role-based access control, attribute-based access control, or a discretionary or mandatory model where the data or mission requires it. Role-based access fits most enterprise applications, while AC-3(7) and AC-3(13) describe the role-based and attribute-based forms that assessors may ask you to explain. Then record the approved authorizations: which roles or attributes may perform which actions on which resources, and who approved each one. The output is an authorization register that maps resources to roles or attributes, actions and approvers. Confirm the model with your access control policy owner before building mechanisms on it.
Choose enforcement mechanisms for each system
For each resource, select where enforcement happens: an identity provider that issues tokens or assertions, a directory that holds group membership, the application's own authorization logic, or a gateway or proxy in front of it. Open-source options include authentik for OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, FreeIPA for Linux and UNIX single sign-on, and Keycloak for federated directory users. Confirm in each product's documentation which features your version supports, because capabilities differ by release. The output is a mechanism inventory that names the enforcement point, the product and version, and the resources it protects. Record any resource enforced only by application code, since assessors will test that code path separately.
Connect authorization data to the policy
Make the authorization register the source of truth for what the mechanisms enforce. Map each approved role or attribute to a group, claim or policy object in the chosen mechanism, and use a provisioning tool such as midPoint where accounts and role assignments must flow to connected systems. midPoint can create, update and delete accounts based on user changes and role assignments, and it keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separate inbound and outbound rules. Document each mapping and who may change it. The output is a configuration baseline that ties every register entry to its mechanism setting and records the change approval path.
Test enforcement with positive and negative cases
Write test cases for each authorization in the register. Positive cases confirm that an approved user can perform the allowed action, and negative cases confirm that users without the authorization are denied, including users with a similar role, expired assignments and users from a different organizational unit. Include a test for each enforcement point, not only the primary one, and test the application path separately from the identity provider path. Run tests in a non-production environment that mirrors the production configuration, then repeat them after any change to the mapping. The output is a test result set with expected and observed outcomes, the tester, the date and the configuration version tested. Retain failing results with their remediation.
Document mechanisms and the audit trail
Bring the outputs together in the system security plan and the control documentation for AC-3. Describe each enforcement mechanism, the authorization model, the register, the configuration baseline and the test results, and state which party is responsible for each. Confirm that access decisions and authorization changes are logged, and that those logs feed the audit record controls in the AU family so an assessor can see who was granted or denied access and when. Assign a review owner and a trigger for updates, such as a new resource, a new mechanism version or a change to the approved authorizations. The output is a control narrative and an evidence index that an independent assessor can follow from policy to test result.

Evidence that passes an AC-3 assessment

AC-3 is tested by checking that the approved authorizations are the ones the system actually enforces, and that denials happen when they should. The cards below cover the artifacts that show this, and each one needs a refresh process so it is current when the assessor arrives rather than rebuilt for the audit.

Approved authorization lists

Export the approved user privileges, role definitions and attribute rules that the access control policy authorizes, with the approver and approval date for each. Assessors use this list as the reference point for every other artifact. Schedule an export from the directory or identity provider and store a dated copy, so the list matches the enforcement configuration on the same day. Check that every enforced permission traces back to an approved entry.

Role and attribute definitions

Keep the role-based and attribute-based definitions in version-controlled files, covering role names, attribute names, permitted values and the conditions that grant access. These definitions show how AC-3(7) and AC-3(13) are implemented where those enhancements apply. Assessors check that the definitions in use match the approved design, so record who changed each definition and why.

Enforcement configuration exports

Capture configuration exports from each enforcement point, such as the identity provider, directory, application proxy and database permissions. The export shows which mechanism enforces each authorization in practice. Let the deployment pipeline write these exports on every change, so the evidence reflects the running configuration and not a document describing it.

Allowed and denied test records

Keep test records showing that authorized requests succeed and unauthorized requests are refused, for each role and attribute rule. Denied cases matter most, because a control that only shows permitted access does not demonstrate enforcement. Automate these checks in the pipeline and retain the results with the build identifier, so each run ties to a specific configuration.

Audit records of access decisions

Retain logs of allow and deny decisions, including the subject, resource, requested action and the policy that decided. Assessors sample these records to confirm that decisions were made and recorded as the policy requires. Confirm that your platform emits decision-level detail, since some components log only authentication events, and set retention to match the period your authorization requires.

Change records for authorization data

Maintain change records for every modification to roles, group memberships, attribute values and provisioning rules, with the requester, approver and reason. Provisioning tools that create or remove accounts from role assignments generate much of this history, and their change logs should be exported with the directory snapshots. Review the records on a schedule so unapproved changes are found before an assessor samples them.

What meeting AC-3 costs in money and effort

This table compares the cost components of meeting AC-3 Access enforcement, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a written scope and to ask providers and auditors for the figures that only your own environment can produce. No prices or durations are given because none are supplied for this control.

Cost component	One-time or recurring, and who is paid	What drives it up or down, and how to keep it down
Tooling or licenses	Recurring if commercial. Self-hosted open-source identity platforms such as authentik, FreeIPA, Keycloak and midPoint have no license fee, but hosting and staff time remain.	Number of applications and identity sources. Ask each vendor for written subscription terms, and confirm that the open-source projects you choose fit your hosting model and licensing review.
Engineering time to configure enforcement	One-time for initial role model, provider and directory integration, paid to internal staff or an implementation partner under a fixed-scope written plan.	Role model complexity, number of applications and quality of the existing directory. Clean groups in LDAP or Active Directory shorten this work; ask for a scope that lists each application and its enforcement point.
Role and attribute model design	One-time for RBAC (AC-3(7)) or ABAC (AC-3(13)) design, plus periodic revision. Paid to owners of access policy and to any consultant who facilitates the design.	Number of distinct roles and attributes. Keep the model to roles that map to documented job functions, and request a written list of attributes the system will evaluate.
Evidence upkeep	Recurring. Exporting authorization lists, configuration snapshots and audit records each review cycle, paid to internal control owners.	Frequency of changes and number of systems in scope. Automate exports of provider and policy configuration where possible, and confirm retention periods with your auditor.
External testing or review of enforcement	Recurring or periodic. Paid to a security testing provider or an independent assessor for access control testing of enforcement points.	Number of enforcement points and bypass paths tested. Ask for a written test scope that names each application, and confirm which tests your assessor will accept as evidence.
Auditor sampling and assessment	Recurring with each assessment cycle. Paid to the independent auditor or assessor, who samples enforcement configurations and access decisions.	Number of systems sampled and quality of evidence. Prepare a documented list of enforcement mechanisms and their owners before fieldwork, and ask the assessor for the sample size they expect.
Ongoing support and upgrades	Recurring if retained. Paid under a retainer or in-house staff time to keep identity components patched and access rules current.	Upgrade frequency and number of integrated applications. Scope retainers in writing, including which components and reviews they cover.

Open-source tools that support AC-3 enforcement

AC-3 is met when systems enforce the access decisions the organization has approved. In practice, that decision usually passes through an identity provider, a directory and a provisioning engine, so the tools below are most useful as a chain. Each card describes one component, the evidence it can help produce and what to confirm in your own deployment before an assessor reviews it.

authentik as identity provider

authentik (MIT) acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in instead of keeping their own user stores. For AC-3, the useful evidence is the provider configuration that shows which applications accept which authorizations. Confirm that each protected application is bound to a provider, that group or role mappings match the approved authorizations, and that applications without an authentik provider are listed and justified in the system security plan.

FreeIPA for Linux and UNIX access

FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which lets host and service access rely on one directory of identities and groups. For AC-3, it can produce exports of host access rules and group membership that assessors compare with the approved authorization list. Confirm which hosts are enrolled, who can change access rules, and whether privileged access to hosts is handled through a path that FreeIPA does not control.

Keycloak federation with existing directories

Keycloak (Apache-2.0) user federation connects to existing LDAP or Active Directory servers and synchronizes users from them into Keycloak, so accounts managed in the corporate directory drive application sign-in. For AC-3, this means the directory remains the source of approved authorizations and Keycloak enforces them at sign-in. Confirm which attributes and groups are mapped, whether disabled directory accounts stop being accepted, and how often synchronization runs, because a delay can leave removed access active.

midPoint provisioning and reconciliation

midPoint (EUPL-1.2+) creates, updates and deletes accounts on connected systems based on user changes and role assignments. It keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. For AC-3, reconciliation reports are the evidence that account state on target systems matches the approved role assignments. Confirm which target systems are connected, who owns the role catalog, and how accounts created outside midPoint are detected and reviewed.

Who does what for AC-3: your team, a partner and the auditor

Your organization remains accountable for AC-3. Access enforcement only means something if the people who own the business data decide who should reach it, and if those decisions are written down in a policy the organization approves. Your team defines the authorizations, approves exceptions and confirms that the enforced outcome matches what was intended. No partner or auditor can make those decisions for you.

Access control policy: Own and approve the policy that defines who may access which information and resources, and under which conditions.
Authorization decisions: Decide and record who holds each role or privilege, and who signs off on changes.
Information owners: Name the owners of each system and dataset who review whether access still reflects their needs.
Enforcement outcomes: Check periodically that denied requests are denied and approved requests succeed, and act on exceptions.
Ongoing operation: Run the reviews and change approvals that keep enforcement aligned with the policy over time.

Before engaging anyone, confirm internally who signs the authorization decisions and where that approval is recorded.

Questions buyers ask about AC-3 access enforcement

How much effort does it take to meet AC-3 access enforcement?

The effort depends less on writing the control statement than on how many systems, applications and data stores must enforce approved authorizations, and how many of them have their own permission models. AC-3 has one determination statement in SP 800-53A Rev. 5, but assessors examine the mechanisms behind it across every in-scope system. Effort rises with the number of applications that make their own authorization decisions, the number of directories and identity sources, and the amount of manual permission setting. Ask any partner to list the in-scope systems, the enforcement points on each one (identity provider, reverse proxy, database, file share, cloud console) and the evidence each point can produce before agreeing to a scope. The SP 800-53B baseline selection for AC-3 is the same at low, moderate and high, so the difference in effort comes from system scope and the depth of testing, not from extra AC-3 enhancements.

How long does AC-3 work usually take, and what drives the timeline?

No supplied source gives a duration for AC-3 work, so treat any number a vendor quotes as a claim to verify. The timeline is driven by four things: how many enforcement mechanisms exist, whether identity sources are already consolidated, whether approved authorization lists exist and are current, and how much audit evidence is already being retained. Consolidating sign-in through a single identity provider, such as authentik, Keycloak or FreeIPA, often shortens the work because applications then delegate authentication and authorization to one place. Work that depends on application owners changing their own code or permission models usually takes longer because it needs their schedules. Ask for a written plan with milestones, the systems in each milestone and the dependencies on your teams before work starts.

What does AC-3 require from our internal team?

AC-3 needs people who own the authorization decisions and people who can show how systems enforce them. Assessors interview organizational personnel with access enforcement responsibilities and system and network administrators, so those people must be named, available and able to explain the configuration. Your internal team should provide the approved authorization lists (user privileges), decide who may approve changes to them, and confirm which roles and attributes are the basis for access. Application owners must confirm how each application enforces its permissions, and security staff must agree which audit records prove enforcement. A partner can prepare configurations and evidence, but the organization still makes the access decisions and signs off on them.

Can our own team meet AC-3 without an outside partner?

Yes, an experienced internal team can meet AC-3 if it has the skills to configure its enforcement mechanisms and the capacity to document and test them. Organizations usually find the hard part is not the control itself but the sprawl: multiple directories, applications with local accounts, and privileged access paths that bypass the main identity provider. Before deciding, check whether your team can answer these questions: which systems enforce access and how, where approved authorizations are recorded, whether role-based or attribute-based rules are used, and how a sample of decisions can be traced to an approved request. If several answers are unclear, an implementation partner can help with scoping and systems work. Whatever you choose, an independent assessor decides whether the control is satisfied.

What will an auditor sample when testing AC-3?

An assessor following SP 800-53A will examine the list of approved authorizations and the system audit records, interview the people responsible for enforcement, and test the mechanisms that implement the access control policy. In practice, expect the assessor to pick a set of users or roles, compare their granted permissions against approved requests, and then try to access a resource the user is not authorized to use to confirm the system refuses it. Prepare a current authorization register, sample access grants with approvals, and audit records showing denied and granted access. Confirm with your assessor which samples they expect and over what period, because the sample rules are set by the assessor, not by NIST or any tool vendor.

Can a partner issue the AC-3 evidence or the assessment result?

A partner can prepare the systems, configurations, documentation and evidence that an assessment will examine, but it cannot issue the assessment result. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Under FISMA, Inspectors General independently assess agency systems, and for other programs an independent assessor or certification body makes the determination. Ask any partner to state in writing which artifacts it will produce, which will remain the organization's responsibility, and which will be reviewed by your independent assessor. Keep the evidence in your own environment so you can give it to whichever assessor you engage.

How DeployOpen scopes and prepares AC-3 evidence

DeployOpen plans, implements and documents self-hosted open-source identity and access platforms inside the client's own infrastructure, so that access enforcement can be shown to an assessor. DeployOpen prepares systems and evidence for AC-3 but does not issue audit reports or certifications; independent assessors do that work.

How we scope

Agree in writing which systems, applications and data stores fall under AC-3 enforcement before any work starts.
Record which access control models apply, such as role-based or attribute-based, and which AC-3 enhancements the client has chosen to address.
Confirm the baseline selected for the system, since AC-3 applies to the low, moderate and high baselines in SP 800-53B.

How we build

Configure the identity provider and directory connections so that applications delegate sign-in and authorization decisions to a single source.
Connect role and attribute assignments to provisioning rules so that enforcement follows the approved authorizations on record.
Harden enforcement points on each in-scope application and confirm that denied requests are logged for later review.

How we hand over

Deliver configuration records, role and attribute mappings, and test results that map each enforcement mechanism to the AC-3 assessment procedure.
Document the list of approved authorizations and the audit records an assessor would examine, with the location where each is kept.
Provide a walkthrough so the client's administrators and assessment staff can reproduce the enforcement tests independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
Review enforcement configuration when applications, roles or directory connections change, and update the evidence set to match.
Confirm with the client's assessor which artifacts they expect for AC-3 before the assessment begins, so gaps are closed early.

AC-3 Access enforcement