AC.L2-3.1.1[e]

AC.L2-3.1.1[e] — Authorized Access Control (System Access Is Limited to Processes Acting on Behalf of Authorized Users)

Domain: Access Control (AC) | Practice: AC.L2-3.1.1 | Objective ID: 3.1.1[e] | Source: NIST SP 800-171 Rev. 2 / CMMC 2.0 Level 2

Assessment Objective:

System access is limited to processes acting on behalf of authorized users.

Executive Summary (For Leadership and the Board)

Objective [e] is the technical-enforcement counterpart to [b]. Where [b] requires you to identify processes acting on behalf of users, [e] requires the systems themselves to refuse access from any process that is not validated and tied to an authorized user. In modern environments this is the difference between “we have a list of service accounts” and “the CUI system actually rejects connection attempts from anything not on that list.”

For executives, the strategic question is: Are we treating service accounts and pipelines as first-class principals with policy enforcement, or are they second-class citizens with shared secrets and implicit trust? The latter is the supply-chain attack pattern (SolarWinds, Codecov, npm, GitHub Actions) and an AC.L2-3.1.1[e] failure.

Business Question	What Leadership Must Confirm
Do CUI systems actually refuse calls from unknown processes / NPEs?	Allowlists / mTLS / SPIFFE / signed-identity tokens are enforced at the CUI boundary.
Are short-lived credentials used for processes?	OIDC federation / workload identity / instance roles replace static long-lived secrets.
Are we logging process-level identity?	Every CUI access is attributable to a specific NPE and the human owner behind it.
Do we test enforcement?	Red-team / pen-test exercises specifically target NPE pathways.

Executive Risk Lens: Process-level trust is where modern attackers live. The CI/CD pipeline, the integration user, the OAuth grant — these are the choke points. AC.L2-3.1.1[e] is your last line of defense between an attacker who has captured a process credential and the CUI itself.

How Authorization Should Flow

From request to authoritative record

Technical Deep Dive (For Engineers, IAM Admins, and ISSOs)

What the Objective Requires

Objective [e] maps to NIST SP 800-53 AC-3, AC-6 (Least Privilege), IA-9 (Service Identification & Authentication), and the NIST SP 800-207 Zero Trust Architecture. Practical implementation patterns: workload identity (Entra Managed Identity, AWS IAM Roles for Service Accounts, GCP Workload Identity), short-lived OIDC-issued credentials, mTLS with SPIFFE/SPIRE, and policy-as-code at the CUI service mesh.

Every CUI-adjacent service authenticates the calling process and refuses unknown identities.
Static long-lived credentials are eliminated wherever workload identity, instance roles, or OIDC federation can replace them.
Pipelines (GitHub Actions, GitLab, Jenkins) authenticate to cloud providers via OIDC — no static keys.
Service mesh (Istio, Linkerd, Consul) or API-gateway policy enforces mTLS and identity-based authorization at every CUI hop.
Logs attribute every CUI action to a process identity AND the human owner.
Allowlists at the network and application layer block unknown caller identities.
Process / workload identities are recertified quarterly (alignment with [b]).

Evidence Package a C3PAO Will Request

Artifact	Where It Typically Lives	Common Gotchas
Workload-Identity Inventory	Cloud IAM, K8s ServiceAccounts, OIDC federations	Static access keys still in use; pipelines using long-lived PATs.
Service-Mesh / API-Gateway Policy	Istio AuthorizationPolicy, gateway configs	“Allow all” default; no per-service identity check.
Pipeline OIDC Configuration	GitHub Actions, GitLab, Azure DevOps	Long-lived AWS access keys / service-principal secrets in repo secrets.
CUI Service Authorization Logs	SIEM correlation rules	Cannot tell which pipeline / NPE made a given CUI request.
Quarterly NPE Recertification	IGA campaign	Pipeline tokens with no expiry; integration users no one owns.

Reference Architecture — Authoritative Source

Real-World Examples — What Goes Wrong

Example 1 — The Codecov-Style Token Exfiltration

A contractor pipeline exfiltrated AWS access keys when a popular CI dependency was tampered with. Because keys were long-lived, attackers used them for 60 days before discovery. CUI build artifacts in S3 were exfiltrated. Had the pipeline used OIDC federation with 15-minute tokens, the blast radius would have been minutes, not months.

Lesson: OIDC workload federation is the difference between a contained incident and a reportable CUI breach. AC.L2-3.1.1[e] is met by short-lived, identity-bound credentials.

Example 2 — SPN Abuse for Lateral Movement

After initial foothold via a phishing email, an adversary requested a Kerberos ticket for a SQL Service Principal Name (SPN), cracked the offline hash, and used the service account to write to the engineering CUI database. The CUI database had no allowlist of which application servers were authorized to call it; any account with the password could read and write.

Lesson: CUI services must allowlist their callers by identity, not just by network reachability. Service-mesh authorization or per-service authentication policy stops this dead.

A vendor app received Files.ReadWrite.All tenant-wide admin consent in 2022. When the vendor was breached in 2024, attackers used the app’s refresh token to enumerate and download CUI documents from SharePoint. No conditional access applied to OAuth apps. No anomaly detection.

Lesson: OAuth apps are processes acting on behalf of users. They must be inventoried, scoped to least privilege, conditionally accessed, and recertified.

How Northern Data Solutions Helps You Pass AC.L2-3.1.1[e]

Service Offering	What It Does for AC.L2-3.1.1[e]
Cyberwatch — Risk Identification	Third-party penetration testing, validation, and vulnerability identification surfaces gaps related to AC.L2-3.1.1[e] before a C3PAO does. Independent attestation that controls match reality.
Cyberwatch Advanced	Operationalizes the controls: Identity & Access Management with adaptive MFA (CyberSecureID), Principle of Least Privilege, Zero Trust Architecture, attack-surface visibility, password management & rotation, and the cybersecurity training platform that produces signed employee attestations — the evidence assessors actually want.
Compliance-as-a-Service	Manages your SSP, POA&Ms, control evidence, and recertification campaigns inside one platform. Maps every artifact to the specific NIST 800-171 / CMMC objective — including AC.L2-3.1.1[e] — so you walk into your assessment with the binder pre-built.
vCSO (Virtual CSO)	Executive-level guidance for boards and leadership on identity strategy, scope decisions (CUI boundary), C3PAO selection, and remediation prioritization across CMMC, FTC Safeguards, and PCI.

Engagement model: Most clients begin with a Cyberwatch baseline assessment (1–2 weeks), then move into Cyberwatch Advanced and Compliance-as-a-Service to remediate and harvest evidence ahead of their CMMC Joint Surveillance or full L2 assessment.

External References & Authoritative Sources

Are You Ready for the Assessor? — 10-Point Readiness Check

Static long-lived credentials have been replaced with workload identity / OIDC wherever possible.
Every CUI service requires authenticated callers and rejects unknown identities.
Service-mesh or API-gateway policy enforces mTLS / identity-based authz on CUI traffic.
Pipelines authenticate to cloud and CUI services via OIDC, not static secrets.
OAuth grants are inventoried, scoped, conditionally accessed, and recertified.
Logs attribute CUI actions to NPE identity AND human owner.
Service-principal / SPN passwords are managed, rotated, and have lockout protections.
Quarterly recertification of NPE access is run.
A red-team exercise has tested NPE pathways within the last 12 months.
A Cyberwatch supply-chain / CI-CD assessment has been completed within the last 12 months.

Next Step: If your CUI services trust their network instead of their callers, you have an AC.L2-3.1.1[e] gap. Engage your Northern Data Solutions vCSO for a Cyberwatch Zero Trust workload-identity assessment.

Tags: AC.L2-3.1.1[e], cmmc

Documentation Index