AC.L2-3.1.5 Least privilege: requirements and evidence

What AC.L2-3.1.5 least privilege requires for a CMMC Level 2 system

If your CMMC Level 2 assessment is coming and the system holding CUI has picked up administrator rights over the years, AC.L2-3.1.5 is the requirement that will expose it. The requirement asks you to employ the principle of least privilege for users and processes, with specific attention to privileged accounts and security functions. It is a 3-point requirement, so it must be MET to reach Conditional or Final Level 2 status, and it cannot be carried on a plan of action and milestones (POA&M). This is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.5, and assessors will test it against the assessment objectives in NIST SP 800-171A.

Privilege accumulation is the usual cause of a failed result. Staff who move between roles keep the rights of every previous role, a helpdesk group ends up with domain administrator rights because it was added once for a migration, and service accounts are reused by several applications with broad permissions. Shared administrator accounts make it worse, because the organization cannot tie a privileged action to a person. Many organizations also have no written record of who authorized a given privilege, so even correct access cannot be proven. The requirement is hard because none of these problems looks dangerous on its own, and each one has to be found and removed before an assessor looks.

Start with an inventory rather than a redesign. Export the accounts, groups and roles from your directory and from each system that stores CUI, then mark which ones are privileged and which security functions (such as audit configuration, key management or user administration) they can reach. Ask the business owner of each privilege to name the decision that justifies it, and keep that decision in a dated authorization record. Confirm with your assessor or your C3PAO how they expect those records and the periodic review to be presented, since the exact evidence they accept should come from the assessment guidance and the assessor, not from this page.

Which accounts, functions and systems fall under least privilege scope

Least privilege under AC.L2-3.1.5 is only as wide as the scope you draw. The decisions below determine which systems, accounts, security functions and third-party administrators land on your privilege review list, and each one can add or remove a large share of the work.

CUI-bearing systems and their supporting assets

Start with the systems that store, process or transmit CUI, then add the assets that support them: identity providers, directory servers, hypervisors, backup servers, logging collectors and jump hosts. An account with administrative rights over any of these can reach CUI even if it never opens a CUI file. Assessors will ask how you decided the boundary, so document the decision and the reasoning behind it. Confirm the boundary with your system security plan before you build the privilege inventory.

Domain administrators and directory-wide rights

Domain admins, enterprise admins and equivalent directory roles can change authentication, group policy and trust settings for every account. Each membership should be named, justified and reviewed on a fixed schedule. Check nested group membership, since a small group can grant domain-level rights through another group. Keep these accounts out of everyday use, which connects to AC.L2-3.1.6 Non-privileged account use.

Cloud global administrators and tenant roles

Cloud tenants often hand out broad roles such as global administrator, subscription owner or organization admin, sometimes through automation or old project grants. Inventory every role assignment at tenant, subscription and project level, not only the directory roles. Look for guest accounts and service principals holding these roles. Record which roles your CUI environment actually needs, and confirm with your cloud provider how each role is scoped in the environment you assess.

Local administrator rights on endpoints

Local administrator rights on workstations and servers let a user change security settings, disable controls and install software. Count these as privileged even when the user is not a domain admin. Endpoint inventories are often incomplete, and standing local admin rights tend to spread over time. Decide whether each endpoint class needs local admin at all, then check the local administrators group on a sample of systems, not only on the ones you already manage well.

Service accounts and automation identities

Service accounts, API keys, scheduled tasks and CI pipelines often run with more privilege than their job requires, and their owners are frequently unclear. For each one, record the owner, the system it serves, the rights it holds and whether anyone can log on interactively. Service accounts that are members of privileged groups belong on the privileged list. Confirm rotation and ownership with the teams that run the applications.

Security functions and third-party administrators

Audit log management, security configuration, key management and backup restore are security functions that need explicit authorization, separate from general system administration. Third parties with administrative access, such as managed service providers, remote support vendors and integrators, belong in the same review, with their accounts named, time-bound where possible and logged. Ask each provider for a list of its personnel with access, and confirm how that list is kept current in your access review.

How an assessor tests least privilege under NIST SP 800-171A

This table maps the four SP 800-171A assessment objectives for AC.L2-3.1.5 to the evidence an assessor requests, the sampling step that links paperwork to live settings, and the findings that most often cause a NOT MET result. Read each row as a question the assessor will ask and the artifact that answers it. Because 3.1.5 is worth 3 points and cannot go on a POA&M, an unresolved gap here blocks Conditional or Final Level 2 status.

Assessment focus	What the assessor asks for	Where it usually fails
Objective: privileged accounts identified	A current list of privileged accounts, plus active and system-generated accounts for comparison	Admin accounts exist in the directory but are missing from the list, or service accounts are not classified
Objective: security functions identified	A documented list of security functions and security-relevant information that need explicit authorization	The list names functions in general terms, such as 'administration', with no link to specific settings or roles
Objective: system administration personnel identified	A list of system administration personnel tied to their roles and privileged accounts	Contractors or former staff hold administrator rights that the personnel list does not show
Objective: access authorized to each security function	Access authorization records that state who may use each function and why, approved by an accountable owner	Admin rights were granted during an incident or project and never documented or removed
Sampling and tie-back to live configuration	The assessor selects accounts and compares each authorization record with the actual group memberships, roles and permissions in the system	Records say one thing and the directory or host shows another, such as local admin rights on workstations outside the documented model
Account management compliance reviews	Periodic review records showing privileges were confirmed, changed or revoked, with reviewer, date and outcome	Reviews are scheduled but not performed, or they approve everything without evidence of checking the access itself
Evidence in final form	Signed and dated authorization records and review outputs that reflect the current state, not drafts	Policies exist as drafts or the most recent review predates a major staffing or system change

Steps to implement least privilege for privileged accounts and security functions

This sequence turns least privilege from a policy statement into a documented, reviewed set of privileged accounts and security functions that an assessor can trace from the system back to a named authorization. Each step produces an artifact that the next step depends on.

Inventory accounts and privileged roles everywhere
Build a complete list of active, system-generated and privileged accounts across the identity provider, operating systems, cloud tenants, databases, network devices and business applications that hold CUI. Include service accounts, break-glass accounts and shared administrator accounts, because assessors look for them. The output is one inventory with the owning system, account type, privilege level and whether the account is active. This is a one-time baseline that must be refreshed whenever a system or directory changes.
Define security functions needing explicit authorization
List the security functions and security-relevant information that only designated people should touch, such as audit log configuration, account creation and role assignment, firewall rule changes, encryption key management and access to security settings. Name the system component where each function lives. The output is a short register of security functions with the roles allowed to perform them. Review it when new platforms or administrative tools are added.
Remove or narrow excess rights
Compare each account in the inventory against the job it supports, then remove standing administrator rights that are not needed, split broad administrator groups into narrower roles, and restrict which configuration settings each role can change. Record each change with a ticket or change reference and the before and after permissions. The output is a permissions baseline that reflects the business need of each role. Expect this step to recur as roles change, but the first pass is the largest.
Document authorization for each privileged role
For every privileged role and security function, write a short authorization record stating who may hold it, the business reason, the approving owner and the systems it covers. Tie each record to an identity group in the directory so membership, not individual exceptions, controls access. The output is a signed-off authorization register that an assessor can compare against live group memberships. Confirm with the assessor how they expect approvals to be signed in your environment.
Assign a named reviewer and set the review cycle
Name one accountable reviewer for each privileged role and document how often the review occurs and what it checks, such as whether each member still needs the role. Access certification tools can run these reviews, where designated reviewers decide to keep, change or revoke each access item within a set timeframe, which also helps catch access accumulation and segregation of duties conflicts. The output is a review schedule and reviewer assignment list. Set the cycle policy once, then the reviews recur on that schedule.
Run the review and act on the results
On each scheduled cycle, the named reviewer compares current memberships against the authorization register, records a keep, change or revoke decision for every item, and the administrator completes each revocation or change. Unreviewed items are escalated to the reviewer's manager. The output is a signed review record per role with the date, reviewer and actions taken. This step recurs for the life of the system.
Retain evidence in final form
Keep the inventory, security function register, change records, authorization register, review records and directory exports in final, dated form. Assessors do not accept drafts as evidence for least privilege, so store approved versions with clear ownership and retention rules. Ask your assessor or C3PAO which artifacts they expect and how they want them organized before the assessment. The output is an evidence package mapped to the four assessment objectives for AC.L2-3.1.5. This is ongoing, with new versions added at each review.

Why privileges accumulate and how to stop it

Privileges rarely get granted all at once. They build up over time as people change roles, keep group memberships from earlier jobs, and pick up rights through nested groups or inherited roles that nobody reviewed when they were added. Access accumulation is the gap between what a person needs today and what the directory, the application and the cloud tenant actually allow them to do. Assessors testing AC.L2-3.1.5 look for this gap in the account lists and authorization records the organization can produce, so the first task is to find where it has already formed. Pull effective permissions for users who have changed roles, not just their assigned groups, because nested membership and inherited roles often grant more than the group list suggests.

The control that keeps accumulation in check is a recurring review in which a designated reviewer decides, for each access item, whether to keep it, change it or revoke it within a set timeframe. Open-source identity governance tools such as midPoint support this pattern through access certification campaigns, where reviewers work through role assignments and record their decisions. The organization owns the policy: who reviews, how often, what the deadline is and what happens to items nobody answers. Those choices belong in the access control procedure and should be settled before the first campaign runs. Confirm the review cadence and deadline with your own policy and with the assessment objectives in NIST SP 800-171A before you commit to them.

Separation of duties is where least privilege and the neighboring requirement AC.L2-3.1.4 meet. A person who accumulates rights across two conflicting duties can carry out a malicious act alone, even if each individual grant looked reasonable at the time. Reviewers should therefore check combinations of privileges, not only single entitlements, and flag any account that holds both sides of a critical duty. AC.L2-3.1.6, which requires administrators to use non-privileged accounts for everyday work, reduces the number of standing privileged sessions a review has to cover. AC.L2-3.1.7 covers preventing non-privileged users from running privileged functions and logging each execution, so this page stops at deciding who holds privileges and how those decisions are re-checked. Evidence for AC.L2-3.1.7 and the other two requirements is covered on their own pages.

Evidence that passes least privilege review

Assessors test AC.L2-3.1.5 by checking whether privileged accounts and security functions are identified, authorized narrowly and reviewed on a schedule. The cards below cover the records that show each step, and each one needs to be current and in final form when the assessment starts.

Privileged account list

A current inventory of every account with administrative or elevated rights, across operating systems, directories, cloud tenants, databases and applications. Assessors compare this list against exports from the systems themselves, so an account that appears in a directory but not on the list is a finding. Record the owner, the role and the business reason for each privileged account, and confirm that shared or service accounts are listed too.

System-generated account list

An export of accounts the system creates on its own, such as built-in administrator, service, database and default vendor accounts. These are easy to overlook because no person requested them. Show how each one is disabled, renamed or restricted, and where its credentials are stored. Assessors use this list to confirm that the privileged account inventory is complete.

Security function authorization list

A document naming each security function and security-relevant information item, such as firewall rule changes, log configuration, key management and user provisioning, along with the people explicitly authorized to perform it. Keep it separate from general role descriptions so an assessor can match each function to a named authorization. Review it whenever a system or administrative process changes.

Signed access authorization records

Approvals that show a manager or system owner authorized a specific privilege for a specific person, with the date and the scope granted. An approval that says only 'admin access' rarely satisfies the assessor. Each record should name the system, the privilege level and the justification, and it should be signed or recorded in a ticketing workflow that keeps the approver's identity and timestamp.

Dated keep, change or revoke reviews

Periodic review records showing a designated reviewer checked each privileged assignment and decided to keep, change or revoke it. Assessors look for the reviewer, the review date, the population covered and the outcome of each item. Access certification campaigns in tools such as midPoint, which requires reviewers to decide within a set timeframe, produce this kind of record. Confirm the review interval your own policy sets and keep the completed campaigns.

Identity system configuration exports

Exports from directories and identity providers, such as group memberships, role bindings and provider configurations, that show privileges as the system enforces them. Authentik, which delegates sign-in to applications through OAuth2, OpenID Connect, SAML and LDAP, and FreeIPA, which provides single sign-on for Linux and UNIX through a Kerberos KDC, both hold authorization state that can be exported. Dated exports taken before and after each review let an assessor trace a decision to a change.

What meeting least privilege costs in effort and tooling

This table breaks down the effort and tooling costs of meeting AC.L2-3.1.5 by component, showing whether each is one-time or recurring and what makes it grow. Use it to frame a quote request, since no dollar figures or durations are supplied for this requirement and the scope depends on your environment.

Cost component	One-time or recurring	What drives it up	How to keep it down
Privilege inventory and cleanup	One-time, then refreshed at each review	Number of systems, legacy applications with local admin rights, shared administrator accounts, undocumented service accounts	Start with directory and system-generated account lists, retire unused accounts first, and scope the inventory to CUI systems
Security function and privileged account authorization records	One-time build, recurring upkeep	Number of privileged roles, number of security functions needing explicit authorization, frequency of role changes	Use a small set of role templates, tie each authorization to a named business need, and record approvals in one place
Access review tooling or licenses	Recurring license or subscription, where used	User and role counts, number of cloud tenants, need for workflow and reviewer reminders	Compare commercial governance suites with open-source options such as midPoint, which runs access certification campaigns without a license fee; confirm features and support with the vendor
Identity provider and single sign-on	Recurring licensing for commercial products, recurring operations for self-hosted	Number of applications, protocols needed (SAML, LDAP, OIDC), legacy systems that cannot delegate sign-in	Self-hosted options such as authentik and FreeIPA can remove license spend; budget for hosting, patching and backup instead
Recurring access review effort	Recurring, at the review cadence you define	Number of reviewers, access items per review, unclear role ownership, manual spreadsheets	Assign named reviewers per system, use time-boxed campaigns, and remove access that is no longer needed before each cycle
Evidence upkeep	Recurring	Number of systems in the assessment boundary, frequency of privilege changes, evidence stored in multiple places	Export configuration and review records on a fixed schedule into one controlled repository, with final versions only
Assessor sampling time	Recurring at each assessment, scales with scope	Number of accounts and privileged functions sampled, incomplete or draft records, inconsistent naming	Prepare a clear list of privileged accounts and matching authorization records before the assessment so samples can be traced quickly
Implementation partner support	One-time for fixed-scope work, optional retainer for ongoing support	Scope of systems, legacy integrations, number of cloud tenants, internal staff availability	Ask for a written, fixed scope with named deliverables, and confirm which evidence the partner prepares versus what your team must maintain

Who owns the privilege model, who helps and who assesses

The organization owns AC.L2-3.1.5 in full. Leadership and the security function decide which roles may hold privileges, who approves each grant, and how often those grants are reviewed. System owners and administrators must understand their own privileges well enough to justify them when asked. Nothing in the control can be delegated to a partner, because the authorization decisions are the organization's own business decisions.

Authorization decisions: Named owners approve privileged accounts and each security function that needs explicit authorization.
Account and role ownership: An accountable owner keeps the list of administrative and privileged accounts current.
Periodic reviews: Reviewers confirm that each privilege still matches a current business need and remove what does not.
Records of decisions: Approvals, changes and review outcomes are kept in dated, final form.
Staff knowledge: Administrators can explain why they hold each privilege and where it is used.

Confirm with your own assessor which review cadence and record format they expect before the first assessment.

Open-source identity tools that support least privilege evidence

Can midPoint produce evidence that role assignments were reviewed?

Yes, midPoint's access certification campaigns are designed for this. Designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments, which counters access accumulation and supports segregation of duties. The campaign records give an assessor a dated trail of who reviewed what and what they decided, which is the kind of evidence AC.L2-3.1.5 reviews look for. The license is EUPL-1.2+. Confirm with your own environment whether midPoint's role model, connectors and reporting cover the systems that hold CUI, since a campaign is only as complete as the accounts and roles it can see.

How does authentik help show that privileged access is controlled?

authentik acts as an identity provider, so applications delegate sign-in to it instead of keeping their own user stores. It supports OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Centralizing sign-in means group membership and authorization decisions can be shown in one place, which helps demonstrate that access to security functions and privileged accounts is authorized narrowly. Its license is MIT. Confirm which of its provider types your applications actually support, and whether each application enforces the authorization decisions authentik makes rather than trusting the token alone.

What does FreeIPA add for Linux and UNIX least privilege?

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. For least privilege, the value is centralized identity and group control across servers, so administrative access to hosts can be granted through defined groups and reviewed in one directory instead of local accounts on each machine. Its license is GPL-3.0-or-later. Confirm how FreeIPA's host-based access and sudo rules fit your server estate, and whether any systems in scope cannot join the Kerberos realm, because those systems will need separate account evidence.

Do these tools replace the privilege review an assessor will test?

No. None of these tools decides what a role should allow or who is authorized to hold a privileged account. Your organization must identify privileged accounts and security functions, define the authorization for each, and perform the reviews. The tools help by producing records of assignments, approvals and decisions, and by enforcing sign-in centrally. An assessor will still test the policy, the authorization records and whether the review happened on schedule. Final-form evidence is required for a requirement to be MET.

Can we run these identity tools ourselves, and what would we outsource?

Many teams with directory and identity experience run these platforms in-house. The usual split is that your staff own the authorization policy and review decisions, while an implementation partner may plan the deployment, integrate applications, configure campaigns and mappings, harden the servers and document the evidence. DeployOpen implements and supports self-hosted open-source platforms inside your own infrastructure under a written, fixed scope, and it prepares evidence for assessments but does not issue reports or certifications. Ask any partner to show how the scope covers your application inventory and privileged account list.

What drives the cost of an open-source identity deployment?

Cost depends mainly on the number of applications and directories to integrate, the number of privileged roles and reviewers, the state of existing account data, and how much documentation the assessor will expect. Software licenses for these three tools are open source, so the spend is mostly labor, infrastructure and any outside help. Some costs are one-time, such as integration, data cleanup and initial campaign design, while others recur, such as running review cycles, patching and staff time. Request a quote that lists each system, each campaign and the evidence deliverables separately.

Which identity tool should we start with?

The right starting point depends on where your privileged access lives. If role sprawl across business applications is the main problem, start with midPoint campaigns. If applications need central sign-in, start with authentik. If the main gap is administrative access to Linux and UNIX hosts, start with FreeIPA. Many environments use more than one. Before choosing, inventory your privileged accounts, applications and hosts, then confirm each candidate's fit against that inventory in a proof of concept.

Common gaps that fail least privilege

Assessors rarely fail least privilege because a policy is missing. They fail it when the privileged accounts, security functions and approvals that the policy describes cannot be traced to a record. The gaps below recur because they sit where identity, operations and documentation meet, and each one has a closing action that produces evidence an assessor can test.

Shared admin accounts with no owner

A shared administrator login, such as a generic root or domain admin account used by several engineers, leaves no way to tie a privileged action to a person. Under AC.L2-3.1.5 the list of privileged accounts must be complete and each one must be authorized, which a shared account cannot satisfy. Check the directory and every host for accounts that several people use. Closing action: replace each shared account with named administrator accounts, record an owner for any account that must remain, and disable the shared credential.

Service accounts with standing domain rights

Service accounts often receive broad directory rights at setup and keep them for years, long after the application needs them. These accounts appear on the list of active and system-generated accounts that an assessor will request, so each one has to show a narrow, documented purpose. Review group memberships for every service account and compare them with the application's actual calls. Closing action: scope each service account to the specific systems and actions it uses, then record that scope in the account inventory.

Undocumented security function lists

AC.L2-3.1.5 requires that security functions and security-relevant information be identified and that access to them be authorized. Many organizations never write this list down, so administrators hold rights to logging, key management or policy settings without anyone having defined them as security functions. An assessor cannot test authorization against a list that does not exist. Closing action: write a single register of security functions, the roles allowed to perform each one, and the approver for each role, and link it from the system security plan.

Access reviews with no decision record

Periodic access reviews that return a blanket approval, or a signed attestation with no item-level decisions, show that a review happened but not that anyone judged the privileges. Assessors look for evidence that each privileged grant was examined and kept, changed or revoked. Ask reviewers which items they removed in the last cycle. Closing action: require a keep, change or revoke decision for every privileged role assignment, timestamped and attributed to the reviewer, and retain the export as the review record. Tools such as midPoint support this model through access certification campaigns.

Privileges granted outside the identity system

Local administrator rights on a server, database roles created directly in an application, or cloud roles assigned in a console bypass the identity system where reviews and approvals are recorded. These grants then fall outside the population an assessor samples, and the access review never sees them. Compare privilege reports from each system against the directory to find grants that were made by hand. Closing action: route every privileged grant through a group or role in the central identity provider, remove direct assignments, and reconcile local and application-level admin lists against the directory each review cycle.

Least privilege questions buyers ask before hiring help

How much effort does least privilege work take for a CMMC Level 2 environment?

The effort depends mostly on how many systems, accounts and roles the assessed environment contains and how much of its access model is already documented. Expect work in four parts: listing privileged accounts and security functions, mapping each one to the people or processes that need it, removing access that exceeds those needs, and building a recurring review. Organizations with a small, well-documented environment usually have less to untangle than those with years of inherited groups and shared administrator accounts. Ask any provider for a written scope that names the systems in the boundary, the identity sources in use, and the number of roles to be reviewed before accepting a fixed price or schedule.

Can our own team implement least privilege for 3.1.5 without outside help?

Yes, many organizations do this in-house, provided they have people who understand the system's administrative model and can document it. The work is mostly configuration, inventory and record-keeping rather than new technology. The harder part is objectivity: the people who grant privileges are often the same people who depend on them, which makes a clean review difficult. Outside help is commonly used to prepare the inventories, configure identity and directory controls, and run a first access review, then the internal team takes over the recurring cycle. Whichever path you choose, the organization owns the decisions on who receives which privilege.

What does least privilege require from our IT and security staff?

It requires named people who can answer three questions for every privileged account: what the account is for, who approves it, and when it was last reviewed. Typical contributors include system administrators who can explain the actual administrative tasks, a security lead who approves the authorization model, and a business owner for each system who confirms who still needs access. Staff must also be prepared to remove standing privileges they have grown used to, and to accept that some tasks will need a documented, time-limited elevation instead. Plan for these people's time during inventory and review cycles, not only during the initial build.

How long does it take to get 3.1.5 ready for an assessment?

No timeline should be accepted from any provider without a written schedule tied to your scope. The duration depends on the size of the boundary, the state of current access records, how quickly approvers respond, and whether the assessment date is already fixed. Ask for a schedule that shows the inventory phase, the authorization phase, the removal of excess access, the first review cycle, and the evidence collection window, with named owners and dependencies for each. Be cautious of any estimate that is not linked to a documented scope. Note that the current status of CMMC Phase II is under review, so confirm the assessment timing with your contracting officer or the DoW CIO page before planning around a date.

Can an implementation partner issue our least privilege evidence or certify us?

No. An implementation partner can help prepare systems, account inventories, authorization records and review evidence, but it cannot issue assessment reports or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and the organization remains responsible for its own controls and for the accuracy of its affirmations. Keep the roles separate in your contract: the partner delivers configured systems and documented evidence within a written scope, and the assessor independently tests that evidence against the NIST SP 800-171A objectives. Ask any provider to confirm this division in writing.

Can we put AC.L2-3.1.5 on a POA&M if we are not finished?

No. AC.L2-3.1.5 is a 3-point requirement, and under the CMMC scoring methodology a point value above 1 cannot be carried on a plan of action and milestones. It must be fully MET to reach Conditional or Final Level 2 status. This means every applicable assessment objective, including identifying privileged accounts and security functions and authorizing access to each, must be satisfied with evidence in final form before the assessment. Drafts do not count. Build the schedule so that the authorization records and review evidence are complete well before the assessment date, rather than planning to close the gap afterward.

What evidence will an assessor ask for to test least privilege?

Assessors commonly examine several records that together show privileges are identified and authorized narrowly. These include lists of active, system-generated and privileged accounts, the list of security functions that require explicit authorization, the roster of system administration personnel, access authorization records for each privilege, and records of account management reviews. Ask your team to confirm that these records exist, are current, and match what the systems actually show. Inconsistencies between a spreadsheet and the directory are a common source of findings, so reconcile them before the assessor arrives.

How DeployOpen prepares least privilege for a CMMC assessment

DeployOpen prepares the systems, privilege model and evidence behind AC.L2-3.1.5 Least privilege inside your own infrastructure. The organization owns its controls and its assessment outcome, and only an independent C3PAO or the organization's own self-assessment process determines whether the requirement is MET.

How we scope

Agree in writing which systems, accounts and security functions fall inside the least privilege scope.
Inventory privileged accounts, system administrators and security functions with the client's identity owners before any build work.
Confirm with your assessor or CMMC advisor which evidence objects your environment must produce for this requirement.

How we build

Configure role and group structures that restrict each user and process to the machines and information its job requires.
Separate administrative accounts from everyday accounts and document which configuration settings each role may change.
Connect applications to a self-hosted identity provider such as authentik so access decisions are made in one reviewable place.

How we hand over

Deliver the privileged account register, authorization records and role permission documentation in final form.
Document the access certification campaign process, including reviewer assignments, decision timeframes and revocation steps.
Provide the evidence package mapped to the four assessment objectives in NIST SP 800-171A so your team can review it.

How we support

Offer ongoing support and periodic access reviews as a retainer after the engagement closes.
Help your team rerun privilege reviews when roles change, staff leave or new systems join the CUI boundary.
Re-test role permissions and update documentation after platform upgrades, as agreed in the written scope.