CM-2(4): Unauthorized Software

CM-2(4) requires you to prevent, detect, and respond to unauthorized software by tying “what is allowed to run” to your system configuration baseline and enforcing it through technical controls and repeatable operations. Operationalize it by defining authorized software rules, blocking unapproved installs/executes, monitoring for drift, and retaining auditable evidence. ¹

Key takeaways:

• Maintain an authoritative allowlist (or defined authorization method) that maps to your configuration baseline and asset inventory.
• Enforce authorization with blocking controls plus monitoring and a documented exception workflow.
• Keep assessment-ready evidence: policy, baseline, allowlist records, detection logs, and remediation tickets. ¹

The cm-2(4): unauthorized software requirement is a configuration management control enhancement: your baseline cannot be “paper-only.” Auditors and assessors will look for a closed loop from (1) defined authorized software, to (2) enforcement that stops unauthorized software from being installed or executed, to (3) monitoring that detects drift and (4) response actions that restore the approved state.

For a CCO, GRC lead, or compliance officer, the practical goal is simple: prove that the organization can consistently keep endpoints, servers, and managed cloud images free of unapproved software, with clear ownership and evidence. This is especially relevant for contractor systems handling federal data and federal information systems, where assessors expect control objectives to be translated into operating procedures and recurring artifacts. ²

The fastest path to operationalization is to treat unauthorized software as a baseline deviation: define what’s permitted, block what isn’t, and document every exception with a time bound and compensating controls. Your program succeeds when Security and IT can answer, quickly and with logs, “what software is running, who approved it, and how do we know nothing unapproved slipped in?”

Regulatory text

Control: “NIST SP 800-53 control CM-2.4.” ¹

Operator interpretation: CM-2(4) is the “Unauthorized Software” enhancement under Configuration Baseline (CM-2). Practically, you must (a) define what software is authorized for the system (directly or by defined criteria), (b) prevent unauthorized software from being installed and/or executed, (c) detect unauthorized software when it appears, and (d) take action to remove it or formally approve it through change control. ¹

Because the provided excerpt is short, assessors typically evaluate CM-2(4) by looking for consistent implementation artifacts tied to your baseline and ongoing operations, not a single document. ²

Plain-English interpretation (what CM-2(4) means in practice)

Unauthorized software is any code on a managed asset that is not explicitly approved or does not meet your defined authorization rules. CM-2(4) expects you to make “authorized vs. unauthorized” enforceable, not subjective.

A workable interpretation for most environments:

• You maintain an approved software standard by platform (Windows, macOS, Linux, server roles, containers, golden images).
• You enforce it with a technical control (application allowlisting, endpoint management restrictions, package repository controls, or equivalent).
• You continuously monitor and reconcile actual installed/running software to the authorized set.
• You run a documented exception process for business-justified deviations, with time bounds and ownership. ¹

Who it applies to (entity and operational context)

Entity scope

• Federal information systems.
• Contractor systems handling federal data (including many systems supporting federal contracts). ²

Operational scope

• Corporate endpoints (laptops/desktops) under management.
• Servers (on-prem and cloud) including jump hosts and bastions.
• Virtual desktop environments.
• Managed container images and “golden” VM images where software is baked in.
• Third-party managed environments where you still have configuration responsibility; if a third party controls the stack, CM-2(4) becomes a shared responsibility requirement you must contractually and operationally verify.

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

1) Assign ownership and define the control boundary

• Control owner: usually Endpoint Engineering, IT Operations, or Security Engineering; GRC owns oversight and evidence quality.
• In-scope assets: define which asset classes must comply (endpoints, servers, images, ephemeral compute).
• Authorization method: choose the rule: strict allowlist, role-based approved catalogs, signed-only execution, or a hybrid mapped to risk tiers.

Deliverable: a one-page CM-2(4) operating statement that names the owner, in-scope assets, authorization approach, and enforcement tooling. ¹

2) Define “authorized software” in a way you can enforce

Build an Authorized Software Standard that includes:

• Approved software catalog ¹.
• Versioning rules (e.g., “current supported versions only” as a policy statement; define who decides support status).
• Prohibited categories (e.g., remote admin tools not managed by IT, unapproved browsers, unsigned binaries).
• Source-of-truth repositories (managed app store, internal package repo, approved SaaS marketplace).

Tie this to configuration baselines: “baseline for developer workstation,” “baseline for finance workstation,” “baseline for Windows server role X,” etc. ¹

3) Implement preventive enforcement (blocking where possible)

Pick controls appropriate to the platform:

• Endpoints: application control/allowlisting, device management policies restricting installs, standard user privileges, and controlled elevation.
• Servers: immutable infrastructure patterns, restricted package manager repositories, golden images, and change-controlled deployment pipelines.
• Cloud images/containers: image signing policies, approved base images, CI/CD gates that fail builds with unapproved packages.

Operational expectation: you can show that unauthorized software cannot be installed or executed on in-scope systems without triggering a block or an alert plus follow-up. ¹

4) Implement detection and reconciliation (monitoring for drift)

Even strong preventive controls have gaps (admin users, emergency changes, offline assets). Add:

• Software inventory collection (installed apps and, where possible, running processes).
• Alerts for new/unknown executables, hash changes, and unapproved publishers.
• Scheduled reconciliation jobs comparing inventory to the authorized catalog and exceptions list.

You need a repeatable review mechanism that results in tickets or tracked findings, not a dashboard that nobody works. ¹

5) Create an exceptions workflow that doesn’t turn into a backdoor

Define a lightweight but strict exception record:

• Business justification and requestor.
• Risk review and approver (Security for high-risk categories).
• Scope (assets/users) and expiration condition.
• Compensating controls (logging, isolation, restricted network access).
• Removal plan.

Assessors will test whether exceptions are time-bound and reviewed, and whether the exception list is reconciled with inventory. ¹

6) Build response and remediation runbooks

When unauthorized software is detected:

• Triage: confirm legitimacy (false positive vs. real install).
• Contain: isolate device if needed, revoke admin tokens, stop execution.
• Eradicate: uninstall/remove binaries, reimage if integrity is questionable.
• Root cause: how did it get installed, and what control failed.
• Document: ticket, timestamps, evidence, and closure criteria.

7) Make it assessable: map to procedures and recurring evidence

This is where many teams fail CM-2(4): controls exist, but nobody can prove operation. Create an evidence map that tells an assessor exactly what to pull each month/quarter. Daydream can help by turning CM-2(4) into a control card with an owner, procedure, and “what evidence do we retain” checklist that stays current as tooling changes. ¹

Required evidence and artifacts to retain

Keep artifacts that show design and operation:

Design artifacts

• CM-2(4) policy/standard section defining unauthorized software and enforcement expectations. ¹
• Configuration baseline documents per system/asset class, referencing approved software rules. ¹
• Authorized software catalog (allowlist, approved app store list, approved repositories).
• Exception procedure and approval matrix.

Operational evidence

• Tool configuration screenshots/exports showing enforcement settings (application control rules, MDM restrictions, repo allowlists).
• Sample blocked events or alerts for unauthorized installs/executes.
• Software inventory exports and reconciliation reports.
• Tickets showing detection → triage → removal/approval with timestamps and approvals.
• Exception register with expirations and reviews. ¹

Common exam/audit questions and hangups

Expect these:

• “Show me your authorized software list. Who approves changes to it?” ¹
• “Demonstrate enforcement on an endpoint and a server. What happens if I try to run an unapproved executable?”
• “How do you handle developers who need tools that aren’t in the catalog?”
• “How do you detect unauthorized software on devices that are offline or rarely connect?”
• “Provide evidence for a sample of alerts and how they were resolved.”
• “How do you ensure third-party managed endpoints meet your standard, or how do you constrain what they can install?”

Hangup to plan for: auditors often reject “we scan occasionally” if you cannot show a control that prevents or promptly remediates unauthorized software and ties back to the baseline. ²

Frequent implementation mistakes (and how to avoid them)

1. Allowlist exists, but it’s not authoritative.
   Fix: publish a single system-of-record (catalog + exceptions) and require procurement/ITSM intake to route through it.

2. No enforcement on privileged users.
   Fix: tighten local admin, use just-in-time elevation, and enforce application control even for admins where feasible.

3. Exceptions never expire.
   Fix: require expirations and a monthly/quarterly exception review, and auto-create tickets for renewals.

4. Inventory doesn’t match reality.
   Fix: validate inventory coverage (all assets, all OS types), and reconcile with asset management.

5. Servers are treated as “special” and excluded.
   Fix: define server baselines by role and use immutable builds or repo restrictions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-2(4). The risk is still concrete: unauthorized software is a common path for malware, credential theft tooling, unapproved remote access, and shadow IT. From a compliance standpoint, weak CM-2(4) usually appears as “inability to maintain a configuration baseline,” which cascades into findings across vulnerability management, incident response, and access control. ²

A practical 30/60/90-day execution plan

Exact timelines depend on asset count and tooling maturity; use phases below to drive execution without overpromising dates.

Immediate (stabilize scope and rules)

• Name control owner and define in-scope asset classes. ¹
• Draft authorized software standard and prohibited categories.
• Stand up an exception register and approval workflow in your ticketing system.
• Identify current enforcement points (MDM, EDR, app control, CI/CD gates).

Near-term (enforce and produce evidence)

• Implement or tighten install/execute restrictions on endpoints first (highest change rate).
• Restrict software sources (app stores, package repos) and remove unmanaged install paths.
• Turn on monitoring with actionable alert routing and SLAs owned by a team.
• Run the first reconciliation cycle and produce a remediation report with tickets.

Ongoing (operate like a control, not a project)

• Monthly/quarterly evidence pulls: allowlist changes, exception reviews, sample alert closures.
• Add servers, golden images, and container pipelines to the same authorization model.
• Review drift trends and refine baselines to reduce noise without widening exceptions. ²

Frequently Asked Questions

Does CM-2(4) require application allowlisting?

The control enhancement is about unauthorized software; allowlisting is a common way to enforce it, but you can meet the intent with other enforceable authorization methods tied to your baseline. Your assessor will still expect prevention or rapid detection with documented response. ¹

How do we handle developers who need to install tools frequently?

Use a developer baseline with a broader approved catalog plus a fast exception workflow with expirations. Keep the rule: installs come from approved sources, and high-risk tools require Security approval. ²

What counts as “unauthorized software” in SaaS-heavy environments?

For CM-2(4), focus on software executing on managed assets and in managed images; SaaS access is usually handled through access control and third-party risk controls. If SaaS includes local agents or plugins, treat those as software subject to authorization. ²

Are browser extensions covered?

Treat extensions as software if they execute code in the browser and can access sensitive data. Enforce via managed browser policies and include extension rules in the authorized software standard. ²

What evidence is “enough” for an assessment?

Aim to show the chain: baseline/standard, enforcement configuration, inventory or monitoring output, and a few complete remediation examples with approvals and timestamps. If Daydream is your GRC system of record, map CM-2(4) to an owner, procedure, and recurring evidence checklist so pulls are consistent each cycle. ¹

How do we apply CM-2(4) to third-party managed endpoints or IT outsourcing?

Treat it as a shared responsibility requirement: contractually require controls, obtain periodic evidence (reports, configurations, exception lists), and constrain installs through your identity/device management where possible. Document the boundary and the verification method. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5