AC-3(3): Mandatory Access Control

The ac-3(3): mandatory access control requirement is an “execution” control: auditors and authorizing officials will look for enforcement in real systems, not only a policy statement. If you claim MAC, you must show (1) the MAC policy exists, (2) the policy defines covered subjects and objects, and (3) technical controls consistently enforce the rules so users cannot bypass them through discretionary sharing or ad hoc permissions.

For many organizations, the practical challenge is scoping and proof. MAC can apply narrowly (for a high-sensitivity enclave, regulated dataset, or mission system) or more broadly (for an enterprise platform handling federal data). Either way, your work is to translate “policy” into concrete enforcement points: operating system MAC (SELinux/AppArmor), database label security, cloud IAM conditions tied to resource tags, or application-layer authorization that reads classification labels from a trusted source. The second challenge is governance: labels must be defined, assigned, changed, and retired under change control, or your “mandatory” system becomes inconsistent quickly.

This page gives requirement-level guidance you can hand to engineering and security operations to implement, evidence, and defend AC-3(3) in an audit.

Regulatory text

Excerpt: “Enforce {{ insert: param, ac-3.3_prm_1 }} over the set of covered subjects and objects specified in the policy, and where the policy:” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: You must (a) define a mandatory access control policy, (b) explicitly identify the subjects and objects that the policy covers, and (c) implement technical enforcement so access decisions follow that policy across the covered scope. The “mandatory” part means enforcement is system-driven and centrally governed; it is not left to individual users to decide who can access labeled data. (NIST SP 800-53 Rev. 5)

Plain-English interpretation (what “mandatory” changes)

Mandatory access control (MAC) is access control where:

• Objects (files, records, queues, buckets, repositories, services) carry labels (classification, sensitivity, compartments, projects, mission domains).
• Subjects (users, roles, service accounts, processes, workloads, devices) have authorizations/clearances or attributes.
• Policy rules map subjects to objects (for example, “Secret can read Secret and below,” “Project A can’t read Project B,” “No cross-tenant access,” “Export restricted data requires additional authorization”).
• Users cannot override the rule by granting access at their discretion.

If your environment is mostly discretionary access control (DAC) today (shared drives, ad hoc ACL edits, owners granting permissions), AC-3(3) is a material change. Treat it as a scoped program with clear boundaries and enforcement points.

Who it applies to

AC-3(3) is relevant when you are expected to align to NIST SP 800-53, including:

• Federal information systems and the teams operating them.
• Federal contractors and service organizations handling federal data in hosted or managed environments. (NIST SP 800-53 Rev. 5)

Operational contexts where AC-3(3) shows up

You are most likely to need MAC when:

• You host multi-tenant or multi-mission data where “need-to-know” constraints apply.
• You maintain segregations that must not be bypassed by data owners (for example, export-controlled datasets, regulated research data, case management records, investigative data).
• Your authorization boundary claims label-based separation or compartmentalization.

What you actually need to do (step-by-step)

Use this as a build checklist that results in testable enforcement and audit-ready artifacts.

1) Write a MAC policy that engineers can implement

Minimum policy content:

• MAC model (label-based, compartmental, lattice, tag/attribute-based with mandatory rules).
• Covered subjects: human users, admin roles, service accounts, CI/CD identities, batch jobs, endpoint processes.
• Covered objects: datasets, repositories, storage locations, database tables, message topics, application resources, logs.
• Decision rules: allowed operations (read/write/execute/admin), label dominance rules, compartment rules, cross-domain sharing rules.
• Authority: who defines labels, who can approve label changes, and who approves exceptions.

Deliverable: a version-controlled policy document mapped to enforcement points. (NIST SP 800-53 Rev. 5)

2) Define your label taxonomy and governance

Create a label standard that is stable and unambiguous:

• Label categories (example patterns): sensitivity/classification, compartment, program, tenant, region, data type.
• Allowed values and meanings.
• Label assignment rules (default labels, inheritance, required labels).
• Label lifecycle: creation, modification, deprecation, and emergency relabeling.

Governance must include:

• A single accountable owner (often security architecture with data governance).
• Change control for label schema changes.
• Periodic label quality checks (missing labels, conflicting labels, drift).

3) Choose enforcement points that cannot be bypassed

MAC only works if enforcement is in the path of access. Common enforcement designs:

• OS/container MAC: SELinux/AppArmor policies for workloads that must enforce process-to-object constraints.
• Database label security: row-level security or label security features if your “object” is a record set.
• Cloud controls: IAM conditions tied to resource tags/attributes, plus service control policies and guardrails where appropriate.
• Application-layer authorization: a centralized policy decision point (PDP) reads subject attributes and object labels from trusted sources; the policy enforcement point (PEP) blocks unauthorized actions.

Pick the minimum set that covers your defined scope. Document why each enforcement point is in-scope and how it enforces the policy.

4) Bind identity attributes to policy decisions

If subjects are not reliably identified, MAC collapses into exceptions.

• Define authoritative identity sources for humans and non-humans.
• Standardize required subject attributes (role, org, clearance/authorization, tenant, device posture if used).
• Prevent attribute spoofing: attributes used in authorization must come from trusted directories/identity providers, not user-provided claims.

5) Implement “mandatory” guardrails (prevent discretionary overrides)

Design out the common bypass paths:

• Restrict who can change labels on objects.
• Restrict who can modify policy rules.
• Separate duties: policy authorship, policy approval, policy deployment.
• Log and alert on label changes and policy changes.

6) Test enforcement with defined scenarios and retain results

Build a small but explicit set of test cases:

• Positive tests: allowed subject/object interactions.
• Negative tests: denied access attempts.
• Boundary tests: cross-compartment attempts, privilege escalation attempts, break-glass scenarios.

Record the test evidence in a repeatable way (scripts, test accounts, screenshots/log extracts).

7) Operationalize exceptions without breaking the model

MAC programs fail when exceptions are informal.

• Define exception criteria (business justification, compensating controls, expiration).
• Require documented approval by the policy owner (and system owner if separate).
• Time-box exceptions and review them.
• Capture technical implementation of the exception (temporary rule, scoped role, controlled sharing mechanism).

8) Run control health checks

At a minimum, check:

• Label coverage: are all in-scope objects labeled?
• Policy drift: are there manual permission grants that bypass MAC?
• Change review: were label/policy changes approved and deployed correctly?
• Access outcomes: are deny logs reviewed and tuned for false positives without weakening controls?

This aligns with the expectation that you can show sustained operation, not a one-time build. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Keep an “AC-3(3) evidence bundle” that an auditor can follow end-to-end:

1. Requirement control card (runbook)

• Objective, owner, system scope, enforcement points, cadence, triggers, exception rules. (NIST SP 800-53 Rev. 5)

2. MAC policy and scope statement

• Covered subjects/objects, label schema, decision rules, and enforcement mapping. (NIST SP 800-53 Rev. 5 OSCAL JSON)

3. Label standard + governance records

• Data dictionary for labels, approval workflow, change tickets/PRs.

4. Configuration evidence

• Policy-as-code repos, IAM condition policies, OS MAC policy files, database RLS policies, application authorization configs.
• Deployment records (change requests, approvals, CI/CD logs).

5. Access test evidence

• Test plan, test accounts, test execution outputs, deny/allow logs.

6. Exception register

• Requests, approvals, compensating controls, expiration dates, closure evidence.

7. Ongoing monitoring outputs

• Periodic reports: label completeness, policy drift findings, remediation tickets to closure.

A practical tip: store this bundle in a single GRC record with stable pointers to source systems (Git, ticketing, SIEM) so you can reproduce evidence without collecting it from scratch each audit cycle.

Common exam/audit questions and hangups

Auditors and customer assessors tend to press on:

• Scope clarity: “Which subjects and objects are covered, and why those?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Mandatory vs discretionary: “Can a data owner share access outside of policy?”
• Bypass paths: “Can admins or developers bypass the control through backdoors, direct DB access, or debug tooling?”
• Label governance: “Who can create or change labels, and how is it reviewed?”
• Evidence of enforcement: “Show me a denied access event that demonstrates the rule works.”
• Change control: “How do you prevent unauthorized policy edits? Who approves?”

Prepare short, direct responses and keep “show me” evidence ready.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only MAC

• Mistake: a document says “we use MAC,” but systems are DAC with ACLs.
• Avoid: enumerate enforcement points and demonstrate deny logs tied to labels.

2. Unscoped subject/object population

• Mistake: “all systems” language, but no inventory of covered objects.
• Avoid: maintain an inventory view listing in-scope repositories, buckets, databases, and services.

3. Labels that are not authoritative

• Mistake: labels live in spreadsheets or user-entered fields.
• Avoid: labels must be system-enforced attributes stored in authoritative services with controlled write permissions.

4. Exceptions become the real policy

• Mistake: break-glass accounts and permanent overrides proliferate.
• Avoid: time-bound exceptions with compensating controls and periodic review; remove or redesign patterns that require frequent exceptions.

5. No drift detection

• Mistake: a good initial deployment, then ad hoc permissions accumulate.
• Avoid: scheduled checks for manual grants, policy changes, and label gaps with tracked remediation.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite specific regulator actions.

From a risk standpoint, weak MAC implementation increases the likelihood of:

• Unauthorized cross-domain access (mission/tenant separation failure).
• Over-permissioning via discretionary shares.
• Audit findings where you cannot prove consistent enforcement across defined scope.

For systems handling federal data, failure to implement stated controls often becomes an authorization and contractual risk because assessors expect operational evidence aligned to NIST SP 800-53 control intent. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

Numeric timelines are guidance for execution planning, not a claim about required duration.

First 30 days (define and scope)

• Assign a single control owner and name engineering counterparts for each enforcement point.
• Draft the MAC policy: covered subjects/objects, label taxonomy, decision rules, exceptions workflow. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Select initial in-scope systems and document boundaries (what is included and excluded).
• Create the AC-3(3) control card and minimum evidence bundle checklist. (NIST SP 800-53 Rev. 5)

Days 31–60 (implement enforcement + governance)

• Implement label storage and governance workflow (change approvals, restricted write access).
• Configure enforcement points for at least one end-to-end path (identity → policy decision → enforcement → logging).
• Build test scenarios and run initial allow/deny validation; store results as evidence.
• Stand up exception register and approval routing; run at least one tabletop for a break-glass event.

Days 61–90 (prove operation and harden)

• Expand coverage to additional objects/systems within scope.
• Add drift checks: detect manual permission grants, label gaps, and policy changes.
• Tune logging and alerting for unauthorized attempts and policy changes.
• Run a control health check and track remediation items to validated closure. (NIST SP 800-53 Rev. 5)

Where Daydream fits naturally: Many teams struggle with “show me the evidence” and “who owns this control.” Daydream can hold the AC-3(3) control card, maintain the evidence bundle pointers, and track recurring health checks and remediation to closure so audits do not turn into evidence scavenger hunts.

Frequently Asked Questions

What qualifies as “mandatory” access control for AC-3(3)?

Access decisions must be driven by centrally managed policy rules using labels/attributes, not by individual users granting access at their discretion. You should be able to show that unauthorized requests are consistently denied based on the policy. (NIST SP 800-53 Rev. 5)

Do we need SELinux or a specific MAC technology to meet AC-3(3)?

NIST SP 800-53 does not mandate a specific product in the provided excerpt. You need an enforcement mechanism that achieves mandatory, label-driven decisions across your defined subjects and objects. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we define “covered subjects and objects” without scoping too broadly?

Start with the systems and data types where label-based separation is required, then document the inventory of identities and resources that are in-scope. Auditors mainly want clarity and consistency: your policy must match your implementation. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle break-glass access in a MAC environment?

Treat break-glass as a formal exception path with tight eligibility, explicit approval, strong logging, and rapid revocation. Keep an exception register entry that links the approval to the technical configuration and post-incident review.

What evidence is most persuasive in audits for AC-3(3)?

Configuration artifacts (policy code/config), a clear scope statement, and test results that show both allowed and denied outcomes tied to labels. Pair that with change control records for label and policy updates. (NIST SP 800-53 Rev. 5)

Our application has “roles.” Is that MAC?

Roles alone are usually discretionary or RBAC unless the roles and access rules are bound to centrally governed labels/attributes and cannot be overridden by resource owners. If owners can freely share resources outside policy, you likely do not meet the “mandatory” intent.