CMMC Level 2 — Independent Research

CMMC Privileged Access Management: 8 Requirements, 24 Objectives, and the Evidence Assessors Actually Check

By The Defense Compliance Report Editorial Team · Published July 2026 · Last reviewed: July 2026 · Last verified: July 10, 2026 · Methodology · Editorial & Advertising Policy

CMMC privileged access management is not a product requirement — no CMMC rule or Level 2 security requirement tells you to buy PAM software. But 8 Level 2 security requirements in NIST SP 800-171 Revision 2, tested through 24 assessment objectives and carrying up to 14 points under the CMMC scoring methodology in 32 CFR § 170.24, demand privileged-access outcomes. Two of them — least privilege (AC.L2-3.1.5) and multifactor authentication (IA.L2-3.5.3) — cannot be placed on a Plan of Action and Milestones (POA&M) at all. Every other six can sit on a Conditional Level 2 POA&M only when the score is at least 88 and every condition in 32 CFR § 170.21 is met — not automatically.

That last sentence is the one most contractors learn during their assessment. Below, we map every requirement, its point value, whether it can be deferred, what an assessor will put in front of you, and the distinction — separate accounts versus controlled role elevation — that can spare small teams the most unnecessary tooling.

One qualifier before anything else: this page covers Level 2 (CUI). If you handle Federal Contract Information (FCI) only, Level 1 carries the 15 basic safeguards of FAR 52.204-21 and none of the requirements below — start with our Level 1 self-assessment walkthrough instead. And your solicitation or contract sets the required CMMC Status — not a checklist, and not a vendor.

The Defense Compliance Report is the independent trade publication and decision resource for CMMC and Defense Industrial Base compliance — explaining the CMMC Final Rule with primary-source citation on every claim and mapping a contractor’s level, CUI scope, assessment type, and timeline to the right provider category, so DIB contractors choose the right CMMC path before they spend six figures.

The bottom line, on one screen

↓ Jump straight to the requirement matrix and gap check

Editorial note: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We are not affiliated with the Cyber AB, the Department of Defense, DCMA DIBCAC, NIST, or any U.S. government agency. Provider-matching forms may generate referral compensation, disclosed at the point of recommendation. This page is educational research, not legal, contractual, or compliance advice — confirm scope and applicability with a CMMC Registered Practitioner (RP/RPO) or a qualified federal-contracts attorney before making compliance decisions.

Which CMMC requirements apply to privileged access management?

Eight CMMC Level 2 security requirements in NIST SP 800-171 Revision 2 explicitly govern privileged access: AC.L2-3.1.5 (Least Privilege), 3.1.6 (Non-Privileged Account Use), 3.1.7 (Privileged Functions), 3.1.15 (Privileged Remote Access), AU.L2-3.3.9 (Audit Management), IA.L2-3.5.3 (Multifactor Authentication), 3.5.4 (Replay-Resistant Authentication), and SC.L2-3.13.3 (Role Separation). Together they contain 24 assessment objectives and carry up to 14 points under the CMMC scoring methodology.

Here’s the thing the vendor pages never tell you: “privileged access management” appears nowhere in 32 CFR Part 170, the CMMC Program Rule that took effect December 16, 2024. It’s industry shorthand. The actual obligations come from NIST SP 800-171 Rev. 2 — which Level 2 adopts wholesale, all 110 security requirements across 14 control families. So we did what shorthand can’t: we went requirement by requirement through Rev. 2 and the DoD CMMC Assessment Guide – Level 2, version 2.13, and pulled every requirement whose published text expressly addresses privileged accounts, privileged users, privileged functions, non-privileged account or role use, security functions, audit-logging management, or the separation of user from system-management functionality.

Quick definition: a privileged accountis one authorized to perform security-relevant or system-management functions ordinary users cannot — creating accounts, changing security settings, administering logs, patching systems, managing keys.

On scoring:the CMMC point values below come from the CMMC scoring methodology in 32 CFR § 170.24. That is notthe same thing as the NIST SP 800-171 DoD Assessment summary score you post under DFARS 252.204-7019 and -7020 — a separate, older regime.

The CMMC Privileged Access Control Matrix — 8 core requirements

Requirement text and objectives: NIST SP 800-171 Rev. 2 and CMMC Assessment Guide v2.13. Point values: 32 CFR § 170.24. POA&M eligibility: 32 CFR § 170.21. Verified July 10, 2026.

* One-point requirements may sit on a Conditional Level 2 POA&M only if the overall score is at least 88 and every other condition in 32 CFR § 170.21 is met. Details in the next section.

Requirement text and official titles per NIST SP 800-171 Rev. 2 and the Level 2 Assessment Guide v2.13; point values per 32 CFR § 170.24; POA&M eligibility per 32 CFR § 170.21.

Seven supporting requirements you can’t ignore

Privileged access doesn’t stop at the eight. Seven more Level 2 requirements reference privileged accounts or administrative activity in their assessment objectives or official discussion — and five of them are heavyweights:

Add it up and our 15-requirement dependency set carries up to 43 points of CMMC Level 2 score exposure— 14 directly, 29 more on requirements whose objectives include privileged accounts. Satisfying the eight does not automatically satisfy the seven; it just means the seven will be a lot easier.

What we actually verified

On July 10, 2026, The Defense Compliance Report Editorial Team cross-checked: requirement text and official titles against NIST SP 800-171 Rev. 2 and the DoD CMMC Assessment Guide – Level 2, v2.13; point values against 32 CFR § 170.24; POA&M eligibility against 32 CFR § 170.21; C3PAO assessment procedures against 32 CFR §§ 170.17 and 170.8; and scoping treatment against 32 CFR § 170.19 and the DoD CMMC Level 2 Scoping Guide. The 8-requirement grouping, 24-objective count, and 14-point total are our editorial calculations from those sources.

Which privileged access requirements can never go on a POA&M?

Under 32 CFR § 170.21(a)(2), a Level 2 Plan of Action and Milestones (POA&M) may only contain security requirements worth 1 point — so Least Privilege (AC.L2-3.1.5, 3 points) and Multifactor Authentication (IA.L2-3.5.3, up to 5 points) must be MET in the final assessment result. Six core one-point requirements — 3.1.6, 3.1.7, 3.1.15, 3.3.9, 3.5.4, and 3.13.3 — may be placed on a Conditional Level 2 POA&M, but only if the overall score is at least 88 and every other § 170.21 condition is met.

This is the section that changes project plans, so let’s be precise. To walk out of a Level 2 assessment with Conditional CMMC Status— a temporary contract-eligibility status available only when the § 170.21 conditions are met, with every POA&M item closed within 180 days — all three of these must be true:

1. Your score divided by 110 is at least 0.8.That’s 88 points, minimum.
2. Nothing on the POA&M is worth more than 1 point.One narrow exception exists, and it isn’t yours: SC.L2-3.13.11 (CUI Encryption) can ride a POA&M at 3 points if encryption is deployed but not FIPS-validated. That carve-out does not extend to 3.5.3.
3. None of six specifically named requirements appears on the POA&M(AC.L2-3.1.20, AC.L2-3.1.22, CA.L2-3.12.4, PE.L2-3.10.3, PE.L2-3.10.4, PE.L2-3.10.5). None of the eight core privileged-access requirements is on that exclusion list — small mercy.

A word on the MFA scoring:the 3-point condition in § 170.24 applies to one specific scenario — MFA implemented for remote users and privileged users, but not yet for the general non-privileged network population. A VPN-only setup that leaves local privileged access without MFA makes IA.L2-3.5.3 NOT MET but does not match that stated partial condition. What matters for your planning is simpler: any 3.5.3 deduction is greater than one point, so the requirement cannot remain on a Conditional Level 2 POA&M in either scenario.

Two procedural facts sharpen the picture. First, in a C3PAO assessment, § 170.17(c)(2) permits a NOT MET requirement to be re-evaluated during the assessment and for 10 business days after the active assessment period — but only if additional evidence shows it MET, no previously MET requirement is affected, and the findings report hasn’t been delivered. Ten business days to fix least privilege from scratch is not a plan; it’s a coin flip. Second, if you do earn Conditional status, every POA&M item must be remediated and confirmed by a POA&M closeout assessment within 180 days of the Conditional CMMC Status Date, or the status expires.

The fix order this dictates

Dependency-based recommendation only — not an order prescribed by § 170.21.

1. IA.L2-3.5.3 first. MFA for privileged accounts, local andnetwork — the console in the server room, not just the VPN. Up to five points, cannot remain on the POA&M, and one of the most common surprises in gap assessments.
2. AC.L2-3.1.5 second.Build the privileged-account and security-function inventories and tie every authorized access to a documented business need. Three points, cannot remain on the POA&M, and it’s the foundation the other seven requirements stand on.
3. The supporting requirements that also can’t ride the POA&M— AC.L2-3.1.1, AC.L2-3.1.2, AU.L2-3.3.1, AU.L2-3.3.2, CM.L2-3.4.5, and MA.L2-3.7.5.
4. The seven potentially POA&M-eligible one-pointers last— the six core one-pointers plus AC.L2-3.1.4. They can remain on a Conditional POA&M only with an overall score of at least 88 and every other § 170.21 condition met.

Two of eight core requirements. Eight of the set’s fourteen points. Zero deferral. That’s the risk profile in one line.

Does CMMC require a PAM tool?

No. No CMMC requirement mandates purchasing a privileged access management platform. 32 CFR Part 170 assesses outcomes against NIST SP 800-171 Rev. 2 requirements and objectives — and all eight core requirements can be implemented with built-in controls, a dedicated PAM platform, or a combination. The assessment result depends on implementation and evidence, not on which product you own.

For a small shop with one or two admins and a stable environment, buying a PAM platform can add cost and assessment surface without closing a single objective faster than the tooling you already own. The assessment methodology puts the principle plainly: it is “not an assessment of one solution compared to another.” Vendor feature maps show where a product may supporta requirement; they don’t determine your finding. Supporting a requirement and satisfying its objectives are different things, and only one of them is for sale.

What the rule actually demands is harder than a purchase: a maintained privileged-account inventory. Separate admin context your team will grumble about. MFA at the physical console, not just the login portal. Logs that capture privileged functions you first had to sit down and define. A tool can automate the evidence — it cannot make the decisions, and an assessor is grading the decisions.

There’s also a category of things no platform can prove by itself: that your CUI boundary is drawn correctly, that every security function got identified, that each privilege reflects a current business need, that staff follow the process outside the tool, and that your System Security Plan (SSP) matches reality. “We have PAM” is not an answer to any of the 24 objectives.

When a dedicated platform — or managed help — genuinely earns its cost

If several of these describe you, the calculus flips, and it flips honestly:

• Multiple administrators, or admin planes spread across AD, a cloud tenant, Linux hosts, and network gear
• Shared or vendor-held admin credentials that still exist somewhere
• A growing estate of service accounts, automation identities, and API keys nobody fully inventoried
• An MSP or MSSP performing remote administration in your environment
• Evidence prep that has become a recurring manual archaeology project, or a Level 2 C3PAO date on the calendar

In those environments, a vaulting/just-in-time platform, or a CMMC-focused Registered Provider Organization (RPO) or MSSP running the identity stack for you, stops being a luxury. Our provider category breakdown maps what each one actually does.

You now know whether a tool is even the question.The next step is knowing which gaps are yours — if you skipped the Gap Checker above, run it now; it takes two minutes and flags the requirements that can’t ride a POA&M.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

What counts as a privileged account under CMMC?

A privileged account or role is one authorized to perform security-relevant or system-management functions that ordinary users cannot — creating accounts, changing security configurations, administering audit logs, patching systems, or managing cryptographic keys. Access to CUI alone does not make an identity privileged; the deciding question is authority over administrative and security functions, per the definitions used in the DoD Level 2 Assessment Guide.

The most common question: “our engineers open CUI drawings all day — are they all privileged users now?” Read-write access to CUI alone does not make an identity privileged. Classify the identity by whether it can perform security-relevant or system-management functions — and remember the same engineer may still be privileged through a separate role or permission set they also hold. Classify by function, not by file access.

A defensible privileged-account inventory — the literal first objective of AC.L2-3.1.5 — has to cover more than the two people with “IT” in their title:

Three edge cases deserve their own sentences. Service accountsare privileged when their permissions say so, regardless of the fact that no human logs in interactively — AC.L2-3.1.5 requires identifying them and authorizing least privilege; assigning an accountable owner, disabling interactive logon where it isn’t needed, and monitoring use are our operational recommendations for making that identification survive an assessment. Break-glass accountsare permitted in practice but exempted by nothing: if the account permits local or network access to privileged authority, IA.L2-3.5.3 applies, and an assessor cannot waive it — the only path around a security requirement is an alternative measure adjudicated by the DoD CIO as equally effective and documented in your SSP. MSP technicianswhose assigned access can execute privileged or security-management functions in your environment belong in your privileged-user analysis — and most administering MSPs have exactly that access. Provider staff without it aren’t privileged merely because of their employer.

Do admins need two separate accounts — or can PIM, JIT, and sudo satisfy CMMC?

CMMC requires that nonsecurity work occur through non-privileged accounts or roles (AC.L2-3.1.6); it does not universally prescribe two permanent usernames. Separate named admin accounts are the simplest design to defend. Controlled role elevation — Entra PIM, AWS role assumption, sudo, Just Enough Administration — can also be defensible when the base state is non-privileged and activation is authenticated, attributable, and logged.

Read the requirement text closely: “use non-privileged accounts or roleswhen accessing nonsecurity functions.” Those two words — or roles— are the most expensive words on this page, because they’re the difference between mandating a second username for every technology and permitting a well-instrumented elevation model. The Assessment Guide states outright that a role change can provide the same degree of assurance as switching between privileged and non-privileged accounts.

“Defensible” in this table is our editorial architecture judgment based on the cited objectives — not an assessor pre-approval or a guaranteed finding.

Per-elevation approval workflows and time limits are our implementation bar for a clean elevation story, not words in AC.L2-3.1.6. The regulatory test is that nonsecurity work happens in a non-privileged account or role and that the applicable authorization, authentication, and audit objectives hold.

Can developers keep local admin rights?There’s no developer exception written anywhere in Rev. 2 — the organization must authorize the privilege against a business need, prevent unauthorized privileged functions, and keep ordinary work separated. Permanent broad local admin “because builds” is hard to defend; task-scoped, time-limited, logged elevation is much easier. Does CMMC require dedicated admin workstations?No Level 2 requirement names a privileged access workstation (PAW). It’s a strong architecture — one we recommend where the stakes justify it — for proving SC.L2-3.13.3 separation, not a mandate.

And yes: your admins will grumble about the second account or the elevation prompt for the rest of their careers. The assessor will not care. Budget the goodwill accordingly.

What will assessors actually check for privileged access?

Level 2 assessments verify security requirements through examine, interview, and test methods drawn from NIST SP 800-171A — assessors select the combination of methods and objects needed to reach confidence on each applicable objective. For privileged access, be prepared to produce the account inventory, demonstrate representative privileged access paths with MFA, and trace a privileged action from identity to protected audit record.

The requirements bar is identical whether your contract calls for a Level 2 self-assessment or a Certified Third-Party Assessment Organization (C3PAO): the 110 security requirements, their 320 assessment objectives, the scoping rules, and the CMMC scoring methodology don’t change. The process does. A C3PAO certification assessment is reported through the CMMC instantiation of eMASS to SPRS, permits the narrow 10-business-day re-evaluation described above, and carries an artifact-integrity procedure: under § 170.17(c)(4), you hash your evidence artifacts with a NIST-approved algorithm, give the C3PAO the artifact names, hash values, and algorithm for eMASS upload, and retain those hashed artifacts for six years from the CMMC Status Date. Under a self-assessment, your results and affirmation go into SPRS directly — and the affirmation is a formal representation to the government, required at each assessment and annually thereafter per § 170.22.

The evidence pack: 10 items, build it now

1. Privileged-identity inventory— every human, service, automation, vendor, MSP, and emergency identity, per 3.1.5[a] and 3.5.3[a]
2. Security-function and privileged-command catalog— the inventory against which 3.1.7’s prevention-and-logging and 3.1.15’s remote-command authorization are assessed
3. Authorization records— who approved each privilege, when, and against what business need (3.1.5)
4. Account architecture— the standard-vs-admin mapping, or the elevation model and its configuration (3.1.6)
5. MFA coverage map plus a demonstration path— every local, network, remote, and emergency route (3.5.3)
6. Authentication-protocol posture— legacy, replay-vulnerable protocols disabled or controlled (3.5.4)
7. Log samples capturing a privileged function— and the trace from named identity → elevation → action → protected record (3.1.7[d], with 3.3.1/3.3.2)
8. Remote-administration authorizations— the written list covering your own admins and every vendor with a path in (3.1.15)
9. Audit-administration roster— the defined subset who can manage logging, and proof nobody else can (3.3.9)
10. SSP sections and Customer Responsibility Matrix (CRM)— describing all of the above in final form, with provider-operated controls mapped explicitly

An illustrative test sequence: an assessor asks a non-privileged user to attempt a privileged function and watches it fail. Asks an admin to elevate and watches the authentication and the log entry land. Pulls a sampled privileged account and asks who approved it. On local MFA, the evidentiary question is whether representative privileged paths authenticate with two distinct factor categories — the screen doesn’t need to show two sequential prompts when the mechanism is inherently multifactor. What never changes: drafts, roadmaps, and undeployed features do not establish implementation. An objective is MET only when final evidence demonstrates the requirement is implemented and operating.

Does a cloud PAM tool need FedRAMP — and how does it enter your CMMC scope?

A PAM asset that provides security functions or capabilities to your CMMC Assessment Scope is a Security Protection Asset (SPA) under 32 CFR § 170.19 — in scope and assessed against the Level 2 requirements relevant to what it does. When an external provider delivers the service, the analysis turns on what the service actually handles: a Cloud Service Provider (CSP) processing CUI triggers the FedRAMP Moderate-or-equivalent condition; one processing only Security Protection Data (SPD) stays in scope as an SPA without that condition.

A PAM platform can solve a control problem and create a scoping problem at the same time. Credentials, configurations, and logs are Security Protection Data when they’re used to protect the assessed environment. Classify the actual data and function, not the field name or the vendor’s label.

What else does DFARS 252.204-7012 require from a cloud provider handling CUI?

FedRAMP equivalence is not the whole obligation. For an external CSP that stores, processes, or transmits covered defense information, DFARS 252.204-7012(b)(2)(ii)(D) also requires the CSP to comply with paragraphs (c) through (g): cyber-incident reporting, malicious-software submission, 90-day media preservation, access for forensic analysis, and damage-assessment support. Ask a prospective provider how they satisfy those five before you sign — a marketing page that says “FedRAMP equivalent” answers one question of six.

Three practical consequences: First, the relevant PAM asset is itself assessedagainst the Level 2 requirements applicable to the capabilities it provides — the vault that fixes 3.5.3 must have controlled access, protected logs, and a place in your SSP. A tool can reduce effort and add scope simultaneously; plan for both. Second, session recording is a data-classification decision— record an admin working inside a CUI file share and the recording may be CUI, which quietly moves a commercial SaaS up the table. Third, the same logic covers your MSP: when their service protects or administers your enclave, it’s in your scope, their privileged-capable technicians enter your analysis, and the CRM dividing responsibility between you is an assessment artifact, not a courtesy.

What’s the right privileged access setup for your environment?

The governing Level 2 requirements don’t change with your stack; which objectives apply and which mechanisms prove them do. Find your row. Platform capabilities below were last checked July 2026; they’re implementation examples that can support the mapped objectives — not DoD-approved architectures, and none is automatically MET.

How do you implement CMMC privileged access management?

Start with the contract requirement and the CMMC Assessment Scope, not a software purchase. Inventory privileged identities and security functions, authorize least privilege, separate ordinary from administrative use, cover every applicable authentication and remote-access path, protect attributable logs, document provider responsibilities, and test each applicable objective with final evidence.

The full sequence, in the order the dependencies actually run:

1. Confirm the requirement. Pull the solicitation or contract language: which CMMC Status, self-assessment or C3PAO. Everything downstream keys off this.
2. Define the assessment scope.CUI systems and flows, Security Protection Assets, ESPs and CSPs — including your PAM, identity, logging, and remote-support services.
3. Inventory security and system-management functions. Account administration, security-policy changes, audit configuration, backup and restore, patching, key management, tenant administration.
4. Inventory every identity that can reach those functions. Humans, service accounts, automation, MSP and vendor personnel, emergency accounts, API credentials. Use the nine-column census above.
5. Authorize least privilege. Each privilege gets an owner, a purpose, an approver, and a review trigger (3.1.5).
6. Separate ordinary work from privileged execution.Separate accounts or a controlled elevation model — pick one, document it, enforce it (3.1.6, 3.13.3).
7. Secure the authentication paths. MFA for local and network privileged access and network non-privileged access (3.5.3); replay-resistant network authentication with legacy protocols shut off (3.5.4).
8. Authorize remote and provider administration.Written authorizations for people, commands, and paths — yours and your vendors’ (3.1.15).
9. Log privileged functions and lock the log room. Capture execution attributably (3.1.7, with 3.3.1/3.3.2); restrict audit administration to a defined subset (3.3.9).
10. Document and rehearse.Update the SSP, asset inventory, network diagram, and CRM; then walk each applicable objective the way an assessor would, and fix what contradicts itself. Final, dated evidence — not intentions.

Most teams can self-serve steps 1 through 4 in a week of focused work. Steps 5 through 10 are where scale, provider access, and evidence volume decide whether you finish in-house or bring in help.

Which provider category solves what’s left?

Use an RPO/RP for scoping and control design, an MSSP or CMMC-focused MSP for implementation and ongoing operation, a GRC platform for evidence workflow, and a C3PAO only for the formal certification assessment. Under 32 CFR § 170.8(b)(17)(ii)(G), the CMMC Code of Professional Conduct prohibits ecosystem members from participating in a Level 2 certification assessment for an organization they served as a consultant to prepare for any CMMC assessment within the preceding three years.

Don’t route a readiness problem to a C3PAO expecting them to fix and then certify the same environment. The three-year rule exists precisely so the certificate means something.

FAQ: CMMC privileged access management

Is privileged access management required for CMMC?

The outcomes are, the product isn't. Eight Level 2 security requirements in NIST SP 800-171 Rev. 2 demand privileged-access controls and evidence; no requirement names PAM software.

Does CMMC require a PAM tool?

No. The requirements can be implemented with built-in controls, a dedicated platform, or a combination — the assessment result depends on implementation and evidence, not the product. Whether a platform is worth it in your environment is a scale-and-discipline question.

Which CMMC requirements apply to privileged access management?

Core: AC.L2-3.1.5, 3.1.6, 3.1.7, 3.1.15; AU.L2-3.3.9; IA.L2-3.5.3, 3.5.4; SC.L2-3.13.3. Supporting: AC.L2-3.1.1, 3.1.2, 3.1.4; AU.L2-3.3.1, 3.3.2; CM.L2-3.4.5; MA.L2-3.7.5.

Is MFA required for privileged accounts?

Yes — for both local and network access, under IA.L2-3.5.3. That includes the console logon in the server room. Full implementation detail in our CMMC MFA requirements guide.

Can least privilege (3.1.5) or MFA (3.5.3) go on a POA&M?

No. 32 CFR § 170.21 limits Level 2 POA&Ms to 1-point requirements; 3.1.5 is worth 3 and 3.5.3 up to 5. The lone 3-point exception applies to SC.L2-3.13.11 (CUI Encryption) only. Both must be MET in the final assessment result.

Is the CMMC 110-point score the same as the SPRS NIST score?

No. CMMC Level 2 uses the scoring methodology in 32 CFR § 170.24; DFARS 252.204-7019 and -7020 govern the separate NIST SP 800-171 DoD Assessment summary score. Under CMMC, self-assessment results and affirmations go into SPRS, while C3PAO results are submitted through the CMMC eMASS instance.

Do administrators need two accounts?

Ordinary work must happen in a non-privileged account or role (AC.L2-3.1.6). Separate accounts are the clearest design; PIM/JIT/sudo elevation is defensible when the base state is non-privileged and activation is authenticated, attributable, and logged.

Is PIM the same as PAM?

No. Privileged Identity Management typically governs role activation; PAM as a category adds vaulting, session control, secrets, and remote-access governance. Assessors evaluate outcomes, not which acronym you bought.

Is Windows LAPS enough for CMMC?

No. LAPS or an equivalent supports local administrator credential management, but it doesn't by itself satisfy privileged-account identification and authorization, use separation, MFA, remote-command authorization, privileged-function logging, or audit-management segregation.

Are service accounts privileged?

When their permissions can perform administrative or security-relevant functions, yes — regardless of the 'service' label. Identify them and authorize least privilege per 3.1.5; assigning owners and restricting interactive logon are our recommendations for making that stick.

Can shared administrator accounts ever be used?

A shared credential alone cannot provide the individual accountability AU.L2-3.3.2 tests for. A design can be defensible only when a separate mechanism — a uniquely authenticated checkout, broker, or session-control layer — identifies, authorizes, and logs each person's use. Otherwise, eliminate the shared path.

Can developers keep local administrator rights?

No rule grants a developer exception. Standing broad local admin is hard to defend under 3.1.5 and 3.1.7; task-scoped, time-limited, logged elevation is far easier. Document the business need either way.

Are break-glass accounts allowed?

Nothing prohibits them, and nothing exempts them. If the account permits privileged access, IA.L2-3.5.3 applies — an assessor cannot waive it, and only a DoD CIO-adjudicated alternative security measure documented in the SSP changes the requirement. Defensible practice: defined purpose, tightly controlled credentials, alerting on every use, post-use review.

Does a cloud PAM platform need FedRAMP?

Only if it processes, stores, or transmits CUI — then the FedRAMP Moderate-or-equivalent condition applies, along with DFARS 252.204-7012's paragraphs (c) through (g). A service handling only Security Protection Data is in scope as a Security Protection Asset without the FedRAMP branch, per the DoD Level 2 Scoping Guide.

Is session recording mandatory?

No requirement names full session recording as a mandated feature. What 3.1.7 mandates is capturing privileged-function execution in audit logs. Recording can strengthen attribution — and can also capture CUI, which changes the scoping analysis.

How often must privileged access be reviewed?

These requirements don't prescribe a universal quarterly interval. Define a defensible organizational frequency plus event-driven triggers — role changes, terminations, emergency use, material system changes — then follow the process and retain the records.

What does PAM cost for CMMC?

There’s no defensible universal price. Cost moves with privileged identities, endpoints, platforms, service accounts, integrations, and operations. Compare three-year total cost only after scope is known — and use our Level 2 cost breakdown for whole-program budgeting.

Does NIST SP 800-171 Rev. 3 change this page?

Not yet. NIST withdrew Rev. 2 and published Rev. 3 on May 14, 2024, but 32 CFR Part 170 incorporates Rev. 2 for CMMC Level 2 — and that stands unless DoD changes the governing rule or contractual requirements. We monitor the Federal Register and DoD CMMC updates and revise this page when the controlling rule changes.

Does CMMC Level 1 require privileged access management?

Level 1 (FCI only) carries the 15 basic safeguards of FAR 52.204-21 — basic access limits, none of the eight requirements above, and no POA&Ms at all. Use our Level 1 walkthrough instead of applying this page’s matrix.

How we built the privileged access matrix

We treated privileged access as an implementation-and-evidence problem, not an official CMMC domain. A requirement entered the core set only when its NIST SP 800-171 Rev. 2 text expressly addresses privileged accounts, users, functions, or commands, non-privileged account or role use, security functions, audit-logging management, or user/system-management separation; requirements whose assessment objectives or official discussion reference privileged access were classed as supporting.

Sources and versions, checked July 10, 2026: NIST SP 800-171 Rev. 2 (requirement text); the DoD CMMC Assessment Guide – Level 2, v2.13 (official titles, objectives, methods, discussion); 32 CFR § 170.24 (CMMC point values) and § 170.21 (POA&M eligibility); 32 CFR §§ 170.8 and 170.17 (ecosystem conduct and certification-assessment procedures); and 32 CFR § 170.19, the DoD CMMC Level 2 Scoping Guide, and the DoD “Technical Application of CMMC Requirements” (scope, SPA/SPD/ESP treatment). Corrections: see our Editorial & Advertising Policy. No provider compensation influenced the matrix.

This page is educational research from The Defense Compliance Report, an independent trade publication on CMMC 2.0 and DIB compliance — not legal, contractual, or compliance advice. Your solicitation or contract and your actual FCI/CUI handling determine your required CMMC Status and assessment path. Confirm scope and applicability with a CMMC Registered Practitioner (RP/RPO) or a qualified federal-contracts attorney before making compliance decisions. Phase 1 of CMMC implementation runs November 10, 2025 through November 9, 2026 and focuses primarily on Level 1 and Level 2 self-assessments; Phase 2 begins November 10, 2026 and generally expands Level 2 C3PAO requirements in applicable solicitations.