Argo CD for NIST CSF 2.0 PR.PS-01 configuration management

How Argo CD supports NIST CSF 2.0 PR.PS-01 configuration management

Argo CD helps with the PR.PS-01 outcome by making the desired state of Kubernetes workloads declared in Git, by routing changes through reviewed commits before they reach a cluster, and by showing when live state drifts from that declared state. It does not satisfy PR.PS-01 on its own. The outcome also depends on your hardened baselines, your review of default settings when software is installed or upgraded, and the people and processes that decide what a baseline contains. NIST does not certify or endorse CSF implementations or services, and DeployOpen prepares systems, controls and evidence for your assessment without issuing attestations. Independent assessors make the judgment on your program.

Start by deciding where the baseline lives. The Git repository holding Argo CD Applications, AppProjects and the workload manifests they reference is your candidate baseline, and the settings to confirm include the admin.enabled key in the argocd-cm ConfigMap, which the user management documentation recommends setting to false once local users or SSO are in place. Repositories must now be defined as Kubernetes Secrets since Argo CD 3.0, so confirm that repository definitions are themselves managed and reviewed. Then check that the AppProject sourceRepos and destination restrictions reflect the approved baseline rather than open defaults.

For the upgrade part of PR.PS-01, treat each Argo CD minor and patch release as a software change with a defaults review. The Argo CD 2.14 to 3.0 upgrade notes changed RBAC for update and delete actions, required an explicit logs permission, and made annotation-based resource tracking the default, so a baseline captured before the upgrade may no longer describe the same access. Record the release you run, confirm it is still within the patch window the release process describes, and compare the rendered configuration against the baseline after each change. Ask your partner or internal owner to document which defaults were reviewed, by whom and when.

Mapping PR.PS-01 and SP 800-53 CM controls to Argo CD capabilities

This table maps the three PR.PS-01 Implementation Examples and the CM-1 to CM-11 references to Argo CD features, the configuration each one needs, and whether the control depends on your own process. Read the Argo CD column as what the tool can enforce or record, and the last column as what your policies, people and reviews must still supply.

Requirement	Argo CD capability and configuration	Evidence to retain	Depends on your process
PR.PS-01 Implementation Example 1: hardened baselines with essential capabilities	Declare baseline manifests in a Git repository, enable selfHeal and prune in sync policies, and limit each Project to approved source repositories, destinations and resource kinds	Git history of baseline manifests, Project definitions, sync policy settings in version control	Yes: you define what counts as essential and approve the baseline
PR.PS-01 Implementation Example 2: reviewing default settings on install or upgrade	Read the official upgrade notes for each minor version before moving, then review changed defaults such as RBAC scope, logs access and resource tracking in a staging instance	Upgrade review record, staging test results, pull request that changes the Argo CD manifests	Yes: your change board must approve the upgrade and sign off the review
PR.PS-01 Implementation Example 3: monitoring deviations from approved baselines	Use automated sync with self-heal to revert out-of-band changes, and Argo CD's diff view to show drift on applications that are not auto-synced	Sync and drift history, Kubernetes events, alerts routed from Notifications	Yes: you decide who reviews drift alerts and how quickly they act
CM-1 Policy and procedures	Argo CD has no policy engine of its own; document how Git, Projects and RBAC implement your configuration policy	Approved configuration management policy and procedure linked to the repository	Yes: the policy and its owner come from your organization
CM-2 Baseline configuration	Store the approved Argo CD and application configuration as the desired state in Git and tag releases of the baseline	Tagged baseline commits, signed or protected branch settings	Partly: the content of the baseline is your decision
CM-3 and CM-4 Change control and impact analysis	Require pull request review before merge, and sync only from protected branches. Argo CD does not perform impact analysis; record it in the pull request	Pull request approvals, review comments, sync history linked to commit IDs	Yes: approval rules and impact analysis criteria are yours
CM-5 Access restrictions for change	Define RBAC so that people who merge changes are separate from those who run sync, and set update and delete permissions at the application level	RBAC policy file in Git, role membership from your identity provider	Partly: the separation of duties must match your access model
CM-6 Configuration settings	Set secure options such as admin.enabled set to false after SSO is configured, and keep settings in ConfigMaps and Secrets managed through Git	Config manifests in Git, admin account status checks	No: Argo CD settings are checked directly, but thresholds are yours
CM-7 Least functionality	Restrict Projects to required namespaces, clusters and resource kinds, and avoid enabling features you do not use	Project manifests, list of enabled features and resources	Yes: you decide which features and resource kinds are essential
CM-8 System component inventory	Use Argo CD Applications and registered clusters as the inventory of managed workloads, kept current in Git	Application and cluster lists exported from Git or the Argo CD API	Partly: the inventory must include systems Argo CD does not manage
CM-9 Configuration management plan	Document Argo CD's role, owners, upgrade cadence and recovery steps in one plan that points to the repository	Approved plan, owner list, review dates	Yes: the plan and its owners must come from your organization
CM-10 and CM-11 Software usage and user-installed software	Allow only approved repositories and charts in Projects, and restrict who can add repositories or registries	Repository allow lists, repository secrets audit, approval records for new sources	Yes: approval of new software and users is your process

Declaring hardened baselines in Git and keeping them there

For PR.PS-01, the approved baseline should be the Git state itself. In Argo CD, the Application and AppProject manifests define which repositories, paths, destination clusters and namespaces a workload may use, and which kinds of resources a project can create. Store those manifests in a repository with protected branches and required reviews, and treat any change to a project's source or destination lists as a baseline change that needs an approver. This gives CM-2 a concrete artifact to point to and gives CM-3 a review trail for every change. Confirm which fields your organization will treat as baseline (for example, allowed source repositories, destination clusters and cluster-scoped resource allowances) and write that list down before the first sync.

Repository content deserves the same scrutiny as the manifests. The Argo CD security documentation notes that the repo-server runs Helm and Kustomize against repository content, so a repository you do not control can influence what gets rendered and what files the build reads. Decide which repositories are trusted sources, restrict Helm and Kustomize usage to approved chart and overlay locations, and confirm how out-of-tree file access is handled in your version before you rely on it. Review rendered output for changes that a diff of the source files would hide, especially in charts pulled from external registries.

Two settings complete the baseline. The user management documentation recommends using the built-in admin account only for initial setup and disabling it by setting admin.enabled to false once local users or SSO are configured. Record that setting in the baseline and test it after each upgrade, since a re-applied default can reopen the account. Pair it with SSO through bundled Dex or a direct OIDC provider, so that access roles come from identity group membership rather than shared credentials. Confirm which identity provider and group claims your environment uses before you map them to project roles.

Evidence Argo CD produces for CM and PR.PS-01 reviews

Argo CD leaves evidence in three places: Git, the Argo CD control plane and the Kubernetes cluster. The cards below cover six record types an assessor may sample when testing configuration management under PR.PS-01. Each record shows part of the story, so plan to retain them together and confirm with your assessor which combination satisfies your scope.

Git history and pull request approvals

Git is the declared baseline, so the commit log and pull request reviews show who proposed each configuration change and who approved it. Assessors often pick a sampled change and ask for the approving review, the reviewer identity and the commit it produced. Retain branch protection settings, required reviewer rules and the signed-commit policy, if you use one, alongside the repository export. Check that the approver is not the same person who merged the change.

Sync history and revision records

Argo CD records each sync with the Git revision applied, the time and the initiating user or automation. This ties a deployed state to a specific commit, which is what a baseline test needs. Confirm how long your Argo CD instance keeps this history, since retention depends on your configuration, and export it to your log store on a schedule so it survives application deletion or a reinstall.

Kubernetes events and object state

Kubernetes events and the live state of managed objects show what the cluster actually ran after a sync. Comparing the rendered manifests with live objects supports deviation monitoring, which is the PR.PS-01 implementation example most directly tied to baselines. Events expire quickly by default, so forward them to durable storage. Ask your platform team how drift detection results are captured and whether they are alerted on.

RBAC and project definitions

AppProjects, RBAC policy and SSO group mappings define who may change which applications and clusters. Store these files in Git so every change to permissions is itself reviewable. Assessors typically ask for the current policy, the approval history for the last change, and proof that the built-in admin user is disabled where your user management standard requires it. Note that Argo CD 3.0 changed how Dex RBAC reads the federated claim, so policies written earlier need checking.

Upgrade records against release notes

Each Argo CD upgrade should have a change record that names the version, the release notes reviewed, the default settings that changed and the test results. Patch releases are published per supported minor line, so record which line you run and when it was last patched. Pair the record with the Git commit that updated the installed version, so the upgrade is traceable in the same way as an application change.

Redacted logs and access logs

Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, which lets you retain logs without storing secrets. Retain API and access logs centrally, and confirm during a test that a sample log line carries no token or repository password. Assessors often sample log entries around a production sync or an access change, so check that timestamps and user identities are present and that log access is itself restricted.

Configuring Argo CD for a PR.PS-01 review

This sequence sets up Argo CD so that its desired state, access model, repository configuration and drift signals are in place before anyone relies on them as configuration management evidence. Each step ends with a check the reviewer can repeat.

Deploy Argo CD in high availability
The platform team installs the HA manifests on a cluster with at least three nodes, since the HA documentation notes that pod anti-affinity rules need that capacity. Confirm that your cluster is not IPv6-only, because the HA documentation says those clusters are not supported. Treat Redis as a disposable cache and keep the application state in Kubernetes objects, so that a rebuilt Argo CD can resume from Git. Done means every component pod is running across separate nodes and a test sync completes after a pod restart.
Configure SSO and disable the admin user
Connect Argo CD to your identity provider, either through the bundled Dex connectors or directly through an existing OIDC provider, so that every human action maps to a named identity. Once local users or SSO work, set admin.enabled to false, as the user management documentation recommends for the built-in admin account. Done means a reviewer can log in only through SSO, and an attempt to use the admin account is refused.
Define projects and RBAC under 3.0 rules
The security team defines AppProjects per team and per environment, limiting source repositories, destination clusters and namespaces. Write RBAC policies that follow the 3.0 rules: update and delete apply only to the application itself, and logs access requires an explicit logs, get permission. For Dex-based mappings, use the federated_claims.user_id claim. Done means a test user in one project cannot sync or view applications in another, and the policy files are stored in Git for review.
Store repository credentials as Secrets
Register each Git repository and Helm or OCI source as a Kubernetes Secret, because Argo CD 3.0 removed repository configuration from the argocd-cm ConfigMap. Limit which repositories each project can use, and review the list of approved sources against your baseline. Done means the repository list is reproducible from manifests, and no repository appears in the ConfigMap.
Pin the baseline and restrict repo-server inputs
Record the approved baseline in Git: the Argo CD manifests, the project definitions and the application paths that define each workload. Because the repo-server runs Helm and Kustomize on repository content, confirm that only trusted repositories are allowed and that out-of-tree file access is restricted as the security documentation describes. Done means a reviewer can diff the live Argo CD configuration against the Git baseline and find no unexplained differences.
Enable drift and sync monitoring
Turn on automated sync only where the change process allows it, and keep self-heal on for applications where unexpected manual changes must be reverted. Export sync history and Kubernetes events to your logging or SIEM platform, and set alerts for OutOfSync states that persist and for syncs that fail. Ask the vendor or your own tests to confirm how each alert and event is retained in your environment. Done means a deliberate manual change to a test workload produces a visible drift record and an alert.
Schedule an upgrade review against release notes
Set up a standing review that checks each new Argo CD minor and patch release against the upgrade notes before it reaches production. The release process states that only the three most recent minor versions receive patches, so confirm which minor line you run and plan moves before it falls out of support. Review the default settings the new release changes, such as resource tracking, and record the decisions in Git. Done means each upgrade has a signed-off review record that lists the defaults checked and the changes accepted.

Reviewing defaults when Argo CD is installed or upgraded

A new installation starts from the upstream defaults, so the first review is a record of what the installation actually does before any team uses it. Capture the effective configuration in Git and compare it against your approved baseline, rather than relying on memory of the install guide. Confirm the settings that most often decide who can change running workloads.

Admin account: Confirm that the built-in admin user is used only for initial setup and that admin.enabled is set to false once local users or SSO are configured.
Authentication path: Record whether SSO runs through the bundled Dex or directly through an existing OIDC provider, and confirm which login method is allowed.
RBAC policy: Review the default policy and confirm that application and project roles are scoped to the teams that need them.
Repository definitions: Confirm that repository credentials are defined as Kubernetes Secrets and that no repository settings sit in the argocd-cm ConfigMap.
Baseline capture: Store the reviewed values as the first approved baseline and record who approved it.

Before go-live, check that each default you accepted is recorded in the baseline with an owner and a date, so the first deviation monitoring has something to compare against.

The 2.14 to 3.0 upgrade changed several defaults that affect access and visibility, so it needs a dedicated review before the upgrade window. Read the upgrade notes against your existing configuration, then test each change in a non-production instance. Treat the changed behavior as a baseline change, with its own approval and record.

Application-scoped update and delete: Update and delete RBAC now apply only to the application itself, so policies that relied on broader permissions need to be rewritten and retested.
Logs access: Pod logs require an explicit logs, get permission, so confirm which roles need it and remove it from roles that do not.
Annotation-based tracking: Annotation-based resource tracking is the default, so confirm how existing resources are tracked and that ownership is not ambiguous after the change.
Repository configuration move: Repositories must be defined as Kubernetes Secrets because the argocd-cm repository configuration was removed, so migrate and verify every repository entry.
Dex claim change: Dex-based RBAC now uses the federated_claims.user_id claim, so test group and user mappings with real test identities.

After the upgrade, compare the live RBAC and repository settings against the pre-upgrade baseline and record every intended difference as an approved change.

What Argo CD does not cover for PR.PS-01

Argo CD enforces and records what is declared in Git, but PR.PS-01 covers the whole configuration lifecycle. The cards below name the areas that sit outside Argo CD and that your organization must define, own and evidence itself.

Baseline content

Argo CD does not define your hardening. It applies the manifests you give it, so a baseline is only as strong as the settings written into those files. Confirm who authors the baseline, which benchmark or internal standard it follows, and how each setting traces back to an essential-capability decision. Review the baseline itself, not just the diffs that change it.

Software outside Argo CD manifests

Anything installed by hand, by a script, or by a tool that does not reconcile through Argo CD falls outside its drift detection. Inventory the packages, agents and controllers on each cluster and node, then decide which ones must be declared in Git. Confirm that the inventory is compared against the approved baseline on a schedule.

Node and operating system configuration

Argo CD reconciles Kubernetes objects, not the kernel, OS packages, SSH settings or the cluster control plane hosts beneath them. Those layers need their own baseline, change process and drift monitoring, usually handled by your platform or infrastructure team. Confirm which tool owns each layer and where its records are kept.

Vulnerability and patch decisions

Argo CD helps you deploy an upgrade, but it does not decide which fix is urgent or whether a release is acceptable. Patch selection, risk acceptance and timing belong to your vulnerability management process. Confirm which Argo CD minor lines you support and who approves moving to a patched release.

Approval policy and separation of duties

Pull request reviews and project roles are only as strong as the policy behind them. Who may approve a change to production, whether authors may approve their own work, and how emergency changes are handled are decisions made outside Git. Confirm that these rules exist in writing and match the repository protections and RBAC actually configured.

Retention and the policy text

Argo CD keeps history only as long as its Kubernetes objects and your logging pipeline allow. How long Git history, sync records and audit logs must be kept is a retention decision you must set and implement elsewhere. Confirm the retention period with your compliance lead, and write the configuration management policy that names owners, review intervals and exceptions.

Questions buyers ask before hiring help for PR.PS-01

What drives the cost of an Argo CD configuration management engagement for PR.PS-01?

The cost follows the scope you agree in writing, so the main drivers are how many clusters and applications Argo CD manages, how many baselines you need to declare, and how much of your current change process must be documented. Expect one-time work to cover the Git repository layout, Projects, RBAC mapping, sync policy decisions, baseline definitions and the monitoring setup. Recurring costs appear when you add support, upgrades or continuous testing, which are available as retainers. Ask any quote to separate one-time build effort from recurring operations, to name who performs each task, and to list the environments and clusters in scope. DeployOpen does not publish a price list, so a quote comes from the written scope.

How long does it take to put Argo CD baselines under PR.PS-01 in place?

Duration depends on how many clusters you run, how far your current configuration is from being declared in Git, and how quickly your reviewers can approve the baselines. Work usually starts with an inventory of existing Argo CD installations and the configuration that is applied by hand today, because that inventory sets the size of the rest of the plan. Ask the proposal to state milestones and dependencies, including when your security and platform owners must sign off. No duration is given here because none is supplied for this topic, so request a timeline tied to the written scope.

What does the client team need to provide for this work?

You need to provide named owners who can make decisions about baselines, access and approvals, plus read access to the Argo CD instances, Git repositories and clusters in scope. Your team should also provide the current hardening standard or internal baseline, if one exists, and the change approval rules that auditors will ask about. Expect to supply a window for the first upgrade review, since PR.PS-01 expects defaults to be checked when software is installed or upgraded. Confirm these inputs in the written scope so that delays in access or approvals are not billed as unplanned work.

Can our own platform team implement PR.PS-01 for Argo CD without a partner?

Yes, if your team has the Kubernetes, Git and identity skills to declare baselines and enforce them. Internal teams often handle the parts that depend on daily context, such as which applications change and who approves them. External help is most useful for the first design, the RBAC and SSO mapping, the upgrade review process and the evidence layout, because those decisions shape the audit trail for years. Compare the internal effort with the written scope before you decide. Ask yourself whether anyone on your team has already read the Argo CD upgrade notes for the major versions you plan to run.

Does DeployOpen's work replace an audit against NIST CSF 2.0?

No. DeployOpen plans, implements, documents and supports the controls, and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. NIST also states that it does not offer certifications or endorsements of CSF-related products, implementations or services. Any assessment of your CSF profile or of your SP 800-53 controls is performed by your own assessors or independent auditors. Ask a partner to show which records will exist for an assessor to sample, and who is responsible for keeping them current after the engagement ends.

What should a written scope for PR.PS-01 Argo CD work include?

A useful scope names the clusters, Argo CD instances and Git repositories in scope, and the baselines to be declared in Git. It should list the deliverables, such as the repository structure, Projects and RBAC definitions, the procedure for reviewing defaults on each upgrade, and the method for detecting deviation from approved baselines. Ask for the SP 800-53 CM controls and the CSF subcategory that each deliverable supports, so that you can map evidence to requirements. The scope should also state what is excluded, how acceptance works and what support is included after handover.

How does Argo CD version support affect the work and its upkeep?

Upkeep depends on the Argo CD release cadence. The release process states that a minor release ships four times a year, and only the three most recent minor versions receive patch releases, so your running version determines how often you must review defaults and apply patches. Major upgrades need their own review, because the 2.14 to 3.0 notes changed RBAC for update and delete actions, logs access and resource tracking, and removed repository configuration from argocd-cm. Ask the partner to include a repeatable upgrade review in the scope, with a named owner and a retained record for each version change.

Is there a per-user license or subscription fee for Argo CD itself?

Argo CD is released under the Apache License 2.0, and the Argo project offers no paid edition, so the software itself carries no project license fee. Costs you should expect instead are the infrastructure to run Argo CD, the people who operate it, the identity provider you connect it to and any external services you choose. Confirm with your procurement team whether a vendor you use for hosting, identity or support has its own licensing terms. The quote from a partner covers implementation and support effort, not the license of the open-source software.

What NIST CSF 2.0 does and does not certify

NIST does not certify Argo CD, your implementation of it, or your organization against the Cybersecurity Framework. NIST states that it offers no certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. Nothing in this page therefore counts as a certified configuration, and no vendor or partner can sell you a CSF certificate on NIST's behalf. What you can show is evidence that your practices match the PR.PS-01 outcome, and whether a given party accepts that evidence is a decision for that party.

The framework is voluntary for most organizations. NIST is not a regulator, and most organizations adopt the CSF because it is useful or because a customer or supplier asks for it. A 2017 executive order made it mandatory for U.S. federal agencies, so a federal customer may set expectations that a commercial company does not face. Before you build evidence around PR.PS-01, confirm in writing with each customer, regulator or contracting office which profile, tier and evidence format they expect. Ask whether they want your own self-assessment, a statement from an independent assessor, or a mapping to another framework such as SP 800-53 or ISO/IEC 27001.

PR.PS-01 is also described through *Implementation Examples*, which NIST publishes online rather than in the CSWP 29 framework document, so NIST can revise them without reissuing the framework. Check the current examples in NIST's CSF 2.0 Reference Tool export before you cite them, and record the date you checked. Treat the examples as guidance for designing your baseline and monitoring, not as a checklist that Argo CD passes or fails. Independent auditors and certification bodies, not DeployOpen or NIST, decide whether your evidence is sufficient for a particular engagement.

How DeployOpen scopes and delivers PR.PS-01 configuration and evidence

DeployOpen plans, builds and hands over Argo CD for NIST CSF 2.0 configuration management inside infrastructure you control. The work ties the Git baseline, RBAC, sync controls and deviation monitoring to the PR.PS-01 outcome, so your team can show how configuration is set up and applied.

How we scope

Each engagement starts with a written scope that names the clusters, Argo CD projects and baseline repositories in play.
We confirm which PR.PS-01 implementation examples and SP 800-53 CM controls your assessor will test against.
Scope documents which Argo CD version and upgrade cadence you will follow, and who owns each baseline change.

How we build

We declare hardened baselines in Git, then configure SSO, admin disablement and project boundaries as reviewed code.
We set up repository credentials as Kubernetes Secrets and test that sync and RBAC behave as the written baseline describes.
We build deviation monitoring and sync history checks, and test them against deliberate out-of-baseline changes.

How we hand over

You receive the baseline repository, configuration documentation and a written record of defaults reviewed at each upgrade.
Handover covers the evidence map from PR.PS-01 and CM controls to the Git history, sync records and monitoring outputs.
Your team gets runbooks for reviewing drift alerts, approving baseline updates and reverting a deviation through Git.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Retainers can cover reviewing default settings for each Argo CD patch or minor release you adopt.
We prepare systems and evidence for your assessments, while independent auditors and certification bodies issue any formal findings.

Argo CD for NIST CSF 2.0 configuration management (PR.PS-01)