Application Execution Policy

Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.8.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   a policy specifying whether whitelisting or blacklisting is to be implemented is specified;

   1 example covers this

2. [b]

   the software allowed to execute under whitelisting or denied use under blacklisting is specified; and

   1 example covers this

3. [c]

   whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c]

  CM.L2-3.4.8 · Application Execution Policy

  Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.

  • [a]

    a policy specifying whether whitelisting or blacklisting is to be implemented is specified;

  • [b]

    the software allowed to execute under whitelisting or denied use under blacklisting is specified; and

  • [c]

    whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.

  Deny-all, permit-by-exception on CUI endpoints after 60 days in audit mode

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Addresses all three Application Execution Policy objectives: the policy choice is specified [a], the software allowed to execute is specified [b], and allow-listing is implemented as specified [c].

  Policy choice [a]. The written policy selects deny-all, permit-by-exception (allow-listing) for endpoints that can access CUI, with the rationale recorded: a deny list cannot keep up with tooling that changes weekly. Devices outside the CUI scope run a lighter deny-by-exception posture, and the boundary between the two is stated so nobody assumes the stricter policy is everywhere.

  What is allowed [b]. The allow-list is expressed as rules in priority order: software installed by the managed installer (endpoint management) is trusted by provenance; specified publisher certificates are trusted for the engineering toolchain; internal scripts must be signed by our code-signing certificate; a short list of hash rules covers unsigned utilities that have no signed equivalent, each with an owner and a review date so the list does not become permanent by neglect. Anything else is denied, including binaries in user-writable paths, which closes the obvious bypass.

  Implementation [c]. The policy ran in audit mode for 60 days first. Audit events were reviewed weekly and produced roughly 40 additions and, more usefully, a list of tools nobody could justify. Enforcement was then enabled ring by ring. The legacy ring — six devices with older imaging — uses the older application control mechanism at equivalent strictness until they are replaced; that difference is documented rather than described as one uniform control.

  Handling the friction. A blocked-execution event gives the user a message with a request link. Requests are triaged within one business day; the answer is often a signed alternative already on the list. This path is why the control survived rollout instead of being turned off after the first sprint.

  Maintenance. Weekly review of block events for both new-tool demand and genuine attempts. Quarterly review of hash rules, biased toward removal. Re-validation of the policy after each major OS feature update, since these mechanisms are sensitive to platform changes.

  Accepted gap. One CAD plug-in loads unsigned modules at runtime and cannot be allow-listed by publisher. Its directory is covered by a path rule that is writable only by administrators, not by the user, and directory contents are monitored for change — weaker than a signature rule, and recorded as such.

  What the evidence looks like

  • Written policy stating the allow-listing choice, its rationale, and its scope boundary
  • Policy export showing managed-installer, publisher, signature, and hash rules
  • Audit-mode review records and the resulting rule additions
  • Sample block event with the user request and its one-business-day resolution
  • Path rule permissions and change monitoring for the CAD plug-in exception

  Environment

  Windows 11 fleet for CUI users, ~90 devices. Engineers previously installed their own tooling freely, so a hard cutover was never going to survive contact.

  Tools

  • Windows Defender Application Control
  • AppLocker
  • MDM
  • Code signing

  Edit history

  · No edits yet