Open source identity governance for CMMC access control

Open source identity governance for CMMC access control: what assessors test

A defense contractor that handles CUI has to show that every account reaching that data holds only the access its job requires, and that privileged functions are restricted and logged. midPoint can run the provisioning, role and review processes behind AC.L2-3.1.5 to 3.1.7, but it produces the evidence of those processes, not the compliance decision. Before you scope the work, confirm the current schedule. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been set to start 10 November 2026, and opened 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 force, and the eCFR text still shows the original four-phase schedule, so confirm the applicable obligations in your contracts with your contracting officer and your assessor.

Assessors work from NIST SP 800-171A (June 2018). For AC.L2-3.1.5 they will look for a list of privileged accounts and security functions, and written authorization for each that follows least privilege. For AC.L2-3.1.7 they will look for a defined set of privileged functions, evidence that non-privileged users cannot run them, and audit records of their execution. A requirement is MET only when every applicable objective is satisfied with final evidence, and AC.L2-3.1.5 is a 3-point item that cannot go on a POA&M, so a gap there blocks Conditional or Final Level 2 status. Practical checks include exporting the privileged role assignments from midPoint and reconciling them against the target system's own admin groups, and confirming that the role catalog and approvals are dated and retained.

DeployOpen prepares the systems, role models, review records and evidence packages for these objectives, and runs the implementation within your own environment. It does not issue assessments, attestations or certifications; a C3PAO assesses Level 2 certification, and the CMMC Accreditation Body, currently The Cyber AB, authorizes those assessors. Before you engage a partner, ask for a mapping of each objective to a midPoint object, report or workflow, a sample evidence package from a comparable scope, and a written statement of which steps remain your responsibility. The CMMC Level 2 assessment guide is the natural next read for the objective wording.

How AC.L2-3.1.5 to 3.1.7 map to identity governance controls

This table compares the two CMMC Level 2 access control requirements against the midPoint configuration that supports each one, and what an assessor will look for in the evidence. Read each row as a control objective, then as a configuration task and an evidence item. The main takeaway is that both requirements are scored at 3 points and cannot be placed on a POA&M, so role design, approvals and reviews for privileged access must be working and evidenced before an assessment.

Requirement or objective	What midPoint must do	Evidence an assessor expects
AC.L2-3.1.5: identify privileged accounts and security functions	Tag privileged roles and entitlements in the role catalog (for example, domain admin, CUI system administrator, audit log access) and flag them with a dedicated attribute so they can be reported and reviewed separately.	A current list of privileged accounts and security functions, with the role definitions that grant them and the named owner of each.
AC.L2-3.1.5: authorize access to privileged functions only as least privilege requires	Build roles at the narrowest practical granularity, assign them by job function through policy-driven assignments, and require an approval workflow for each privileged role before midPoint provisions it.	Approval records for each privileged assignment showing approver, justification, scope and date, plus the role definition in force at that time.
AC.L2-3.1.5: confirm that non-privileged work does not carry privileged rights	Use separate privileged and everyday accounts where possible, and configure segregation rules so one identity cannot hold conflicting roles, such as assigning CUI approvals and CUI administration to the same person.	Segregation of duties rule definitions, any exceptions with approvals, and a report showing no identity holds a blocked role combination.
AC.L2-3.1.5: review privileged access on a defined cadence	Run certification campaigns scoped to privileged roles and CUI system entitlements, route them to resource owners, and configure removal or revocation of any access not re-certified.	Completed campaign reports with reviewer decisions, timestamps, revocations executed and evidence that revoked access was removed from the target system.
AC.L2-3.1.7: define privileged functions and non-privileged users	Maintain a documented list of privileged functions (for example, changing audit settings, managing accounts, altering security configuration) and map each one to the midPoint roles that grant it, so non-privileged roles are defined by exclusion.	A written definition of privileged functions and a role-to-function mapping that matches what is actually assigned in midPoint and in the target systems.
AC.L2-3.1.7: prevent non-privileged users from running privileged functions	Ensure target system connectors provision only the privileged roles approved in midPoint, and reconcile target systems against midPoint so that local or out-of-band privileged grants are detected and reported. midPoint does not enforce function-level execution on its own, so enforcement sits in the target systems.	Reconciliation reports showing no unmanaged privileged grants, and configuration or screenshots from target systems showing privileged functions restricted to the approved groups.
AC.L2-3.1.7: capture execution of privileged functions in audit logs	midPoint records provisioning, assignment and approval events in its audit trail. Confirm that target systems and the logging pipeline also record privileged function execution, and that the logs are retained and reviewable.	Sample audit log entries showing privileged function execution tied to a named account, with log retention settings and the process used to review them.
Scoring impact for both requirements	Both requirements are worth 3 points under the CMMC Scoring Methodology, so each must be MET for Conditional or Final Level 2 status. Confirm current assessment timing with the DoW CIO and the Cyber AB before scheduling work.	Assessment objectives for NIST SP 800-171A (June 2018) satisfied with final, not draft, evidence for every applicable objective.

How role models in midPoint define least privilege for CUI systems

A least privilege role model in midPoint starts by separating three populations in the role catalog: users who reach the CUI enclave, administrators and security function holders, and standard business users who never touch CUI. Keep these as distinct role families with their own naming convention, for example a cui-enclave- prefix for enclave access, an admin- or secfn- prefix for privileged roles, and a std- prefix for everyday roles. The privileged roles should be flagged explicitly in midPoint, for instance through a role property or a dedicated category that your reports can filter on, so that AC.L2-3.1.5 and AC.L2-3.1.7 can be shown with a population list rather than an argument. Assessors check whether you have identified privileged accounts and security functions at all, so the catalog itself is the first piece of evidence.

Build the first draft of roles from existing access rather than from job titles alone. Export current group memberships, directory roles and application permissions from each CUI system, cluster users who hold the same sets, and then validate each candidate role with the system owner and the requirement owner for CUI. Record which entitlements were inherited from older groups and which were granted by exception, because the exceptions are where least privilege most often fails. Before any role is assigned to a CUI system, confirm connector coverage for that system: whether midPoint has a supported ConnId connector for the target, whether the connector can read and write the entitlements that the role references, and whether it can report them back for review. Where coverage is community or experimental, or absent, the role model still needs a manual or scripted fulfillment step that is itself documented and reviewed.

Which open source platforms fit each part of the control set

midPoint is the component that decides who holds which access and records why. It models roles, assigns entitlements through policy, provisions accounts into target systems through connectors, and runs certification campaigns that show a reviewer approved each privileged assignment. For AC.L2-3.1.5 and 3.1.7, its role catalog and assignment history are the best place to show that privileged accounts and security functions were identified and authorized.

Role model: Separate roles for privileged functions, such as administration of CUI systems, from ordinary business roles so the privileged population can be listed and reviewed on its own.
Connectors: Documented connectors include LDAP, Active Directory, SCIM2 and Microsoft Entra ID, which cover most directories that hold CUI system accounts. Confirm each target system has a supported connector before go-live.
Certifications: Campaigns can route privileged assignments to named owners and keep their decisions as records.
Versions: midPoint 4.10.5 is the current release, and midPoint 4.8 (Curie) is the long-term support release supported until October 17, 2028. Choose the line that matches your upgrade policy.
Scope limit: midPoint is an identity management system, not an SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML.

Ask the integrator to show how a privileged role is defined, approved and removed in midPoint, and which report proves each step to an assessor.

How the work runs from role baseline to first certification campaign

The sequence moves from defining the CUI boundary and its privileged accounts to a first certification campaign whose decisions and evidence are frozen for assessors. Each step closes with a check the team can show to an assessor, so the baseline is provable rather than assumed.

Scope the CUI systems inside the assessment boundary
The client's compliance lead and system owners list every system, directory, application and service that stores, processes or transmits CUI, plus the identity sources that feed them. DeployOpen maps which midPoint connectors, SSO flows and administrative paths touch those systems, so accounts in scope are defined by the boundary, not by the team that manages them. The step is done when the boundary diagram and system inventory are signed off by the client, because every later requirement is measured against it.
Identify existing privileged accounts and security functions
Working with directory administrators and application owners, the team enumerates accounts that hold administrative rights, service accounts with broad permissions, and the security functions such as audit log configuration, key management and user administration. Each entry records the owning person or team and the justification for the privilege. The step closes when the privileged account register exists for the in-scope systems, since AC.L2-3.1.5 and AC.L2-3.1.7 both depend on knowing which accounts and functions are privileged.
Clean up orphaned and excess access before go-live
midPoint reads the current entitlements from each in-scope source through its connectors and compares them with authoritative HR data. Accounts with no owner, dormant accounts and access beyond what a person's job requires are listed for disposition. Owners decide to keep, reduce or remove each entitlement, and removals are executed through the connectors with the decision recorded. The step is done when the orphan and excess report shows no unexplained access in the boundary and every retained privilege has a named approver.
Build and approve the role model
Roles are derived from observed access patterns and job functions, then reviewed by business owners and security staff. Each role states the entitlements it grants, whether it is privileged, and who may request it. Privileged roles are kept separate from standard roles so that a non-privileged user cannot pick up a privileged function through a general role. The step closes with an approved role catalog and a log of approvals, which becomes the reference an assessor compares against actual assignments.
Configure connectors and joiner, mover and leaver rules
The team configures connectors to the in-scope targets, sets the rules that assign roles from HR attributes, and defines how a change of job or departure removes access. Privileged role assignments require an approval step in midPoint before they take effect. Test accounts run through each rule in a non-production environment, and the results are retained. The step is done when test cases for joiner, mover and leaver events pass and the rule set is version-controlled and documented.
Run a first certification campaign
Reviewers, typically managers and system owners, certify whether each account and privileged role remains necessary. midPoint routes items to the right reviewer, records each decision, and flags items left unanswered for escalation. The security team reviews revocations and confirms they were applied on the target system, not only in midPoint. The step closes when every item has a decision and every revocation is verified against the target, since an unverified decision does not show the access was removed.
Freeze evidence in final form
Once the campaign and rule tests are complete, the team exports the role catalog, approvals, connector configuration, campaign results, revocation records and the privileged account register as final, dated records. Drafts are replaced rather than edited. A short mapping ties each artifact to the assessment objectives for AC.L2-3.1.5 and AC.L2-3.1.7 in NIST SP 800-171A. The step is done when the evidence set is versioned, stored under access control and reviewed by the client, because a requirement is met only when its evidence is in final form.

What assessors ask for and which component produces it

This table maps the evidence an assessor typically examines for AC.L2-3.1.5 and AC.L2-3.1.7 to the component that produces it and what must be kept in final form. Read each row as a question the assessor will ask, then confirm the record exists, is complete and can be reproduced from the system of record. Missing final-form evidence is the most common reason a requirement fails to be MET.

Evidence item	Produced by	What must be retained in final form
Privileged account and security function inventory	midPoint (role and entitlement catalog), with account data from source directories	Dated export of privileged roles, the accounts holding them and the security functions each role grants, with the owner who approved the list
Role definitions and assignment history	midPoint role model and assignment audit records	Approved role definitions with version history, plus a time-stamped record of each assignment and removal showing who requested and who approved it
Approvals for privileged grants	midPoint approval workflows, with the approval decision stored on the request	Completed approval records showing approver identity, justification, decision date and the access granted, not drafts or unsigned requests
Certification campaign decisions	midPoint certification campaigns	Closed campaign reports listing each reviewer decision, the reviewer, the date, remediation actions taken and evidence of follow-up on revoked access
Removal records on leave or role change	midPoint lifecycle and reconciliation records, with Keycloak session and account disablement logs for the SSO layer	Timestamped deprovisioning or role-change events tied to the HR trigger, plus confirmation that access was removed in each connected system
Audit logs of privileged function execution	Wazuh or Security Onion collecting logs from hosts, directories and applications where privileged functions run; OpenBao audit devices for secret and key access	Retained, tamper-resistant logs covering privileged command and administrative events, with a documented retention period the organization can confirm against its own requirements

What tooling alone does not satisfy

A midPoint deployment can enforce least privilege for accounts that reach CUI, but it does not write the policy, prove the connectors cover every system or decide what sits inside the assessment boundary. The cards below cover the gaps assessors look for, and each one needs a named owner and evidence before the assessment.

Policy and SSP come first

A midPoint role model is not a written access control policy or a System Security Plan. Assessors test whether the SSP describes how access is granted, reviewed and removed, and whether the implementation matches that description. Ask your partner to deliver the role catalog, approval rules and review procedure as signed documents that name the systems each role reaches, so the platform configuration can be checked against written intent.

Connector coverage for CUI systems

Each application that stores or processes CUI must either be reached by a connector or handled through a documented manual process. A connector that reads accounts may not remove entitlements, and a community connector may not be supported for your version. Check every CUI system against its connector status, test deprovisioning in a non-production copy and record any system that is still managed by hand.

Endpoint and workstation controls

Least privilege on a workstation, such as local administrator rights, application allow-listing and session lock, is usually managed by endpoint tooling or group policy, not by the identity governance platform. Requirements tied to privileged functions on endpoints can therefore fail even when midPoint is correct. Identify which endpoint settings the assessment will examine, assign each to an owner and collect their configuration evidence separately.

Assessor judgment against objectives

The 110-point score depends on whether the assessor finds every applicable NIST SP 800-171A objective satisfied for AC.L2-3.1.5 and AC.L2-3.1.7. Those objectives require you to identify privileged accounts and functions, authorize them and show that non-privileged users cannot run privileged functions. A screenshot of a role does not meet that standard. Pre-test each objective against the evidence you intend to show, and ask your partner to walk through the objective list with you before the assessment.

Boundary decisions stay with people

Tooling cannot decide which systems, accounts, enclaves and service identities are in scope for CUI. That decision depends on where CUI is stored, processed and transmitted, and on which external service providers touch it. If the boundary is drawn too narrowly, the midPoint deployment will look complete while accounts that reach CUI remain unmanaged. Document the boundary, have the scope approved by the accountable executive and rerun the account inventory whenever a system joins or leaves.

Schedule changes move the proof

The Department of War suspended CMMC Phase II on 13 July 2026, and NIST withdrew SP 800-171 Rev. 2 on 14 May 2024 when it published Rev. 3, while the CMMC rule still incorporates Rev. 2. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Confirm with your contracting officer which revision and assessment path applies to each contract, and keep the evidence for the controls in a form that can be re-examined later.

How much effort and cost does CMMC access control with midPoint require?

What drives the cost of midPoint for CMMC access control?

The software itself carries no license fee, so the cost is the work around it. midPoint is published under the European Union Public License 1.2 or later, and Evolveum states it has no enterprise edition. The main cost components are connector work for each target system, role modeling against the systems that hold CUI, cleanup of existing accounts and entitlements, infrastructure for the midPoint and PostgreSQL servers, and support. Connector and role-modeling work usually grows with the number of systems in the CUI boundary. Ask any quote to split one-time build work from recurring support and upgrades, and to name who is paid for each item.

How long does a midPoint access control project take?

Duration depends on the number of CUI systems, the state of existing roles and the quality of HR data, so no general timeline can be given here. The work runs in phases: scoping the CUI boundary, mapping privileged accounts and security functions, modeling roles, building connectors, cleaning up existing access, then running the first review cycle. Most engagements are fixed-scope, so ask for the phase plan, the dependencies on your teams and the acceptance criteria in writing before work starts.

What does the client team need to provide during implementation?

The engagement depends on people who own data and decisions, not only on engineers. Expect to need:

HR data owners who can confirm the authoritative source for joiners, movers and leavers
System owners for each CUI application, directory and database, who can explain their roles and privileged accounts
Approvers for access requests and privileged functions, named in writing
Security and compliance staff who can define privileged functions and confirm the evidence format assessors will accept

Agree on these owners at scoping, because delays in any of them usually delay the go-live date.

Can an internal team implement midPoint for CMMC without a partner?

An internal team can implement midPoint alone if it has Java and PostgreSQL operations skills, identity engineers who know the ConnId connectors for each target system, and staff who can model roles and run certification campaigns. Many organizations lack one or more of these skills at once, and the CMMC requirements add assessment evidence work on top of the build. Test the decision against your own staffing: confirm who will maintain connectors after go-live, who will run upgrades on the long-term support line, and who will produce evidence during an assessment. DeployOpen can implement, integrate, harden and document a midPoint deployment under a written scope if you choose that route.

Does DeployOpen certify CMMC compliance for my organization?

No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for compliance assessments. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and self-assessments are performed by the organization itself. Ask any partner, including DeployOpen, to state in writing which parts of the work produce evidence and which parts remain your responsibility.

Which CMMC schedule changes should I watch before budgeting?

The schedule has changed recently, so check the current status before committing budget. On 13 July 2026 the Department of War suspended CMMC Phase II and started 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. The DoW CIO 'About CMMC' page said implementation is paused and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still contains the original four-phase schedule. Confirm the current status with the contracting officer and the DoW CIO page before setting dates. Also watch for NIST SP 800-171 Rev. 2 versus Rev. 3, because the CMMC rule still incorporates Rev. 2 while the Department of War said it will enforce Rev. 2 in the interim.

Why does AC.L2-3.1.5 matter so much for the scoring and effort?

AC.L2-3.1.5 is a 3-point requirement under the CMMC Scoring Methodology, so it cannot be placed on a POA&M and must be MET to reach Conditional or Final Level 2 status. Under 32 CFR 170.21(a)(2), a requirement worth more than 1 point is not eligible for a POA&M. This means the least privilege work, including identifying privileged accounts and authorizing access to each security function, cannot be deferred to a later sprint. Budget identity work on privileged accounts early, because a gap there can block the whole assessment outcome.

What recurring work follows go-live with midPoint?

Most of the cost after go-live is recurring operations. Plan for midPoint upgrades, connector maintenance as target systems change, periodic certification campaigns, review of role definitions, and evidence retention. Evolveum offers Product Support subscriptions with 8x5 next-business-day or 24x7 SLA options and Platform Subscriptions, and the subscription page lists no prices, so request current terms directly. Select a release line with a published support end date, such as the 4.8 long-term support release that is supported until 17 October 2028, and budget upgrade work against that date.

Official sources for the CMMC and NIST requirements

The requirements for AC.L2-3.1.5 and AC.L2-3.1.7 come from a small set of primary texts, and each one answers a different question. Read the rule for scope and scoring, the model for requirement IDs, the assessment guide for what an assessor checks, and the NIST documents for the underlying control wording. Check each source against the version your contract references before you design a role model.

CMMC Program rule

32 CFR Part 170 sets the CMMC levels, the scoring method and the rules for POA&M eligibility. Section 170.14 defines the Level 2 requirements as identical to NIST SP 800-171 Rev. 2, and section 170.24 explains why AC.L2-3.1.5 cannot be carried on a POA&M. Confirm which version of the eCFR text applies to your contract, because the phase schedule has been under review in 2026.

DoW CIO Level 2 assessment guide

The Level 2 Assessment Guide, version 2.13, shows how assessors plan and score each requirement, including the evidence they expect for privileged accounts and privileged functions. Use it to build your evidence list for AC.L2-3.1.5 and AC.L2-3.1.7 before the assessor asks for it. Check whether a newer guide has been published, since the program schedule has changed.

NIST SP 800-171 Rev. 2

This publication holds the requirement wording that CMMC Level 2 incorporates, including 3.1.5 on least privilege and 3.1.7 on preventing non-privileged users from running privileged functions. Map each requirement to a midPoint role, entitlement or audit setting using your own words. NIST withdrew Rev. 2 when Rev. 3 was published, so confirm with your contracting office which revision governs your assessment.

NIST SP 800-171A assessment objectives

This companion publication, dated June 2018, lists the assessment objectives behind each requirement. For AC.L2-3.1.5, the objectives cover identifying privileged accounts and security functions and authorizing access to each under least privilege. For AC.L2-3.1.7, they cover defining privileged functions, blocking non-privileged execution and capturing that execution in audit logs. Build your test cases from these objectives so each one has a matching record in midPoint or the target system.

midPoint release and support dates

The midPoint releases page shows which version is current, which release is long-term support and when each branch leaves support. Choose the version your role model and connectors will run on, and plan upgrades before a branch reaches end of support. Check the page again before go-live, because the feature release schedule changes.

How DeployOpen scopes and delivers CMMC-ready identity governance

The sequence turns CMMC Level 2 access control requirements into a written scope, a midPoint deployment in your own environment, and evidence that your assessor can examine. Each step closes with an output you can check before the next one starts.

Confirm CUI boundary and account population
DeployOpen works with your security, compliance and IT leads to map which systems store, process or transmit CUI, which accounts reach those systems, and which privileged accounts and security functions exist. The inputs include directory exports, system owner lists and the current system security plan. The step closes with a written population inventory that names each system, account type and owner, so the scope of AC.L2-3.1.5 and AC.L2-3.1.7 is defined before any design work begins.
Agree a fixed scope in writing
Engagements are fixed-scope, so the systems to connect, the role model work, the connectors, the review campaigns, the handover items and any excluded areas are written down and agreed before work starts. Your team signs off on the scope document, and DeployOpen issues a quote that follows from it. The output is a signed scope with deliverables and acceptance criteria. Anything outside that document needs a written change before it is built.
Design the role model and privilege rules
DeployOpen builds roles from the access your people hold today, separates standard roles from privileged roles, and documents which functions only privileged accounts may execute. Approvers, owners and the rules for granting privileged access are recorded alongside each role. The output is a role catalog that maps each role to its systems, approvers and least-privilege justification, which becomes the basis for the 3.1.5 and 3.1.7 evidence.
Deploy midPoint in your infrastructure
DeployOpen installs midPoint, its PostgreSQL repository and supporting components inside your own cloud accounts, data centers or enclaves, following the midPoint system requirements for the Java version and database placement you choose. Your team controls the hosts, keys and network paths, and CUI never leaves that environment. The step closes with a tested non-production instance and a documented build record that names the release and configuration baseline.
Connect sources and target systems
DeployOpen configures the ConnId connectors that reach your authoritative source and the systems that hold CUI, then reconciles accounts against those systems before any automated changes are switched on. Orphaned accounts, shared accounts and excess privileges are reported and routed to owners for decision. The output is a reconciliation report showing the account population after cleanup, with each exception recorded and resolved or accepted by its owner.
Configure approvals, reviews and audit logging
DeployOpen sets up access request and approval workflows for privileged roles, schedules certification campaigns, and confirms that provisioning and privilege changes are written to logs that your team can retain and export. Test cases are run with your staff to show that non-privileged users cannot obtain privileged functions through the configured paths. The output is a test record covering approvals, review decisions and log capture, which supports the assessment objectives for 3.1.7.
Prepare assessment evidence and hand over
DeployOpen assembles the evidence package that maps the implemented controls to the NIST SP 800-171A objectives for 3.1.5 and 3.1.7, including role catalogs, approvals, review records and log samples in final form. Your team reviews the package and the runbooks, and the handover is recorded. DeployOpen prepares these systems, controls and evidence but does not issue assessment results or attestations. Assessors from the C3PAO or the appropriate body make that determination.
Continue with optional retainers
After handover, you can choose a retainer for upgrades, support and periodic testing of the identity platform. Upgrades are planned against the midPoint release and long-term support dates, which you should confirm with Evolveum and your own change process. The output is a documented support agreement with agreed response expectations and a maintenance calendar, so the access control evidence stays current between assessments.

Open source identity governance for CMMC access control