What AC.L2-3.1.1 authorized access control asks for
AC.L2-3.1.1 requires a defense contractor to limit access to its CUI system to authorized users, processes acting on behalf of authorized users, and authorized devices, including other systems. Before an assessor looks at anything else, the organization must be able to name who and what is allowed in, and show that the system enforces that list. This is the foundation for the rest of the access control family: if the organization cannot produce a current list of authorized accounts and devices, the more specific access rules that follow have nothing reliable to apply to. The requirement is worth 5 points under the CMMC Scoring Methodology, and it cannot be placed on a POA&M. Because it carries more than 1 point, it must be MET before the organization can reach Conditional or Final Level 2 status. In practice, it is hard for three reasons: accounts are scattered across the directory, cloud email, engineering tools and local systems; accounts for departed or transferred staff linger after the people leave; and device lists, including servers, printers and other systems that connect to the CUI environment, are often undocumented. Each gap alone can fail the requirement.
The Level 1 counterpart is AC.L1-b.1.i, which applies the same 3.1.1 objectives to Federal contract information rather than CUI. The boundary with AC.L2-3.1.2 is important: 3.1.1 decides whether an identity may get in at all, while 3.1.2 decides which transactions and functions that identity may perform once inside. Identity proofing and authenticator strength sit with IA.L2-3.5.1 and its neighbors, so 3.1.1 relies on a vetted identity rather than replacing that control. A practical first step is to reconcile three lists: the identity source of record, the accounts that actually exist on each in-scope system, and the device inventory. Ask the implementation partner or internal team to show how disabled accounts are tied to a named person, and confirm with your assessor which account management records they will request. Your assessor, not the implementation partner, makes the final determination.
Which systems, accounts and devices fall under AC.L2-3.1.1 authorized access control
Scope decides how much of the environment must show authorized access. Start with the systems that hold CUI, then trace every identity source, account type and device that can reach them. The cards below cover the decisions that most often change the effort.
CUI systems and their boundary
Begin with every system that processes, stores or transmits CUI, including servers, workstations, databases, backup targets and collaboration tools. Authorized access must be shown for each of them, so an unlisted system that touches CUI is a finding waiting to happen. Confirm the boundary against your system security plan and data flow diagrams before assessors do.
Identity sources that feed CUI systems
Map every directory and identity store that creates or authenticates the accounts used on the CUI boundary, such as Active Directory, LDAP, cloud identity tenants and local accounts on appliances. An account created in a source outside the boundary can still grant access inside it. Ask who can create or change accounts in each source, and record that owner.
Service and process accounts
Service accounts, scheduled jobs, API tokens and integration accounts are authorized processes under the requirement, not exceptions to it. For each one, record its owner, the system it acts on, the credential type and who can retrieve the secret. Shared or orphaned service accounts are among the most common gaps assessors raise.
Devices allowed to connect
The requirement also covers devices, including other systems, that may connect to the CUI environment. Maintain a list of authorized devices, identified by hardware or certificate identity, and decide how unknown devices are refused. Include laptops, printers, network appliances and any system that links to the boundary.
Third parties with administrative access
Vendors, managed service providers and support engineers who hold administrative access to CUI systems fall inside scope when they can reach those systems. Document each third-party account, its sponsor inside your organization, the approval for its access and its removal date. Confirm contract language that requires the third party to follow your account rules.
Cloud tenants holding CUI
Any cloud tenant, subscription or hosted email environment that stores or processes CUI is in scope, even when the provider runs the infrastructure. Confirm which tenant administrators can grant access to CUI data and whether the provider's environment is authorized under your contract. Keep the account list for each tenant separate from on-premises records.
How an assessor tests AC.L2-3.1.1 and what they request
This table walks through the six NIST SP 800-171A assessment objectives for AC.L2-3.1.1, pairing each with the evidence an assessor typically requests and the findings that often cause a NOT MET result. Read it as a checklist for what to have in final form before the assessment starts.
| Assessment step | Evidence an assessor requests | Common findings |
|---|---|---|
| Identify authorized users | Current list of active accounts, each tied to a named person, with account type and owning department | Shared or generic accounts with no accountable owner; accounts that cannot be matched to an employee or contractor |
| Identify authorized processes | Inventory of service accounts and automated processes, with the purpose and owner of each | Service accounts with broad rights and no documented owner; scheduled jobs running under personal credentials |
| Identify authorized devices | Authorized device list for systems allowed to connect, with identifiers and the approving owner | Devices connected to the environment that are missing from the list; undocumented network equipment or personal devices |
| Limit access to authorized users, processes and devices | Access authorization records showing approval before each grant, and samples of account provisioning tickets | Access granted by verbal request with no record; access that outlives the approved business need |
| Review termination and transfer handling | Recently disabled account list with the person tied to each, plus termination and transfer records showing timely removal or change | Orphaned accounts for former staff; transferred employees who keep old access; disabled accounts still in group memberships |
| Test account management compliance and mechanisms | Periodic account management review records, and evidence of how the account management process and its tools operate (for example, directory or provisioning configuration) | Reviews that are scheduled but not performed or not signed; process documents that do not match how accounts are actually created and removed |
How to implement AC.L2-3.1.1 in sequence
This sequence turns AC.L2-3.1.1 from a policy statement into working account records, an authorization model and a device list that an assessor can trace from a sample back to an approved identity. Confirm each step against your own environment, since the systems, identity sources and HR processes will differ from organization to organization.
Inventory systems and identity sources
List every system that holds or processes CUI, including cloud tenants, servers, network devices and applications, and record where each one gets its user accounts today. Note which systems use a central directory, which keep local accounts and which accept accounts from outside the organization. The owner of this step is usually the system owner working with IT, and the output is a system inventory with an identity source named for each system. You know it is done when every in-scope system has one documented source of accounts and any local accounts are listed with a reason for existing.
Define the account standard and authorization model
Write a short account standard that defines the account types the organization recognizes: user accounts for people, process accounts for services and automated jobs, and device identities for machines that connect to the system. For each type, state who may request it, who approves it and what information must be recorded. Pair this with an authorization model that says which accounts may reach which systems and data. The output is an approved account standard and authorization model, and you know it is done when a reviewer can classify any account in the inventory as one of the defined types.
Connect applications to one identity source
Point applications and systems at the identity source chosen in the inventory so that sign-in is delegated rather than handled by separate local passwords. Open-source options such as authentik, FreeIPA and Keycloak can act as the identity provider for applications, or can federate with an existing LDAP or Active Directory server, depending on the environment. Confirm each option's supported protocols and integration method with the vendor before relying on it. The output is a list of applications with their sign-in path recorded, and you know it is done when each in-scope application either delegates to the chosen source or has a documented exception.
Set provisioning and deprovisioning rules tied to HR events
Define how accounts are created, changed and removed when an employee joins, changes role, leaves or is transferred, and tie each event to a named trigger from the HR process. Where the environment supports it, automated provisioning tools such as midPoint can create, update and delete accounts on connected systems from role assignments and user changes, with inbound and outbound rules defined separately. Where automation is not in place, document the manual steps and the person responsible for each one. The output is a provisioning and deprovisioning procedure with its triggers, and you know it is done when a test leaver or mover can be traced through every in-scope system.
Build the authorized device list
Identify every device allowed to connect to the system, including servers, workstations, network devices, and any mobile or wireless equipment in scope, and record each one with an owner and a purpose. Devices that are not on the list should be blocked or flagged by the controls that already exist in the environment. Confirm with the assessor's guidance how device authorization interacts with the separate wireless, remote and mobile requirements. The output is an authorized device list, and you know it is done when every device in the inventory either appears on the list or has a documented removal or exception.
Schedule account reviews and record the results
Set a recurring review of active accounts, recently disabled accounts and device list entries, comparing them with HR records and the authorization model. Record who performed each review, what was found, what was changed and who approved the changes. Keep the review records alongside the lists they examined, since assessors often ask for the records of account management compliance reviews. The output is a dated review record for each cycle, and you know it is done when the most recent review shows that every discrepancy was either corrected or accepted in writing by the owner.
Evidence that passes AC.L2-3.1.1 and how to keep it current
An assessor testing AC.L2-3.1.1 wants to see who is authorized, which processes and devices are authorized, and proof that access is removed when it should be. The cards below cover the records that carry that proof and the routines that keep them accurate between assessments, since a record that was true in the audit window but stale afterward will not hold up.
Account listings with owner mapping
A current export of every active and recently disabled account, with the named person tied to each identity. Assessors use it to check that no account exists without an accountable owner, and that service and shared accounts have a documented owner too. Export it on a fixed schedule from the directory or identity provider, store each export with its date, and reconcile it against HR records. Confirm that every account maps to one person or one owning team.
Disablement and termination tickets
Tickets that show when an account was disabled after a departure, transfer or contract end, who requested the change, and who completed it. Assessors compare these tickets against the account listing to find accounts that stayed active after the person left. Tie each ticket to the HR event that triggered it, and keep the completion timestamp from the system itself, not only the ticket text.
Access approval records
Signed or workflow-approved records that show who authorized each account and each access grant before it was created. An approval should name the requester, the approver, the system, and the date. Keep these records attached to the account identifier so an assessor can follow one account from request to approval to current state. Confirm the approval workflow cannot be bypassed by administrators who create accounts directly.
Periodic account review sign-offs
Dated review records in which an accountable owner confirms that each listed account and its access are still needed. Assign each system or group to a named reviewer, set a review cadence in the account management procedure, and record exceptions with the action taken. A review signed by a shared mailbox or left blank does not show that a person examined the list. Keep the completed sign-off in final form, not a working draft.
Device authorization lists
A maintained list of the devices permitted to connect to the system, with the owner, purpose and authorization date for each. Because AC.L2-3.1.1 extends to authorized devices and other systems, assessors look for this list alongside account records. Generate it from network access control or asset inventory data where possible, and compare it to observed connections on a schedule to catch unlisted hardware.
Account management procedure
The written procedure that governs how accounts are requested, approved, changed, reviewed and removed, including roles and review frequency. Assessors test the process as well as the records, so the procedure must match what the systems actually do. Review it at least once a year, record the revision history, and update it when the identity platform or HR process changes. Confirm the procedure names who owns each step.
Which self-hosted open-source tools support AC.L2-3.1.1 evidence
authentik is an identity provider that applications can delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. For AC.L2-3.1.1, its value is that every application that holds CUI can point to one place that decides who may sign in, so the list of authorized users for those applications is maintained in a single system rather than in each application.
- Application-level user lists: Exported user and group membership from the identity provider can serve as the list of active accounts assessors ask for under the 3.1.1 assessment objectives.
- Disabled and removed accounts: Logs of account deactivation and group removal show that access ends when a person leaves or changes role.
- Provider configuration: Saved configuration of each application's provider shows which applications delegate authentication and which do not.
- Sign-in records: Authentication events show which authorized identities actually reached each application.
- Gaps to close: Applications that keep local accounts outside the provider create authorized identities the tool never sees.
It does not replace your access authorization records, your decision on who should hold an account, or the process for approving and reviewing those accounts. Confirm the license terms for authentik directly with the project before you rely on them in a contract.
FreeIPA provides single sign-on for Linux and UNIX environments, using an MIT Kerberos key distribution center as its authentication core. For AC.L2-3.1.1, it gives administrators one directory of user and host identities for servers and workstations, so the list of accounts allowed to log in to those systems comes from a managed source rather than from individual machines.
- Central user and host lists: Exports of users, groups and enrolled hosts can serve as the authorized user and authorized device lists for Linux and UNIX systems.
- Disabled account records: Account status changes and deletion history show when access to Linux and UNIX systems was removed.
- Kerberos ticket policy: Configured ticket and authentication settings show how identities are verified before access is granted.
- Host enrollment records: Enrollment of a host into the realm is evidence that the device is known to the system.
- Gaps to close: Local accounts on hosts that were never enrolled, and service accounts created outside FreeIPA, must be inventoried and justified separately.
FreeIPA does not decide which people or devices are authorized to hold accounts, and it does not cover Windows endpoints or cloud consoles on its own. Confirm the GPL-3.0-or-later terms and any bundled component licenses with the project before deployment.
Keycloak can connect to an existing LDAP or Active Directory server through user federation and synchronize those users into its own store, so applications sign users in with accounts that are already managed in the corporate directory. For AC.L2-3.1.1, this keeps the corporate directory as the system of record for who is authorized, while Keycloak carries that decision into applications.
- Federation configuration: Saved user storage settings show which directory is the source of accounts and which attributes are synchronized.
- Synchronized user records: Imported accounts and their status show which directory users can sign in to applications.
- Application client records: Client configuration shows which applications accept federated identities.
- Sign-in and admin events: Event logs show authentication activity and administrative changes to federation settings.
- Gaps to close: Accounts that exist only in applications, and directory accounts that sit outside the synchronized scope, need separate review.
Keycloak does not replace the directory's own account management, approval workflow or periodic review of who holds access. Confirm the Apache-2.0 license terms and any extensions you plan to use with the project before you rely on them.
midPoint creates, updates and deletes accounts on connected systems based on user changes and role assignments. It keeps those accounts aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. For AC.L2-3.1.1, it is the tool that shows whether the accounts on each system still match the authorized population, which is the gap that directory and sign-in tools cannot close alone.
- Reconciliation reports: Scheduled comparisons show accounts that exist on a target system without a matching authorized identity, and the actions taken.
- Provisioning history: Records of account creation, change and deletion tie each account to the request or role assignment that produced it.
- Synchronization rules: Documented inbound and outbound rules show how identity data flows between sources and target systems.
- Discovery results: Accounts found on connected systems that were never provisioned can be investigated and resolved.
- Gaps to close: Systems that are not connected to midPoint still need manual account lists and manual review.
midPoint does not decide who should be authorized, and reconciliation results still need a documented owner who reviews and acts on exceptions. Confirm the EUPL-1.2 or later terms, including how they apply to your deployment, with the project before you adopt it.
What meeting AC.L2-3.1.1 costs in money and effort
This table breaks the cost of meeting AC.L2-3.1.1 into components, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a quote request that separates tooling, engineering, evidence upkeep and assessment fees. No dollar figures appear because the sources supplied do not provide them, so ask each party for a written scope and price.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Directory and identity software | Software vendor or none if self-supported open source | Recurring for hosting and support, one-time for setup | Number of identity sources and applications; open-source licenses remove license spend but not hosting or support |
| Application integration | Implementation partner or internal engineers | One-time, with later changes | Count of applications that must delegate sign-in to the central identity provider |
| Provisioning rules and role mapping | Implementation partner or internal engineers | One-time build, recurring tuning | Number of connected systems and how many role changes occur per year |
| Access reviews and account listings | Internal control owners | Recurring | Staff turnover, number of active and disabled accounts, and review frequency the organization sets |
| Evidence collection and retention | Internal compliance staff | Recurring | Need to keep account lists, authorization records and termination records in final form for each assessment |
| Pre-assessment review | Independent consultant (optional) | One-time per cycle | Maturity of current records and whether the consultant also reviews the system security plan |
| Certification assessment fees | C3PAO, paid by the organization | Recurring per assessment cycle | Scope size and number of systems in the assessment boundary, as set by the assessment plan |
| Retainer support and upgrades | Implementation partner | Recurring if contracted | Patch frequency, upgrade scope and how quickly fixes are needed after account changes |
Who owns AC.L2-3.1.1, who prepares it and what an assessor may do
Your organization owns the access decisions behind AC.L2-3.1.1. Someone accountable inside the company must decide who and what may use systems that handle CUI, approve each account, and confirm that the list of authorized users, processes and devices stays current. A partner can build the machinery, but it cannot decide on your behalf who is authorized.
- Authorization decisions: Name the owner who approves each user, service account and device that may access the CUI environment, and keep the approval records.
- Account reviews: Schedule periodic reviews of active and disabled accounts and record who signed off, what changed and why.
- Joiner, mover and leaver steps: Define how staff who join, change roles or leave are added, reassigned or removed, and who is notified when that happens.
- Device and process lists: Maintain the authoritative list of devices allowed to connect and the processes allowed to act for users.
- Policy and scope: Document the access control policy and confirm which systems fall inside the CUI scope.
Before any assessment, check that you can produce the approval, review and termination records on request, in final form, without relying on the partner to reconstruct them.
An implementation partner typically prepares the technical side of AC.L2-3.1.1: identity integrations, provisioning rules, device inventories and evidence exports. The partner works under a written scope and hands the work back to your organization. It does not approve access, decide who is authorized, or certify that the requirement is met.
- Identity integrations: Connect applications to a central identity provider, for example by delegating sign-in from applications to a directory or identity platform.
- Provisioning rules: Configure how accounts are created, updated and removed from role assignments or directory changes, so that approved decisions flow into systems consistently.
- Device list and exports: Build the device inventory and produce account and access reports that show the authorized population.
- Evidence packaging: Organize configuration records, logs and review outputs so your team can present them in final form.
- Documentation: Write runbooks and system documentation that explain how the controls operate.
Confirm in the written scope which of these tasks the partner performs, who holds administrative credentials to the systems, and who owns the evidence after the engagement ends.
The independent assessor tests whether AC.L2-3.1.1 is met. For Level 2 certification, a C3PAO authorized or accredited by The Cyber AB performs that assessment. Under the CMMC rule, the assessor checks the assessment objectives in NIST SP 800-171A against evidence in final form, and it must remain independent of the people who prepared the environment.
- Objective testing: The assessor examines account lists, authorization records, termination records, account management reviews and the list of authorized devices, and may test the account management process and its mechanisms.
- Sampling and walkthroughs: Expect the assessor to pick accounts and devices and trace them back to an approval and a current status.
- Findings: The assessor records MET or NOT MET for each objective and issues findings. Only the assessor's determinations count toward status.
- Independence: A preparation partner should not also serve as the assessor for the same environment, and the assessor should not design the controls it later tests.
- Limits on help: Your team and partner can answer questions and provide access to evidence, but cannot change records to fit the assessment.
Confirm the assessor's authorization status and its conflict-of-interest rules with The Cyber AB before you engage it.
The practical question for AC.L2-3.1.1 is which tasks can be outsourced without compromising the assessment. Preparation work can be delegated, while decisions and testing must stay separate. The boundary is clearest when you map each activity to the party that performs it and the party that signs off.
- Usually outsourced: Identity integration, provisioning configuration, device inventory builds, log and report exports, and documentation drafting.
- Usually kept in-house: Approval of each authorized user, process and device, account review sign-off, termination decisions, and ownership of the policy.
- Shared work: Testing your own configuration before the assessment, which can be done by your team or a partner as long as the partner is not the assessor.
- Independence checks: Ask whether the same firm designed, built and then tested the environment, and avoid overlapping roles.
- Illustrative example: If a partner builds a provisioning rule that grants access by job title, your team must still approve that mapping and record it as an authorization decision.
Before signing any engagement, write down which party signs each access decision and keep that record for the assessor.
Where AC.L2-3.1.1 usually fails and how to close each gap
Most failures against AC.L2-3.1.1 are not missing technology. They are account records, owner assignments and review cycles that exist on paper but cannot be shown to an assessor as final evidence. Each card below names one gap, the action that closes it, and the record that proves it closed.
Departed staff accounts still active
Accounts for people who have left or moved roles remain enabled in directories, applications and cloud tenants long after their last working day. Close this by tying account disablement to the HR termination and transfer workflow, and by reconciling the active account list against the current staff roster. Evidence is a dated list of active and recently disabled accounts, each linked to a named person, plus termination records showing when access was removed. Check that disabled accounts also lose group and role memberships.
Service accounts with no owner
Service and process accounts often have no named owner, no documented purpose and passwords that never rotate. The requirement covers processes acting on behalf of authorized users, so each one must be authorized like a person. Close this by building a register that records the owning team, the system it serves, the permissions granted and the review date for each service account. Evidence is that register, plus the approval record for each account and proof that the owner confirmed it at the last review.
No authorized device list
Assessors look for a defined list of devices allowed to connect to the system, and many organizations can only show a general asset inventory. Close this by defining which device types may connect, then creating a list of specific authorized devices with identifiers, owners and approval dates. Connections from devices that are not on the list should be blocked or alerted. Evidence is the authorized device list itself, the approval workflow behind each entry and a sample showing that an unlisted device was refused or flagged.
Reviews scheduled but not signed
Account reviews appear on a calendar, yet nobody signs the output, so the review cannot be shown to have happened. Close this by assigning each review to a named reviewer, defining what they check (accounts, owners, device entries and group memberships), and recording the decision and any removals. Assessors test account management compliance reviews, so a signed and dated record for each cycle is what they need. Confirm that the review cadence your own policy sets is the cadence you actually follow.
Evidence kept only in drafts
Access authorization procedures, account registers and review records are often left in working drafts or personal folders. Under the CMMC scoring rules, a requirement is MET only when its evidence is in final form, so a draft does not count. Close this by placing each record under document control with an approved version, an approval date and an owner, and by moving the final copies to a repository the assessment scope covers. Check that the evidence matches what the system shows today, not a version from months earlier.
Questions buyers ask about AC.L2-3.1.1 cost, effort and outside help
How much effort does AC.L2-3.1.1 take to meet?
Most of the effort goes into building an accurate inventory of who and what may access the system, then proving that the inventory matches reality. The requirement is worth 5 points under the CMMC scoring method and cannot be placed on a POA&M, so it must be MET before a contractor can reach Conditional or Final Level 2 status. The main drivers are the number of identity sources (directories, cloud tenants, local accounts, service accounts), the number of systems in scope, how well joiner, mover and leaver processes already work, and whether authorized devices are tracked anywhere. An organization with one directory and a disciplined HR feed will need far less work than one with many legacy applications holding their own user lists.
Can our own staff implement AC.L2-3.1.1 without an outside firm?
Yes. The organization owns its controls, so internal staff can implement AC.L2-3.1.1 if they have directory administration skills, a clear account management process and time to collect evidence. Outside help is usually most useful for planning the identity architecture, configuring provisioning and deprovisioning, and preparing evidence packages that an assessor can follow. Internal teams often underestimate how many accounts exist outside the directory, such as local administrator accounts, service accounts and vendor accounts. A short gap review against the six assessment objectives in NIST SP 800-171A will show whether in-house capacity is enough.
What does the work need from our staff day to day?
The work needs named owners more than technical hours. Someone must own the authoritative list of users, usually HR or the identity team, and someone must own the authorized device list, usually IT operations. System owners must confirm which accounts, service identities and processes they actually need. Managers must approve access and review it on a schedule the organization defines. Security staff must check that disabled and terminated accounts are removed and keep records of transfers and terminations. Ask the partner to name each role in writing, so that evidence collection does not depend on one person who may leave.
How long does AC.L2-3.1.1 usually take to complete?
No reliable duration applies to every environment, so treat any single number with caution and ask for a timeline in the written scope. Timing depends on how clean the current directory is, how many systems hold their own accounts, whether provisioning can be automated, and how long reviews take to run through at least one full cycle. Evidence must be in final form, not drafts, so the organization needs time to produce records that show the control working over time. Ask your partner which milestones depend on your staff, such as HR data access or change approvals, because those are often the real schedule drivers.
Do open-source identity tools remove the cost of AC.L2-3.1.1?
Open-source tools usually remove license fees, but they do not remove the cost of implementing and running the control. Projects such as authentik (MIT), FreeIPA (GPL-3.0-or-later), Keycloak (Apache-2.0) and midPoint (EUPL-1.2+) can act as identity providers, central directories, federation hubs or provisioning engines. Remaining costs include hosting in your own infrastructure, design and configuration work, integration with applications, testing, backups, patching and staff time to operate the platform. Check each license with your legal team before deployment, since obligations differ between permissive and copyleft licenses. Ask any quote to separate one-time build costs from recurring operating costs.
What can an implementation partner not do for an assessor?
An implementation partner cannot issue an assessment report, a certificate or an attestation, and it cannot act as the independent assessor for your environment. It can prepare systems, configure identity controls, document procedures and organize evidence so that it is accurate and in final form. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, and the Affirming Official must personally affirm compliance for the organization. Your organization is responsible for the accuracy of its own statements, so the partner should never sign or submit affirmations on its behalf.
What changes for AC.L2-3.1.1 if CMMC Phase II is paused or reviewed?
The requirement itself does not change. AC.L2-3.1.1 still corresponds to NIST SP 800-171 Rev. 2 requirement 3.1.1, and the Department of War said it will enforce Rev. 2 in the interim. On 13 July 2026 the Department suspended Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and began a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. What moves is the timing and type of third-party assessment, so confirm the current status on the DoW CIO About CMMC page before you set a schedule.
How DeployOpen scopes and prepares AC.L2-3.1.1 evidence
DeployOpen works on AC.L2-3.1.1 as an implementation partner: it helps you define which users, processes and devices are authorized, then builds and documents the account management setup that produces the evidence. Your organization owns the control and its decisions, and only an independent assessor issues a result.
How we scope
- We agree in writing which systems, identity sources and account types fall inside the AC.L2-3.1.1 scope before work starts.
- We inventory the user populations, service processes and authorized devices your organization needs to account for.
- We confirm with you the owners who approve account requests, terminations and transfers, and who keeps the authorization records.
How we build
- We configure a self-hosted identity provider such as authentik or FreeIPA to be the single source of account records for in-scope applications.
- We connect existing LDAP or Active Directory sources where your organization already manages accounts, so sign-in follows one record.
- We set up provisioning and reconciliation rules so disabled or departed accounts are removed from connected systems, with the rules documented.
How we hand over
- We deliver the account inventory, authorization records, configuration exports and review procedures that an assessor would ask to see.
- We test the account lifecycle end to end, from request through termination, and record the results for your own assessment file.
- We document each step so your staff can explain and repeat the process, and we flag any gaps for you to decide how to close them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- We can review account management evidence before your self-assessment or a third-party assessment, so you can confirm it is in final form.
- Your organization decides the final status of each requirement, and an independent assessor or certification body issues any report or certificate.
