Argo CD for CMMC change management (CM.L2-3.4.3)

How Argo CD supports CMMC change management for CM.L2-3.4.3

A defense contractor that handles CUI in Kubernetes environments needs evidence that each change to those systems was tracked, reviewed, approved or disapproved, and logged. These are the four assessment objectives that NIST SP 800-171A (June 2018) breaks out for CM.L2-3.4.3. Argo CD can supply much of the technical record for the tracking, review and logging objectives, because desired state lives in Git pull requests and Argo CD keeps sync history. It does not decide whether a change is authorized, run your change control board, assign the requirement's score, or make a system compliant. DeployOpen plans, configures and documents these controls and prepares the evidence, but it does not issue certifications or attestations. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB.

Program status changes the timing of assessments, not the control design. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, 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 states that, as of 17 October 2026, implementation is paused in Phase 1 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 with your contracting officer which assessment your contracts require before you scope the evidence set. Level 2 self-assessments use the same assessment objectives, so the design work carries over either way.

Start by deciding which Argo CD projects, clusters and namespaces host CUI workloads, because the evidence set only needs to cover systems inside your assessment scope. Within that scope, make the Git repository and its protected branch the record of approval, and separate the people who approve changes from the people who trigger syncs using Argo CD projects and RBAC. Set admin.enabled to false once SSO works, and review which identity provider groups map to Argo CD roles. Retain the pull request reviews, sync history and Kubernetes events for each change in the form they were recorded. A requirement is met only when its evidence is in final form, so do not plan to rebuild records from drafts during the assessment.

Mapping CM.L2-3.4.3 objectives to Argo CD capabilities

This table maps each SP 800-171A assessment objective for 3.4.3, plus the SP 800-53 CM-3 mapping, to the Argo CD feature that produces the evidence and to the configuration that keeps that evidence trustworthy. Read each row as a question an assessor will ask, then check the configuration column against your own cluster. The main takeaway is that Argo CD covers the records side well only when SSO, RBAC and repository settings are locked down first.

Assessment objective or mapping	Argo CD capability that supports it	Configuration to confirm
Tracking changes	Git commit history records each desired-state change, with author and timestamp for the commit	Repositories defined as Kubernetes Secrets, since Argo CD 3.0 no longer reads repository configuration from argocd-cm
Reviewing changes	Pull requests in the Git host hold the diff and reviewer comments before the change reaches the synced branch	Confirm your Git host enforces review and that the sync target branch is protected from direct pushes
Approving or disapproving changes	AppProject source and destination restrictions limit which repositories and clusters a change can reach, and RBAC limits who can sync	Update and delete RBAC applies only to the application itself, so scope sync permissions per project and team
Logging changes	Sync history and Kubernetes events record what was applied and when, and Argo CD logs record user actions	Logs access needs an explicit logs, get permission, so grant it only to roles that need to review logs
Identity behind each change	SSO through Dex or a direct OIDC provider maps identity groups to Argo CD roles, so each sync traces to a named person or automation	Set admin.enabled to false once SSO or local users are configured; with Dex RBAC, confirm the federated_claims.user_id claim
Resource tracking across the cluster	Annotation-based resource tracking is the default, so each managed resource is linked to its owning application	Confirm the tracking method in your installation and check that manually created resources appear as drift
SP 800-53 CM-3 mapping (configuration change control)	Git as the approved baseline, review before sync, and retained records of applied changes supporting the CM-3 evidence assessors examine	Document which pull request approvals and sync records form your change control record set for the assessment

How a Git-driven change becomes a tracked system change

The change record for a CM.L2-3.4.3 assessment starts in Git, not in Argo CD. A proposed change begins as a commit on a branch, and the pull request must exist before the sync happens. The DoW CMMC FAQ of July 2026 advises documenting each change in the change management process before implementation, so the assessor will look for the proposal, the review and the approval timestamp ahead of the first Kubernetes change. Configure your Git host so that merges to the branch Argo CD tracks require an approved pull request, and so that the pull request template captures the reason for the change, the affected application, the risk and the rollback plan. Confirm with your Git host which audit log entries it retains for approvals and force pushes, and how long they are kept, because those entries are what you will show the assessor.

After the merge, Argo CD detects the new commit revision for the tracked application and, if the Application uses automated sync, applies it, or waits for a manual sync from an authorized user. Each sync records the Git revision it deployed, the operation's start and finish times, the user or automation that triggered it, and the resulting resource status. Kubernetes events and the application controller logs add detail on what changed in the cluster. Decide early whether sync is automated or manual for each project, since manual sync adds a second authorization point that you must also record. Confirm in your own environment how long Argo CD keeps sync history in the Application status and whether you export it to a logging system, because history that is not exported may be lost when the application is pruned or the controller is redeployed.

The record set is only useful if each entry links back to the same change. Use the Git commit SHA as the common key: the pull request references it, the sync history shows it, and the cluster state reflects it. Drift that happens outside Git is a separate event that the requirement's logging objective also covers, so plan how unexpected out-of-band modifications are detected and reviewed. A rollback is itself a change, so route it through the same pull request and approval path, and keep the emergency path documented in advance. Ask your assessor's expectations and your C3PAO, if one applies, how they want the linkage demonstrated, since the assessment objectives in NIST SP 800-171A define what must be tracked, reviewed, approved and logged.

Assessment objects Argo CD can help produce

Assessors testing CM.L2-3.4.3 look for records they can sample, not for a tool's screen. Argo CD produces some of the raw material automatically, such as Git history and sync results, while the review, approval and oversight records must be captured and kept in final form by your team.

Change control records

Pull requests and their approvals in your Git host are the closest thing Argo CD has to a change control record. Each merged commit that Argo CD syncs should trace to a reviewed request, a named approver and a linked ticket where your process uses one. Check that branch protection requires approval and that approvers differ from authors. Export or archive these records once a change is merged, because a pull request left open or in draft does not satisfy the objective. Argo CD does not generate the approval decision or the ticket itself.

Change review reports

Sync history and diff output show what Argo CD actually applied and what differed from Git before a sync. Argo CD keeps recent sync operations and revision details, but retention depends on your configuration and history limits, so confirm the settings in your environment. Export the sync record for each change window into your evidence store and keep the diff or review note that a person signed off on. Argo CD does not write a review decision for you, and a dashboard view is not a retained report.

Oversight meeting agendas and minutes

Assessors may interview change control board members and request agendas and minutes from configuration change control oversight meetings. Argo CD has no native place for these documents, so store them in your document management or GRC system and link them from the change tickets they cover. Confirm that minutes record decisions on specific changes and are finalized and signed before an assessment, since drafts do not count toward MET. Keep the board charter and membership list alongside them.

Sync and access event logs

Logs show who connected to Argo CD and which syncs ran, which supports the logging objective for changes. Access to logs requires an explicit logs, get permission, so grant it only to reviewers. Forward Argo CD audit-relevant events and Kubernetes events to a central log platform with retention set by your policy. Confirm which events your version emits and where, because Argo CD does not produce a complete change log on its own, and gaps need to be covered by Git and cluster audit logs.

Emergency changes and unapproved drift

A planned change starts as a commit to a branch in the configuration repository and becomes a system change only when it is merged and synced. The Git record carries the request, the review, the approver and the timestamp, which are the tracking, reviewing and approving elements that the assessment objectives for 3.4.3 look for. Argo CD adds the deployment half of the trail by showing which revision reached which cluster and when.

Protected branch rules: Require review from someone other than the author and block direct pushes to the branch Argo CD tracks. Confirm the exact settings in your Git host.
Commit to sync link: The sync history records the revision that was applied, so each deployment can be matched to a merged pull request.
Approver identity: Map reviewers and sync users through SSO groups so that the person who approved and the person who synced are both identifiable.
Change ticket reference: Require the ticket ID in the pull request template or commit message so the change control record can be found from either side.

Check that a sample of recent syncs can be traced to an approved merge request and a change ticket without manual lookup.

What Argo CD does not cover for CM.L2-3.4.3

Argo CD records and enforces changes to Kubernetes workloads from Git, but 3.4.3 covers every change to the system in scope. The cards below cover the parts that sit outside Argo CD and must be evidenced by the organization through its own change board, approval records, logs and assessment boundary.

Change control board and meeting records

Assessors may interview members of the change control board and request agendas and minutes of configuration change control oversight meetings. Argo CD has no record of board decisions, risk discussions or rejected proposals. Provide a charter, membership list, meeting cadence and dated minutes, and confirm that each Git change maps to a board decision where the board requires one.

Approval policy outside Git

Argo CD can require pull request review, but the policy that defines who may approve, which changes need board review and how emergency changes are handled usually lives in a written procedure. Confirm that the branch protection rules, CODEOWNERS entries and Argo CD project permissions match that procedure, and that the procedure is itself version-controlled and approved.

Non-Kubernetes systems and network devices

Firewalls, switches, hypervisors, databases outside the cluster and vendor appliances change through their own tools. Argo CD cannot track or log those changes. Inventory every in-scope system that is not reconciled by Argo CD, and decide whether each uses its own change ticketing, configuration backup or a separate tracking process that produces the four 3.4.3 records.

Log retention and off-cluster storage

Sync history and Kubernetes events are kept in the cluster and can be lost when workloads or namespaces are recreated. Audit records need a retention period set by your policy, and logs should be shipped to storage the cluster administrators cannot alter. Confirm where Argo CD and API server logs go, who can delete them, and how long they are kept.

Endpoint and workstation changes

Engineers' laptops, build agents and administrator workstations change through patching, software installs and local configuration. These changes fall under 3.4.3 when they touch in-scope systems, but they never pass through Git. Document how endpoint changes are tracked, reviewed and logged, typically through endpoint management tooling and ticket records, and include them in the change process.

Assessment scope and boundary decisions

Which Argo CD clusters, Git hosts, runners and identity systems fall inside the CMMC assessment boundary is a decision the organization makes and documents, and assessors will test it. Define the boundary before collecting evidence, record which components handle CUI, and confirm any external Git host or cloud service used for the repositories meets the cloud requirements that apply to it.

When CM.L2-3.4.3 can go on a POA&M

CM.L2-3.4.3 is a 1-point requirement that is not on the 170.21 exclusion list, so it can be placed on a plan of action and milestones (POA&M) if the rest of the assessment supports Conditional Level 2 status. Under 32 CFR 170.24, the score must be at least 88 of 110 (0.8), and closeout is due within 180 days. For Argo CD, that means the change-tracking, review, approval and logging objects described above must be largely in place already. A POA&M entry lets an organization record a gap while it closes it. It does not make the control exist, and an assessor will not accept a POA&M for a change process that has never run.

Before relying on this option, check the current program status. The Department of War suspended CMMC Phase II on 13 July 2026, and its CIO's About CMMC page says implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2. Confirm which assessment type applies to your contract, whether a certification assessment is required, and how your sponsor treats POA&M entries under DFARS 252.204-7021 and 252.204-7025. Also confirm the current requirement text in the official eCFR entry for 32 CFR Part 170, because the eCFR still carries the original phase schedule.

Treat the POA&M rules as a question for counsel and your contracting officer, not as a planning assumption. Ask them to confirm the scoring treatment, the closeout date rules and whether a Git-based change record created during the gap period counts toward closure. Then decide whether you want Argo CD's pull request and sync history to be complete before the assessment, which is usually the safer position, because it removes the need to rely on a POA&M for the requirement at all.

Configuring Argo CD so change records assessors can test

This sequence sets up identity, roles, approval gates and log retention in Argo CD so each production change has a traceable requester, reviewer, sync record and log trail. Each step closes with a check you can show an assessor. Work through the steps in order, because later steps depend on the identities and roles set earlier.

Enable SSO and disable the built-in admin account
Connect Argo CD to your identity provider, either through the bundled Dex connectors or directly through an existing OIDC provider, and confirm named users can sign in. Once local users or SSO work, set admin.enabled to false so the shared built-in admin account can no longer act. The user management documentation recommends keeping that account for initial setup only. The check: sign in with a named account, confirm the admin login is refused, and record the configuration change in Git.
Connect SSO groups to scoped roles
Write RBAC policies in argocd-rbac-cm that bind identity provider groups to roles, so each person receives only the projects and actions their job requires. On Argo CD 3.0 and later, Dex-based RBAC matches the federated_claims.user_id claim, so confirm which claim your identity path emits before writing policies. Keep the policy file in Git so access changes go through the same review as application changes. The check: sign in as one user from each group and confirm each sees only its assigned projects.
Define AppProjects with allowed repositories and destinations
Create an AppProject for each environment or team, listing the Git repositories it may read and the clusters and namespaces it may deploy to. Restrict the resource kinds each project can create so an application in one project cannot write into another team's namespace. Assign every Application to exactly one project. The check: attempt a sync from an unlisted repository or to an unlisted destination, confirm Argo CD rejects it, and store the project manifests in Git.
Require pull request review on the tracked branch
Argo CD syncs what the tracked branch contains, so the approval gate belongs in your Git host. Protect the branch that production applications track so changes arrive only through pull requests, with at least one reviewer who is not the author, and block direct pushes. Confirm that each merge record shows the reviewer and the commit that Argo CD later synced. The check: attempt a direct push to the protected branch and confirm the host rejects it.
Scope update and delete permissions to applications
Grant update and delete permissions in the RBAC policy only to roles that need them. Since the 2.14 to 3.0 upgrade, these permissions apply to the application itself, so test how a role's permissions behave against a non-production application before relying on them. Keep delete rights with a small, named group of operators. The check: run a test role against a sample application and confirm the actions it can and cannot take match your approval matrix.
Grant logs access only to auditors
Viewing application logs requires an explicit logs, get permission, so leave it out of general developer and operator roles. Create an auditor role with read access to the relevant projects plus the logs permission, and assign it only to people who review changes. Log output can expose operational detail, so this keeps it out of reach for everyone else. The check: sign in as a developer without the permission and confirm log requests are denied, then confirm the auditor role can read them.
Store repository credentials as Kubernetes Secrets
Since Argo CD 3.0, repositories must be defined as Kubernetes Secrets because repository configuration is no longer read from argocd-cm. Create repository Secrets with read-only credentials scoped to the approved repositories. Then confirm that each AppProject's sourceRepos lists only the repositories it needs. Argo CD redacts Git credentials from API responses and logs, which keeps them out of the evidence you export. The check: list the repositories Argo CD knows and confirm only approved ones appear.
Export sync history and logs to retained storage
Argo CD keeps its state in Kubernetes objects, so sync history can be lost with the cluster or pruned by configuration. Confirm how long sync history and events are kept in your Argo CD version, then forward Argo CD logs and Kubernetes events to a log platform with a retention period set by your records policy. Keep these exports outside the cluster so a cluster failure does not erase them. The check: restore a sample sync record from the retained store and match it to the Git commit and approver.

Questions buyers ask about CM.L2-3.4.3 and Argo CD

Does Argo CD alone satisfy CMMC requirement CM.L2-3.4.3?

No. Argo CD supports the requirement but does not satisfy it by itself. CM.L2-3.4.3 asks an organization to track, review, approve or disapprove, and log changes to its systems, and NIST SP 800-171A breaks that into four assessment objectives. Git pull requests, protected branches, Argo CD RBAC and sync history can provide much of the evidence for those objectives, but the organization still needs a written change control process, named approvers, and records that show the process was followed. Assessors also test whether people actually follow the process, so the tooling must match what the change board says it does.

What drives the cost and effort of setting this up for CMMC?

The main drivers are the number of environments and clusters, how mature the existing Git workflow already is, how long evidence must be retained, and how much interview preparation the team needs. Each additional environment adds project, access and sync configuration to review. A team that already uses pull requests with required reviews needs less change to its process than a team that deploys by hand. Evidence retention affects storage and export work. Ask any provider for a fixed-scope written proposal that lists the environments, repositories, identity integration, evidence outputs and staff time included, since a quote follows from that scope. DeployOpen does not publish prices.

How long does it take to configure Argo CD for this requirement?

The duration depends on the scope agreed in writing, so no fixed figure applies here. The work usually includes confirming the change process, configuring projects and RBAC so that only approved people can sync production, wiring identity provider groups, enabling audit history and exporting sample records, and then rehearsing an assessment walkthrough. Teams with a single cluster and an existing review process move faster than teams with many clusters, legacy manual deployments or unclear approval rules. Ask for a timeline tied to the agreed deliverables and to the staff time your side must commit.

What does the work need from our change board and staff?

The change board must define what counts as a change, who may approve it, how emergency changes are handled, and which evidence it will review and when. Staff must agree that production changes go through Git and that manual edits to live clusters are either blocked or recorded. Platform engineers provide access to Git hosting, identity provider settings and clusters. Someone must own the evidence process after handover, including who runs reviews and who answers assessor questions. Without these decisions, the tooling will record activity that nobody has agreed to review.

Can our own team implement Argo CD for CMMC change management internally?

Yes, a capable platform team can do this internally, provided it has time to read the Argo CD security and user management documentation, plan high availability, and build the evidence process. The harder parts are usually organizational: getting the change board to accept the process and keeping the records consistent over time. Many teams bring in an outside partner for the configuration review, a fixed-scope hardening pass or assessment preparation, and keep daily operations in-house. Decide early which parts you want to own and which you want reviewed.

Is Argo CD itself in scope for CUI under CMMC?

It depends on where Argo CD runs and what data it touches. Argo CD is self-hosted software, so it is assessed as part of the organization's own systems if it runs in an environment that stores, processes or transmits CUI, or that provides security protection for such systems. Repository content, cluster credentials and sync logs can carry sensitive information, so treat the Argo CD deployment and its clusters as part of the assessment boundary unless a scoping review shows otherwise. Confirm the boundary with your assessor or C3PAO and your compliance lead before the design is final.

How does the Phase II suspension affect planning for this requirement?

The suspension changes timing and the form of external assessment, not the requirement itself. On 13 July 2026 the Department of War suspended CMMC Phase II and started a 60-day review, while Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the DoW CIO page says implementation is paused in Phase 1 and the eCFR still contains the original schedule, confirm the current requirements with your contracting officer and assessment body. Planning should still treat CM.L2-3.4.3 as a control you must be able to show, because the rule still incorporates NIST SP 800-171 Rev. 2 and contracts may require it now.

How DeployOpen scopes and delivers CMMC change management evidence

DeployOpen plans, implements and documents Argo CD in infrastructure you control, so Git-based change flow, projects, RBAC and sync history can be presented as evidence for CM.L2-3.4.3. We prepare the systems, controls and records for your assessment, but we do not issue assessment results, and the C3PAO or self-assessment outcome remains with your organization and its assessor.

How we scope

Written scope lists the clusters, Argo CD instances, repositories and change roles that fall inside your CUI boundary.
Scope states which of the four SP 800-171A objectives for 3.4.3 each control is meant to support.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We configure pull request approval, separate merge and sync permissions, and project boundaries per environment.
We set up SSO, disable the built-in admin user and test RBAC roles against the change approval process.
We verify that sync history, Kubernetes events and Git commits can be exported and retained for assessors.

How we hand over

You receive configuration records, RBAC mappings, runbooks and a worked change record for each control.
Documentation maps each Argo CD control to the assessment objects your assessor is likely to request.
We walk your change control board and operators through the evidence collection steps before handover.

How we support

Ongoing support covers Argo CD patch and minor upgrades, with release review before each change to the platform.
Retainers can include periodic evidence reviews and drift checks ahead of your assessment window.
Confirm with your assessor and the current DoW CMMC guidance which evidence formats they accept before scoping.

Argo CD for CMMC system change management (CM.L2-3.4.3)