CM-2(5): Authorized Software

CM-2(5): Authorized Software requires you to define, approve, and enforce an “allowed software” baseline for in-scope systems, and to maintain evidence that only authorized software is installed and running. Operationalize it by establishing an authorization workflow, implementing technical allowlisting controls, continuously monitoring for drift, and retaining audit-ready records of approvals and exceptions. ¹

Key takeaways:

• Maintain a current authorized software list tied to system baselines and change control. ¹
• Enforce authorization with technical controls (allowlisting where feasible) and detect unauthorized installs fast. ¹
• Keep evidence: approvals, inventories, exception records, and monitoring outputs mapped to owners and cadence. ²

The cm-2(5): authorized software requirement is a configuration management expectation: software running in production should be there because you approved it, not because a user had admin rights or a deployment pipeline pulled in a new dependency by default. For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat “authorized software” as a governed baseline plus enforcement, not as a one-time inventory exercise.

In practice, assessors look for three things: (1) a defined policy and standard for what “authorized” means in your environment, (2) technical controls that prevent or rapidly detect unauthorized software, and (3) repeatable evidence that the process operates across endpoints, servers, and cloud workloads. CM-2(5) often fails on evidence and scope boundaries: teams can describe how approvals “should” work, but cannot show approvals, exceptions, and monitoring results tied to the systems in scope.

This page translates CM-2(5) into concrete operational steps, artifacts to retain, common audit traps, and a staged execution plan you can run through with IT, Security Operations, and platform owners.

Regulatory text

Control requirement: “NIST SP 800-53 control CM-2.5.” ²

Operator interpretation of what you must do: CM-2(5): Authorized Software is an enhancement under configuration management. You are expected to (a) define which software is permitted on a system (the authorized baseline), (b) ensure software installations/updates follow an approval path, and (c) enforce or monitor to prevent/identify unauthorized software. Your implementation must be provable with records that show the authorized list, the approval and exception workflow, and outputs from monitoring or enforcement. ¹

Plain-English interpretation

• “Authorized” means you have an explicit decision record that a software title (and, for higher-risk categories, a version range or package identity) is allowed for a specific environment. ¹
• You need a mechanism that makes unauthorized software hard to introduce and easy to catch. That can be allowlisting, controlled admin rights, packaging via managed software distribution, container image admission policies, or other enforceable gates depending on platform. ¹
• Evidence matters as much as intent. If you cannot show approval tickets, exception sign-offs, and monitoring reports, you will struggle to demonstrate operation of the control. ²

Who it applies to

Entities

• Federal information systems and organizations implementing NIST SP 800-53. ¹
• Contractors and service providers operating systems that handle federal data, where NIST 800-53 is flowed down contractually or used for an authorization boundary. ¹

Operational scope (what systems) Apply CM-2(5) to any environment where unauthorized software meaningfully increases risk: employee endpoints, privileged admin workstations, production servers, build agents, container platforms, and managed SaaS connectors where “apps” or “integrations” can be installed. Define your boundary in the system security plan (or equivalent) so auditors do not decide scope for you. ¹

What you actually need to do (step-by-step)

1) Set the governance rule for “authorized”

Create an “Authorized Software Standard” that answers:

• What categories require explicit authorization (examples: remote access tools, admin tools, scripting runtimes, database clients, browser extensions, IDEs, agents, container base images).
• The approval authority by category (Security, IT, platform owner, data owner).
• Minimum evaluation criteria (license legitimacy, supplier reputation, update mechanism, logging capability, support status).
• Where authorization is recorded (ticketing system, GRC tool, CMDB record). ¹

Operator tip: Write the standard so it can be executed. A short decision tree beats a long narrative.

2) Build the authorized software list (ASL) as a living baseline

Stand up an ASL with these fields:

• Software name, publisher, purpose, approved environments (endpoint/server/cloud), approved version policy (pinned or range), approving role, approval date, review trigger, and deprecation date.
• Mapping to the system baseline configuration (gold images, endpoint profiles, container base images, approved marketplace apps). ¹

Practical scoping move: Start with “high-risk software” plus “most installed software.” Then expand.

3) Tie authorization to change control

Make the ASL the gate for:

• New software requests (user request or engineering dependency request).
• Software updates that change major versions or introduce new capabilities (for example, a new kernel module, new browser extension permissions, new network listeners).
• Emergency installs with retroactive approval and a time-bound exception. ¹

Define a minimum workflow:

1. Request submitted (what software, where, why).
2. Security/IT review per category.
3. Approval recorded; ASL updated.
4. Deployment method assigned (MDM, package manager repo, golden image, container registry).
5. Post-install validation: inventory shows presence only on authorized assets. ¹

4) Enforce with technical controls (pick the right pattern per platform)

You do not need one tool for every environment, but you do need enforceable control coverage.

Endpoints (Windows/macOS)

• Prefer allowlisting for privileged/high-risk endpoints (admin workstations, finance). If full allowlisting is impractical, enforce “managed install only” for standard users and restrict admin rights.
• Use MDM/endpoint management to control app installs and extensions. ¹

Servers

• Build from hardened images; block ad-hoc installs by removing package manager access on production where feasible.
• Treat agents (monitoring, backup, EDR) as baseline components with controlled rollout. ¹

Containers/Kubernetes

• Control software via base image policy and admission controls (only approved registries, signed images if your program supports it).
• Track authorized images and packages in a registry inventory; require PR-based changes to Dockerfiles and lockfiles. ¹

SaaS and third-party integrations

• Maintain an “authorized integrations” list; route new connectors through risk review and least-privilege scopes.
• Disable user-installed apps where the platform supports admin control. ¹

5) Monitor continuously and reconcile drift

Implement a recurring comparison between “what’s installed/running” and “what’s authorized.”

• Data sources: endpoint inventory, EDR telemetry, server configuration scans, cloud workload inventories, SBOM/lockfile outputs for CI artifacts (where available).
• Define thresholds for action: unauthorized high-risk software triggers incident or containment; low-risk triggers ticket and removal timeline.
• Track remediation to closure with evidence (ticket links, uninstall logs, follow-up scan). ¹

6) Manage exceptions without weakening the control

Create an exception type for unauthorized software with:

• Business justification, risk owner approval, compensating controls, expiry date, and renewal criteria.
• Automated reminders and forced review on expiry.
• A requirement to add to ASL if it becomes standard. ¹

7) Assign ownership and evidence cadence (make it auditable)

CM-2(5) frequently fails on “who owns the list” and “how often it’s reviewed.” Set:

• Control owner (often IT Security or Configuration Management).
• ASL data steward (CMDB admin, endpoint engineering, or platform ops).
• Review trigger (new critical system, major platform change, supplier EOL) and a recurring review meeting. ²

Where Daydream fits: If your friction point is audit readiness, Daydream can help you map CM-2(5) to a named owner, a written procedure, and a predictable evidence bundle so you stop rebuilding proof every assessment cycle. ²

Required evidence and artifacts to retain

Keep artifacts that prove definition, approval, enforcement, and monitoring:

1. Authorized Software Standard (policy/standard document) and approval history.
2. Authorized Software List (ASL) export with fields, last updated timestamp, and owner.
3. Baseline configuration artifacts: golden image manifests, approved package repos, endpoint profiles, approved container base images.
4. Approval workflow records: tickets/changes showing request, review, approval, and deployment method.
5. Exception register: approvals, compensating controls, expiry, closure evidence.
6. Monitoring outputs: inventory scans, EDR app telemetry reports, drift reports, and remediation tickets.
7. Removal/containment evidence: uninstall logs, device quarantine records, follow-up scan results. ¹

Common exam/audit questions and hangups

Auditor question	What they want	What to show
“Define authorized software for this system.”	Clear rule and scope	Standard + system boundary statement 1
“How do you prevent unauthorized installs?”	Enforceable mechanism	Allowlisting/MDM controls, privilege restrictions, change gates 1
“How do you detect unauthorized software?”	Monitoring with action	Latest drift report + remediation tickets 1
“Show exceptions.”	Controlled deviations	Exception register with approvals and expiry 1
“Prove it works across asset classes.”	Coverage by scope	Evidence per endpoints, servers, cloud workloads 1

Frequent implementation mistakes and how to avoid them

1. Inventory without authorization. An app list is not an ASL. Add explicit approval fields and decision rights. ¹
2. ASL exists, but installs bypass it. If admin users can install anything, auditors will treat CM-2(5) as weak. Pair the ASL with privilege management and controlled deployment paths. ¹
3. No version strategy. “Chrome is allowed” is incomplete if a vulnerable version remains installed. Define version policy by risk category and patch process linkage. ¹
4. Exceptions become permanent. Exceptions need expiry and renewal discipline; otherwise your “authorized” baseline becomes meaningless. ¹
5. Evidence scattered and unreproducible. Centralize exports and reports so you can answer an assessor in hours, not weeks. ²

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog. Practically, CM-2(5) gaps show up during ATO assessments, third-party reviews, and incident postmortems where unauthorized tools (remote access, credential dumpers, unapproved agents) widen blast radius. Treat this as a breach-prevention and assessor-confidence control: it reduces unknown software risk and makes your environment explainable under scrutiny. ¹

A practical 30/60/90-day execution plan

Days 1–30: Establish control decisions and minimum viable ASL

• Name the control owner and the ASL steward; document scope boundaries for in-scope systems.
• Publish the Authorized Software Standard with category-based approvers.
• Generate an initial software inventory snapshot for endpoints and servers; classify high-risk titles.
• Stand up the ASL repository (GRC tool, CMDB table, or controlled spreadsheet with change history). ¹

Days 31–60: Connect approvals to operations and start enforcement

• Add an approval workflow in ticketing/change management; require ASL entry before deployment.
• Implement “managed install only” for standard users where possible; tighten admin rights for sensitive groups.
• Configure monitoring reports for unauthorized software detection; define response playbooks by severity.
• Create the exception register template and start migrating existing “known deviations” into it. ¹

Days 61–90: Prove operating effectiveness and scale coverage

• Run recurring drift reviews with IT/SecOps; remediate unauthorized installs and document closure.
• Expand coverage to cloud workloads and containers (approved registries/base images).
• Prepare an audit packet: policy, ASL export, sample approvals, monitoring reports, exception register, remediation samples.
• If evidence assembly is the bottleneck, implement Daydream-style mapping of owner, procedure, and recurring evidence outputs so audits follow a repeatable script. ²

Frequently Asked Questions

Do we need strict allowlisting to meet cm-2(5): authorized software requirement?

Not always, but you need an enforceable mechanism appropriate to the platform and risk. If you cannot block installs, you must at least detect unauthorized software quickly and show remediation records tied to approvals and exceptions. ¹

How detailed does the Authorized Software List need to be?

Detailed enough that an assessor can tell what is allowed, where it is allowed, and who approved it. For higher-risk software, include version policy and explicit environment scoping to prevent “approved on dev” from becoming “installed in prod.” ¹

Does CM-2(5) apply to browser extensions and SaaS integrations?

If extensions or integrations can execute code, access sensitive data, or change security posture, treat them as software for authorization purposes. Maintain an authorized list and control installation permissions where the platform supports it. ¹

How do we handle open-source libraries pulled in by CI/CD?

Treat dependency introduction as “software authorization” through engineering gates: approved registries, code review for dependency changes, and lockfile controls. Keep evidence through PR reviews, build logs, and approved base images. ¹

What evidence is most persuasive in an audit?

A current ASL export, a small set of completed approval tickets, one or more drift reports showing unauthorized detections, and the remediation tickets that closed them. Pair that with an exception register that shows expirations and reviews. ¹

Who should own CM-2(5) in a modern org?

Security usually owns the control, but endpoint engineering, server/platform ops, and cloud teams must own the technical enforcement points. Assign a single steward for the ASL so updates do not depend on informal knowledge. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON