Least Functionality | Authorized Software — Allow-by-Exception

CM-7(5) requires you to run an allow-by-exception software execution model: define which software is authorized to run, block everything else by default, and regularly review and update the authorized software list. To operationalize it, you need enforceable technical controls (not just policy), a governed exception process, and evidence that the control works across your FedRAMP boundary. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• You must implement “deny-all, permit-by-exception” for software execution, not just document intent. (NIST Special Publication 800-53 Revision 5)
• Your authorized software list is a controlled configuration item: defined ownership, change control, and scheduled review. (NIST Special Publication 800-53 Revision 5)
• Exceptions must be time-bound, risk-accepted, and traceable to technical enforcement and monitoring outcomes.

“Least Functionality | Authorized Software — Allow-by-Exception” (NIST SP 800-53 Rev. 5 CM-7(5)) is the practical requirement behind application allowlisting. The control is blunt on purpose: you decide what software may execute, you block everything else, and you keep that decision current through a defined review cadence. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an operating model that spans governance, endpoint/server engineering, and change management. Auditors will look for three things: (1) a clearly scoped “system” boundary where the rule applies, (2) a technical enforcement mechanism that defaults to deny, and (3) durable evidence that your authorized list is maintained and actually drives what can run. (NIST Special Publication 800-53 Revision 5)

This page gives you requirement-level implementation guidance you can hand to engineering and still own as a compliance artifact: what “authorized software” means in practice, how to run exceptions without turning the control into a rubber stamp, what artifacts to retain, and what usually breaks during assessment.

Regulatory text

Requirement (CM-7(5)): “Identify organization-defined software programs authorized to execute on the system; employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and review and update the list of authorized software programs at an organization-defined frequency.” (NIST Special Publication 800-53 Revision 5)

Operator translation: what you must do

1. Identify authorized software: Define, in a controlled list, the software programs permitted to execute within the system boundary. (NIST Special Publication 800-53 Revision 5)
2. Enforce deny-all by default: Put a technical control in place so execution is blocked unless the software matches an approved allow rule (publisher, hash, path, signing certificate, package identity, etc.). (NIST Special Publication 800-53 Revision 5)
3. Review and update on a defined cadence: Set a frequency, assign an owner, and prove the list is reviewed and updated as the environment changes. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what “allow-by-exception” actually means)

“Allow-by-exception” means you do not rely on users or admins to “do the right thing.” The system enforces a default block on execution, and only software explicitly authorized is allowed to run. In practice, this typically maps to:

• Servers: strict allowlisting for production hosts, build systems, and administrative jump hosts.
• Endpoints: allowlisting for privileged users and high-impact roles, or for all endpoints if your environment supports it.
• Containers and managed services: allowlisting through image admission policies, signed artifacts, and runtime controls (the requirement is about what executes, not only what is installed).

The hardest part is scoping and operational friction: you need a mechanism to add legitimate software quickly without letting “temporary” exceptions become permanent.

Who it applies to (entity and operational context)

Applies to:

• Federal agencies operating information systems that must meet NIST SP 800-53 requirements. (NIST Special Publication 800-53 Revision 5)
• Cloud Service Providers supporting FedRAMP-authorized services, across the defined authorization boundary. (NIST Special Publication 800-53 Revision 5)

Operational contexts where assessors focus

• Production workloads: application servers, databases, and supporting services inside the boundary.
• Privileged administration: bastion/jump hosts, break-glass accounts, admin workstations.
• Build and deployment paths: CI/CD runners, code signing, artifact repositories, configuration management nodes.
• Third-party software: remote support tools, security agents, monitoring agents, database clients, and “helper” utilities that admins install ad hoc.

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

Step 1: Define scope and ownership

• Define the “system” boundary where you will enforce allow-by-exception (FedRAMP boundary, enclaves, segmented networks).
• Assign ownership of the authorized software list to a control owner (often Security Engineering) with a named backup.
• Define what counts as “software programs” in your environment: executables, scripts, installers, interpreters, packaged apps, container images, and admin tools.

Deliverable: a short control implementation statement that ties enforcement to the system boundary and identifies the authoritative list. (NIST Special Publication 800-53 Revision 5)

Step 2: Build the authorized software baseline

Create a baseline list that is realistic enough to run production, but strict enough to be meaningful.

• Start from gold images and standard build templates.
• Include security tooling (EDR agents, log forwarders), platform agents, and approved admin tools.
• Document authorization logic per item:
  • Name, versioning approach (pinned vs range), publisher/signing identity, and approved source.
  • Where it is allowed (all hosts vs specific tiers).
  • Business purpose and owner.

Tip from practice: your baseline fails if it doesn’t include “operational glue” (shells, package managers, scripting runtimes). Decide explicitly which are permitted and where.

Step 3: Implement technical enforcement (deny-all, permit-by-exception)

Auditors will not accept a spreadsheet alone. You need a control that enforces execution policy. (NIST Special Publication 800-53 Revision 5)

A practical approach:

• Choose the enforcement plane per asset class:
  • Endpoints: application control / allowlisting tooling.
  • Servers: host-based allowlisting, immutable images, or configuration enforcement that prevents unapproved binaries from being present and executable.
  • Containers: restrict runnable images to approved registries and signed images; restrict runtime privileges.
• Define allow rules that minimize admin overhead:
  • Prefer publisher/certificate-based rules where feasible.
  • Use hash rules for high-risk binaries or when publisher identity is unavailable.
  • Avoid broad path-based rules unless the path is tightly controlled and write-protected.

Minimum expectation: unknown binaries and scripts fail to execute by default, and you can show that behavior during testing.

Step 4: Stand up an exception process that doesn’t weaken the control

“Permit-by-exception” is a permissioning workflow with guardrails, not informal approvals.

• Intake: requestor, business need, target systems, timeframe, and software identity attributes.
• Review: security review for risk and alternatives; validate software source and integrity.
• Approval: documented risk acceptance when needed; scope restriction (only certain hosts/users).
• Implementation: add allow rule; push via configuration management.
• Expiration: exception end date and revalidation trigger; remove rules when no longer needed.

If you use Daydream to manage third-party and internal software exceptions, set it up so each exception record maps to (a) a change ticket, (b) the allow rule artifact, and (c) the post-implementation verification evidence. That linkage is what makes the workflow auditable under CM-7(5). (NIST Special Publication 800-53 Revision 5)

Step 5: Review and update the authorized software list on your defined frequency

CM-7(5) explicitly requires a review/update cadence. (NIST Special Publication 800-53 Revision 5) Your frequency should match change velocity and risk tolerance, but it must be:

• Defined (written down),
• Executed (calendar evidence),
• Actionable (adds/removes/adjusts allow rules),
• Traceable (who reviewed, what changed, why).

Review inputs to include:

• New software requests and exception backlog
• Asset inventory changes (new images, new host pools)
• EDR/monitoring detections of blocked executions
• Patch and upgrade cycles that change signed binaries or package identities

Step 6: Monitor, test, and prove it works

Operational proof beats policy language.

• Capture allowlisting events (blocked execution attempts, policy updates).
• Perform periodic tests: attempt to run an unapproved binary in a controlled way on representative hosts; record outcomes.
• Track drift: systems not receiving policy updates, hosts in “audit-only” mode, or enforcement disabled for troubleshooting.

Required evidence and artifacts to retain

Keep artifacts in a form an assessor can follow end-to-end:

Governance artifacts

• Authorized software policy/standard stating deny-all, permit-by-exception and the review frequency. (NIST Special Publication 800-53 Revision 5)
• RACI for list ownership, approvals, and emergency changes.
• Defined system boundary statement for where enforcement applies.

Operational artifacts

• Authorized software inventory/list (with approval metadata and scope).
• Allowlisting configuration exports (rules, policies, assignments).
• Exception records: request, review notes, approval, implementation date, expiration, closure.
• Change management tickets for policy/rule changes.

Verification artifacts

• Logs showing blocked execution attempts and successful allowed executions (samples are fine if properly scoped).
• Evidence of periodic review: meeting notes, tickets created/closed, diffs of authorized list across review cycles.
• Test records demonstrating deny-by-default behavior.

Common exam/audit questions and hangups

1. “Show me the mechanism that enforces deny-by-default.” Expect a live demo or configuration export, not a narrative. (NIST Special Publication 800-53 Revision 5)
2. “What is your authoritative authorized software list?” Assessors dislike multiple conflicting lists across teams.
3. “How do you handle scripts and interpreters?” If PowerShell/Python/bash exists, auditors may ask how you prevent arbitrary code execution.
4. “How do exceptions expire?” If you can’t show removal, exceptions will look permanent.
5. “What is your review frequency, and prove it happened?” The requirement demands both definition and execution. (NIST Special Publication 800-53 Revision 5)

Frequent implementation mistakes (and how to avoid them)

• Mistake: “We inventory software” instead of “we block execution.” Fix: confirm the control is enforced and not only detected. (NIST Special Publication 800-53 Revision 5)
• Mistake: Allow rules too broad. Example: allowing all executables in a user-writable directory. Fix: constrain by publisher/signing identity or locked-down paths.
• Mistake: Exceptions without expirations. Fix: require an end date, and automate reminders and removal workflows.
• Mistake: Split-brain ownership. Fix: one authoritative list with clear intake and change control; teams can propose, one owner approves and publishes.
• Mistake: “Audit mode forever.” Fix: set criteria to move systems from observe to enforce; track waivers explicitly as exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk perspective, CM-7(5) reduces the execution paths for malware, unauthorized remote tools, and admin “convenience” utilities that expand your attack surface. It also forces discipline in third-party software onboarding: if a third party tool must run, it must be explicitly approved, scoped, and reviewable. (NIST Special Publication 800-53 Revision 5)

Practical execution plan (30/60/90)

The requirement needs a defined review frequency, but the implementation ramp can be staged.

First 30 days (Immediate)

• Confirm the in-scope boundary and asset categories for enforcement.
• Draft the authorized software standard: deny-all/permit-by-exception, ownership, and review cadence. (NIST Special Publication 800-53 Revision 5)
• Build the initial authorized software baseline from images and current operational needs.
• Stand up an exception intake path tied to change management (Daydream can act as the system of record for exceptions and third-party software approvals).

By 60 days (Near-term)

• Deploy enforcement in a pilot segment (admin jump hosts and a small server pool are common starting points).
• Convert baseline list into real allow rules; validate deny-by-default with controlled tests.
• Operationalize logging: collect allow/deny events and exception changes in your SIEM.
• Start the first formal review cycle; record what changed and why. (NIST Special Publication 800-53 Revision 5)

By 90 days (Ongoing operating model)

• Expand enforcement coverage to the remaining in-scope systems in phases based on operational risk.
• Tighten allow rules (publisher-based where possible; remove broad paths).
• Normalize exception expirations and closure, and track recurring exception themes as backlog items (often points to missing baseline entries or needed engineering work).
• Run the recurring review cycle on schedule and keep the evidence package current. (NIST Special Publication 800-53 Revision 5)

Frequently Asked Questions

Does CM-7(5) require a specific allowlisting product?

No. The requirement is outcome-based: identify authorized software, block everything else by default, and review/update the list on a defined frequency. (NIST Special Publication 800-53 Revision 5)

Can we meet this with an inventory tool and EDR detections?

Inventory and detection help, but CM-7(5) explicitly requires a deny-all, permit-by-exception execution policy. You need a control that prevents execution of unauthorized software, not only alerts on it. (NIST Special Publication 800-53 Revision 5)

What counts as “authorized software programs” in a modern environment with containers?

Treat anything that can execute code as in-scope: host binaries, scripts, and container images. For containers, your “authorized list” often maps to approved images and registries, backed by admission/runtime restrictions.

How do we handle emergency fixes where engineers need a new tool immediately?

Create an emergency exception path with fast approvals, narrow scope, and a short expiration. Document the reason, who approved, and remove or formalize it during the next review cycle. (NIST Special Publication 800-53 Revision 5)

How often do we need to review the authorized software list?

CM-7(5) requires an organization-defined frequency, so you must set one and follow it. Pick a cadence that matches your change rate, then retain evidence that reviews happened and resulted in updates. (NIST Special Publication 800-53 Revision 5)

What evidence is most persuasive to an assessor?

A clear authoritative list, the enforceable policy/rules exported from the control, exception tickets tied to changes, and logs or test results showing unauthorized software is blocked. That package maps directly to the three CM-7(5) clauses. (NIST Special Publication 800-53 Revision 5)