User Access Management Across CMMC, FedRAMP Rev5, and FedRAMP 20x

The core concept

User access management is the full lifecycle of an account or permission: request, approval, provisioning, periodic review, and revocation. Every framework audits this lifecycle. What varies is the cadence, the approvers, the authentication requirements, and the deprovisioning triggers.

The operational pattern is universal. Someone needs access. Someone approves it. The system provisions it. On a defined cadence, someone reviews whether the access is still appropriate. When the person leaves, changes roles, or no longer needs the access, it gets revoked with a timestamp and evidence.

Granting access is the easy part. Every organization can do that. The hard part is proving the rest of the lifecycle: that you reviewed access on schedule, that you revoked it when you should have, and that the approval chain is traceable. That is where assessments fail.

graph LR
    REQ[Request] --> APR[Approval]
    APR --> PROV[Provisioning]
    PROV --> REV[Periodic Review]
    REV -->|confirm| PROV
    REV -->|revoke| DEPROV[Deprovisioning]
    HR[HR/IdP Event] --> DEPROV
 
    style REQ fill:#2b5797,stroke:#5b9bd5,color:#fff
    style APR fill:#1a5c3d,stroke:#51cf66,color:#fff
    style PROV fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style REV fill:#5c4a1a,stroke:#ffc857,color:#fff
    style DEPROV fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style HR fill:#4a1a5c,stroke:#c77dff,color:#fff

What CMMC requires

Access Control is the largest CMMC domain. It is also where CUI environments fail assessments most often. The practices cover everything from basic access restrictions to privileged account management, separation of duties, and multi-factor authentication.

The relevant practices:

• AC.L1-3.1.1 (Level 1): Limit system access to authorized users, processes acting on behalf of authorized users, and devices. 5-point, not POA&M-eligible. This is the core practice: you control who and what gets access.
• AC.L1-3.1.2 (Level 1): Limit system access to the types of transactions and functions that authorized users are permitted to execute. 5-point, not POA&M-eligible. This is function-level access control, not just system-level.
• AC.L2-3.1.5 (Level 2): Employ the principle of least privilege, including for specific security functions and privileged accounts. 3-point, not POA&M-eligible. Least privilege applies to all accounts, with extra scrutiny on privileged ones.

Supporting practices add depth to the assessment:

• AC.L2-3.1.4: Separation of duties. Different people for different functions.
• AC.L2-3.1.6: Use non-privileged accounts for non-privileged functions. Do not log into production with an admin account to check email.
• AC.L2-3.1.7: Prevent non-privileged users from executing privileged functions. Log and audit when it happens.
• IA.L2-3.5.3: Multi-factor authentication for access to CUI.

What a C3PAO assessor looks for:

• A documented access request and approval process, with evidence for real users, not a template that was never used
• Least privilege on privileged accounts, with business justification for elevated access
• Access reviews on a regular cadence, with confirm-or-revoke decisions captured
• Timely deprovisioning when people change roles or leave
• A privileged account inventory with justification for each account
• MFA enforcement evidence

The common gap: organizations can show they granted access, but cannot prove the full lifecycle. Accounts accumulate privileges over time with no cleanup. Quarterly privileged access reviews exist in the plan but not in practice. Deprovisioning happens eventually, but the timestamps are scattered across three systems.

The scoring is significant. Two L1 practices in this set are 5-point and not POA&M-eligible. AC.L2-3.1.5 (Least Privilege) is 3-point and not POA&M-eligible. You cannot defer any of them at assessment. If you cannot demonstrate the lifecycle end-to-end, those points are lost with no remediation path during the assessment window.

What FedRAMP Rev5 requires

FedRAMP spells out the access review cadences. Miss them and you pick up findings that compound every cycle.

The relevant controls:

• AC-2 (Account Management): the full account management control. Approval workflows, role-based provisioning, lifecycle tracking, disable inactive accounts, terminate sessions on logout, and review accounts per the defined cadences.
• AC-6 (Least Privilege): authorize only the access necessary for users to accomplish assigned tasks.
• AC-6(7) (Review of User Privileges): review user privileges on a defined cadence to validate that they remain necessary and appropriate.

Key FedRAMP cadences (the ones most often missed):

• Privileged access reviews: quarterly
• Non-privileged access reviews: annually
• Termination or transfer notification: within 8 hours
• Account no longer needed: within 24 hours

Those four cadences drive most of the access management findings in FedRAMP assessments. The quarterly privileged review is one of the most commonly cited gaps. Organizations know they need to do it. They plan to do it. They miss it because it is tracked in a spreadsheet that nobody opens until assessment prep.

The 8-hour termination notification and 24-hour deprovisioning windows are tight. When someone leaves the organization or changes roles, the clock starts immediately. If you learn about it on Friday afternoon and the deprovisioning happens Monday morning, you have already missed the 24-hour window. If the notification to the security team happens Tuesday, you have missed the 8-hour window by days.

What 3PAOs look for: evidence of reviews on cadence, not just initial provisioning. Approval for every grant. Deprovisioning records tied to personnel actions, with timestamps that clear the 8-hour and 24-hour windows. This is not a matter of intent. It is a matter of evidence with timestamps.

Multi-tenant environments add complexity. Access management has to account for tenant isolation, customer administrator access, and consumer-specific review processes.

Common gap: the cadenced reviews. Quarterly privileged account reviews are one of the most commonly cited findings in FedRAMP assessments. The spreadsheet with the review dates exists, but the actual decisions (confirm or revoke for each account) are not captured anywhere auditable.

What FedRAMP 20x requires

FedRAMP 20x sets a higher bar for identity than Rev5. The difference is not incremental. It is structural. 20x expects phishing-resistant authentication, just-in-time access, automated account lifecycle management, and automated response to suspicious activity.

The relevant KSIs:

• KSI-IAM-01 (Phishing-Resistant MFA): enforce phishing-resistant multi-factor authentication. Machine-based validations check for console users without MFA and flag virtual MFA (TOTP) as insufficient because it is vulnerable to phishing. FIDO2, WebAuthn hardware tokens, smart cards, and platform authenticators clear the bar. SMS codes and TOTP apps do not.
• KSI-IAM-02 (Passwordless Authentication): move toward passwordless authentication methods. Machine-based validations check password policy settings and age, but the direction is clear: passwords are a transitional mechanism.
• KSI-IAM-03 (Non-User Accounts): manage non-user accounts (service accounts, machine identities) with the same rigor as human accounts. Machine-based validations check for IAM roles without condition constraints, long-lived access keys (over 90 days), unused instance profiles, and instances without managed identities. Long-lived credentials for service accounts are a 20x anti-pattern.
• KSI-IAM-04 (Just-in-Time Authorization): implement just-in-time, least-privileged, role or attribute-based authorization for all accounts. Standing privileged access is discouraged. Access exists only when needed, then reverts.
• KSI-IAM-05 (Least Privilege): persistently ensure each user and device accesses only what is needed. Machine-based validations check for wildcard IAM policies, inactive users with active credentials, and accounts with AdministratorAccess. Non-machine validations review the roles and responsibilities matrix for accuracy and separation of duties.
• KSI-IAM-06 (Suspicious Activity): auto-disable or lock down privileged accounts on suspicious activity. Machine-based validations check that detection services are enabled and that IAM-related alerting is active and actionable.
• KSI-IAM-07 (Automated Account Management): manage the lifecycle and privileges of all accounts with automation. Machine-based validations check that identity stores are configured for automated provisioning, that stale users (90+ days inactive) are flagged, and that access keys are rotated. Manual provisioning scripts do not satisfy this KSI.

Our own validation data makes the gap concrete. KSI-IAM-01 is Partially Satisfied because moving every account to phishing-resistant MFA in a production environment takes time, especially when legacy applications or integrations only support TOTP. KSI-IAM-07 is Not Satisfied because full automated account lifecycle management, from provisioning through deprovisioning with no manual steps, requires deep integration between the identity provider, HR systems, and the cloud platform. These are not checkbox items. They require architectural changes.

The common gap on the path to 20x: standing privileged access that never expires, manual provisioning workflows, no JIT capability, legacy MFA methods that do not resist phishing, and service accounts with long-lived credentials that are never rotated.

The pain we lived

User access management was one of the earliest pain points we hit at scale.

Granting access was never the problem. Someone needed access to a system, they asked for it, someone approved it, and it was provisioned. That part worked. The pain was everything after.

Quarterly privileged access reviews were tracked in spreadsheets. Someone would export the list of privileged accounts from the identity provider, paste it into a spreadsheet, and send it to the reviewers. The reviewers were supposed to mark each account as “confirm” or “revoke.” Some reviewers responded promptly. Some did not respond at all. The spreadsheet was chased over email for weeks. By the time all the responses were collected, it was nearly time for the next quarter’s review.

The evidence was weak. A spreadsheet with names and checkmarks, plus a chain of emails. An assessor would ask: “Show me the approval for this specific privileged account.” We would dig through the email thread, find the message where the reviewer said “looks good,” and present that as the approval. There was no timestamp on the decision tied to the specific account. There was no structured record of what was reviewed, by whom, and what action was taken.

Deprovisioning was worse. When someone left the organization, the HR notification went to the manager. The manager was supposed to notify the security team. The security team was supposed to deprovision the accounts. Sometimes this happened within hours. Sometimes it took days. The 8-hour notification window and 24-hour deprovisioning window required by FedRAMP were missed more often than they were met. Not because anyone was negligent, but because the process depended on a chain of manual notifications across three teams.

Access approval evidence was scattered. The approval for a specific access grant lived in an email thread, a Slack message, or a verbal conversation. Reconstructing the approval chain for a specific user’s access to a specific system required archaeology. An assessor would ask: “Show me the approval for this person’s access to this system, the date it was provisioned, the most recent review, and the justification.” That is four data points across four different systems, if the data exists at all.

Privilege creep was a quieter problem but just as damaging. Users accumulated permissions over time as they moved between projects. Nobody removed the old access when new access was granted. A developer who started on one project and moved to three others over two years still had access to all four. Least privilege on paper, privilege accumulation in practice.

Across 15+ environments, these gaps multiplied. Each environment had its own identity provider, its own access review cadence, and its own way of tracking approvals. There was no single view of access across environments. There was no way to answer basic questions quickly: “How many privileged accounts exist across all environments? When was the last review? Are any overdue?” The questions were simple. The answers required hours of manual data collection.

How we automate it

We built user access management in Stratus GRC-ITSM to make the full lifecycle auditable by default. Proving access management to any framework becomes a reporting exercise, not a data collection project.

1. Self-service access request portal. Users request access with required fields: system, role, business justification, and requested duration. Free text alone does not clear intake. The structured data at the point of request is what makes everything downstream work.
2. Automated approval routing. Standard access goes to the user’s manager. Privileged access goes to manager plus security. The approver chain is defined once per system and role level, not per request. When people change roles, the routing updates in one place.
3. Single-click approvals on the ticket. The approver reviews the request and clicks approve or deny. The decision, the approver’s identity, and the timestamp are captured on the ticket. No email threads to chase. No verbal approvals to reconstruct later.
4. Provisioning integration. Approved requests trigger provisioning through the identity provider. Denied requests are logged with a reason. No tickets get lost between approval and provisioning.
5. Time-bound access. Privileged grants have expiration dates. When a grant expires, a renewal or revocation review fires automatically. This supports the JIT posture that KSI-IAM-04 expects for 20x. Access does not persist indefinitely by default.
6. Recurring access review tasks. The platform creates review tasks on cadence: quarterly for privileged accounts per AC-6(7) and AC-2, annually for non-privileged, configurable for CMMC. Each task carries the current access list and cannot be closed without a confirm-or-revoke action per user. There is no “mark all as reviewed” shortcut. Each account gets an explicit decision.
7. Deprovisioning triggers. HR and identity provider events (termination, role change) fire access review workflows immediately and start the Rev5 8-hour notification and 24-hour deprovisioning clocks. No waiting for the next scheduled review. No relying on a manager to remember to notify the security team.
8. Full audit trail. Every access decision (request, approval, provisioning, review, revocation) lives on one record. When an assessor asks to see the lifecycle for a specific account, every step is on a single timeline with timestamps, actors, and decisions.

graph TD
    REQ[Access Request] --> APR[Approval Record]
    REQ --> PROV[Provisioning Event]
    PROV --> REC[Recurring Review Task]
    REC -->|confirm| PROV
    REC -->|revoke| DEP[Deprovisioning Record]
    HR[HR / IdP Event] --> DEP
    APR --> AUDIT[Full Audit Trail]
    PROV --> AUDIT
    REC --> AUDIT
    DEP --> AUDIT
 
    style REQ fill:#2b5797,stroke:#5b9bd5,color:#fff
    style APR fill:#1a5c3d,stroke:#51cf66,color:#fff
    style PROV fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style REC fill:#5c4a1a,stroke:#ffc857,color:#fff
    style DEP fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style HR fill:#4a1a5c,stroke:#c77dff,color:#fff
    style AUDIT fill:#1a3d1a,stroke:#a9dc76,color:#fff

The principle: the failure mode is not doing any single step of the access lifecycle. Organizations know how to grant access. The failure mode is proving the full lifecycle. Recurring review tasks that force explicit decisions, HR-triggered deprovisioning with automatic clocks, and one record per access decision solve the problem for CMMC assessors, FedRAMP 3PAOs, and 20x KSI validators at the same time.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]