Most blocking controls ship with an audit mode, and many of them never leave it, so the organisation pays for a control that only writes logs. Application control, attack surface reduction rules, Content Security Policy, Kubernetes admission policies and web application firewalls all let you observe what a policy would block before you let it block. That staging step is essential, but audit mode is a temporary state with a cost, not a safe resting place. This guide compares the two modes across those five control families, sets out exit criteria for moving to enforcement, and explains the risks of staying in audit. It is for endpoint, platform and application security engineers who own a rollout, and for the managers who have to sign off the switch.
Key takeaways
- Audit mode measures, enforcement mode protects. In audit the control evaluates every event and records what it would have done, but the attack still succeeds.
- Every major control family has the same pattern. App Control option 3, ASR rule state 2, the Content-Security-Policy-Report-Only header, Pod Security Admission audit and warn labels, and ModSecurity DetectionOnly all separate evaluation from blocking.
- Exit on evidence, not on the calendar. Move to enforcement when audit events have been triaged, legitimate activity has rules or exceptions, and the residual audit hit rate is stable and explained.
- Run both modes at once where the product allows it. Enforce a proven baseline while auditing a stricter candidate policy, so the next tightening is already being measured.
- A policy left in audit is a finding. Track how long each control has been in audit, who owns the decision to enforce, and alert when an enforced policy is switched back.
What the two modes actually do
Audit mode (also called report-only, detection-only, dry run or monitor mode) runs the full policy evaluation and records a "would have blocked" result, but lets the action proceed. Enforcement mode runs the same evaluation and stops the action: the binary does not load, the script is refused, the browser drops the resource, the API server rejects the object or the proxy returns an error.
The evaluation logic is identical in most products, which is what makes audit useful: the audit log is a forecast of enforcement impact. Three differences matter in practice:
- Impact: audit has no effect on users or workloads; enforcement can break legitimate activity if the policy is incomplete.
- Signal: audit events are evidence for tuning, not alerts. Enforcement events are both a security signal (something was stopped) and an operations signal (something may now be broken).
- Protection: audit provides detection at best. If nobody reviews the events, it provides nothing.
Some products add a middle state. Microsoft Defender attack surface reduction (ASR) rules have a Warn state that blocks but lets the user proceed, Kubernetes has warn as a separate mode from audit, and OPA Gatekeeper has a warn enforcement action. These soften the switch but are still forms of enforcement for most users.
Side-by-side comparison
| Dimension | Audit mode | Enforcement mode |
|---|---|---|
| Effect on the action | Allowed, logged as would-block | Blocked, logged as blocked |
| Security value | Visibility and impact forecasting | Prevention plus visibility |
| Operational risk | Near zero (log volume only) | Outages, user friction, failed deployments if the policy is wrong |
| Who acts on events | Policy owner, as tuning backlog | Service desk and platform teams for false positives; SOC for true positives |
| Typical duration | Weeks, bounded by exit criteria | Permanent, with a tested rollback |
| Attacker view | Control is present but not stopping anything | Control must be bypassed or disabled |
| Main failure | Left on indefinitely; events never read | Switched on without triage; switched back after one incident |
How each control family implements audit and enforcement
The switch is a specific setting in each product. Knowing the exact setting, and the event it produces, is what lets you measure and govern the rollout.
| Control | Audit setting | Enforcement setting | Where the evidence lands |
|---|---|---|---|
| Microsoft App Control for Business (WDAC) | Rule option 3, Enabled:Audit Mode | Delete option 3 from the policy and redeploy | CodeIntegrity Operational: 3076 (audit) and 3077 (block); AppLocker MSI and Script: 8028 (audit) and 8029 (block); 3089 carries signature detail |
| Microsoft Defender ASR rules | State 2 (Audit) | State 1 (Block) or 6 (Warn); 0 is Off, 5 is Not configured | Windows Defender Operational: 1122 (audit), 1121 (block), 5007 (settings changed) |
| Content Security Policy | Content-Security-Policy-Report-Only response header with report-to | Content-Security-Policy header | Reporting API endpoint named in Reporting-Endpoints; report-uri is deprecated but still sent for older browsers |
| Kubernetes Pod Security Admission | pod-security.kubernetes.io/audit and /warn namespace labels | pod-security.kubernetes.io/enforce label | API server audit log annotations; client warnings |
| Kubernetes ValidatingAdmissionPolicy | validationActions [Warn, Audit] on the binding | validationActions [Deny] (optionally with Audit) | Audit event annotation validation.policy.admission.k8s.io/validation_failure |
| Kyverno | failureAction: Audit | failureAction: Enforce | PolicyReport and ClusterPolicyReport resources, plus events |
| OPA Gatekeeper | enforcementAction: dryrun (or warn) | enforcementAction: deny (the default) | Constraint status violations; --log-denies |
| ModSecurity with OWASP CRS | SecRuleEngine DetectionOnly | SecRuleEngine On | ModSecurity audit log and error log |
Policy engines are listed alphabetically; the order is not a ranking.
Application control
Microsoft documents option 3 as the setting that logs applications, binaries and scripts that would have been blocked, and says to delete the option to enforce. The documented workflow is to deploy in audit, exercise the applications you need, review the CodeIntegrity and AppLocker MSI and Script logs, generate rules from the events, merge them into the base policy or a supplemental policy, then remove option 3. Two details catch teams out. Script enforcement is decided by the script host: Microsoft notes that PowerShell runs scripts that fail the policy in Constrained Language Mode rather than refusing them outright, so 8029 does not always mean the script did nothing. And option 10, Enabled:Boot Audit on Failure, drops an enforced policy back to audit if a boot-critical driver fails, which is a safety net you should know is there. See the App Control for Business (WDAC) guide for rule levels and supplemental policies, and the Application Allowlisting Guide for the platform-neutral model.
Attack surface reduction rules
Microsoft's ASR test guidance is to enable all rules in Audit at the same time, starting with a first ring of champion devices, because audit does not affect users and shows which rules fire on everyday business activity. Its exclusions guidance is direct: rule exclusions are better than turning rules off or switching them back to Audit, and Warn should be used where a rule supports it to limit disruption. Two rules do not support Warn: Block credential stealing from the Windows local security authority subsystem, and Block Office applications from injecting code into other processes. Those go straight from Audit to Block. See How to Deploy Attack Surface Reduction Rules for the per-rule rollout.
Content Security Policy
The CSP Level 3 specification (a W3C Working Draft, dated 27 October 2026 when checked) gives each policy a disposition of enforce or report. The report-only header cannot be delivered in a meta element, only as a response header, and MDN notes that without report-to (or the deprecated report-uri) no reports are sent at all. Because both headers can be present on one response, the strongest pattern is to enforce a working policy and run a stricter candidate, such as a nonce-based script-src without unsafe-inline, in report-only alongside it. See the Content Security Policy Guide for directive design.
Kubernetes admission
Pod Security Admission defines three modes per namespace, and a namespace can set a different level for each. Audit and warn are applied to workload resources such as Deployments and Jobs, while enforce applies only to the resulting Pods. That asymmetry matters: an enforced namespace will accept a non-compliant Deployment and then fail to create its Pods, so the failure shows up as a stuck rollout rather than a rejected apply. The Kubernetes documentation recommends a server-side dry run of the enforce label before applying it, which tests existing Pods against the new level and returns violations as warnings without changing anything. For ValidatingAdmissionPolicy, Deny and Warn may not be combined, and Warn with Audit is the documented observe pattern. See the Kubernetes Admission Control Guide and Admission Control vs Runtime Security.
Web application firewalls
The ModSecurity reference manual describes DetectionOnly as processing rules but never executing disruptive actions such as block, deny or drop. With the OWASP CRS, tuning in detection mode means lowering false positives through rule exclusions before raising the anomaly threshold into blocking. See WAF vs API Gateway for where the WAF sits in an API stack.
Exit criteria: when to switch to enforcement
A fixed period ("two weeks in audit") is a poor rule on its own because it ignores business cycles and coverage. Use evidence-based gates, with a time box as a backstop.
- Coverage: the audit policy is deployed to a representative set that includes every major device build, application owner group, namespace type or site template, not just IT devices.
- Business cycle: the audit period spans at least one occurrence of known periodic activity: month-end finance jobs, quarterly patching, payroll runs, release trains.
- Triage complete: every distinct would-block item (by file hash or publisher, rule ID, violated directive or policy) is classified as legitimate (rule or exception added), malicious (incident raised) or unwanted (owner told it will break).
- Stable residual: new distinct would-block items per week have fallen to a low, explained level, and the remaining ones are understood.
- Rollback tested: the team has reverted the policy in a pilot ring and confirmed how long it takes to propagate.
- Support ready: the service desk has a script for "blocked by policy" tickets, a route to the policy owner and a target turnaround for exceptions.
- Sign-off: a named owner approves enforcement for the ring, recorded as a change.
Set a maximum audit duration per control (for example, one quarter) after which the owner must either enforce or record a risk acceptance. That turns indefinite audit into a visible decision.
Implementation: a staged rollout
- Baseline: deploy the policy in audit to all in-scope systems at once where impact is nil, so you see the full picture. ASR guidance follows this approach.
- Collect centrally: forward the audit events (Windows Event Forwarding or EDR telemetry, the CSP reporting endpoint, API server audit logs, PolicyReports, WAF logs) to the SIEM before tuning starts.
- Tune: build rules from audit data, prefer narrow exceptions (publisher and product over path, a single rule exclusion over disabling the rule set) and record each exception with an owner and review date.
- Enforce in rings: ring 0 IT and champions, ring 1 a representative pilot, ring 2 broad deployment, ring 3 sensitive or fragile estates. Hold each ring for a defined soak period.
- Keep auditing the next step: run a stricter candidate in audit alongside the enforced baseline (a second CSP header, a restricted audit label over a baseline enforce label, a supplemental App Control policy in audit).
- Rollback: revert by ring through the same deployment channel, never by disabling the control fleet-wide, and log the rollback as a change with a reason.
Decision guidance
| Situation | Approach |
|---|---|
| New control, unknown estate | Audit everywhere first, then enforce by ring |
| High-risk, low-impact rule (for example LSASS credential theft protection) | Short audit, enforce early; few legitimate triggers expected |
| Fragile or regulated systems (OT, clinical, trading) | Longer audit with owner sign-off; enforce last, with a maintenance window |
| Public web application | Enforce a known-good CSP now, run the strict candidate report-only |
| Kubernetes cluster with many teams | Audit and warn at restricted cluster-wide, enforce baseline, raise enforce per namespace as teams comply |
| Active incident or known exploitation | Skip or shorten audit for the specific rule; accept some disruption |
Small organisations rarely have staff to triage weeks of audit data. A short audit on a handful of representative machines, then enforcement with a fast exception route, often gives better protection than a long audit nobody reads. Large organisations need the ring model, an exception workflow with owners, and reporting on audit age per control, because the risk of an indefinite audit grows with the number of teams that can delay sign-off.
Risks of staying in audit
- No prevention: commodity malware, unsigned tools and injected scripts run exactly as if the control were absent.
- False assurance: dashboards and audit evidence show the control as "deployed", and auditors or insurers may read that as protection. Report mode explicitly.
- Policy drift: the longer audit runs, the more new software and workloads appear, so the tuning backlog grows instead of shrinking.
- Log fatigue: high volumes of would-block events with no owner train the SOC to ignore the source, including real attacks in it.
- Easy defence impairment: an attacker with admin rights who disables or modifies security tools (MITRE ATT&CK T1685 Disable or Modify Tools) has less to do when the control is already non-blocking.
Where identity fits
Two identity questions decide whether the switch holds. First, who can change the mode: the Intune or Group Policy administrators, the Kubernetes users allowed to edit namespace labels or policy bindings, and the pipeline identities that deploy WAF and CSP configuration can all quietly switch enforcement back to audit. Limit those rights and treat the deploying service accounts and CI tokens as privileged non-human identities. Second, exceptions are often scoped to identities (a service account exempt from an admission policy, a user group excluded from an ASR rule); review those exceptions like access grants. See the Change Management Security guide and How to Run an Access Review for Service Accounts.
Detection and measurement
Monitor the mode itself, not just the events it produces:
- Alert on ASR event 5007 where a rule state changes from 1 or 6 to 2 or 0, on App Control policy redeployments that add option 3, on namespace label changes that remove an enforce label, on Gatekeeper constraints changing from deny to dryrun, and on WAF configuration changes to DetectionOnly.
- Correlate enforcement events (3077, 8029, 1121, API server denials, WAF blocks) with service desk tickets to separate false positives from attacks.
Metrics that show the programme is working:
- Enforcement coverage: percentage of in-scope systems, namespaces or applications where the control is enforced, per control.
- Audit age: days each policy has been in audit, against its maximum.
- Distinct would-block items per week during audit, trending down.
- Exception count and age, with the share past review date.
- Rollbacks per quarter and median time to restore after a false positive.
- Unauthorised mode changes detected, target zero.
Common failure patterns
- Audit forever. The policy is deployed, the project closes, and nobody owns the switch. Fix: maximum audit age with forced decision.
- Audit on IT devices only. The estate that matters (finance, engineering, production namespaces) was never in the sample, so enforcement breaks it.
- Broad exceptions to hit a date. Path-based App Control rules on user-writable folders, a whole ASR rule disabled, unsafe-inline left in script-src, a namespace exempted from Pod Security Admission. The control is enforced in name only.
- Silent report-only. CSP report-only without report-to, or audit annotations without an audit policy that records them, produce no data at all.
- Fleet-wide reversion after one outage. Rolling back everywhere instead of the affected ring loses months of work. Revert narrowly and fix the rule.
- Misreading enforcement events. Treating 8029 as proof a script was stopped when the script host only constrained it, or treating a Pod Security Admission pass on a Deployment as proof its Pods will run.
Framework mapping
| Framework | Reference | How the audit to enforcement process supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-7(5) Authorized Software: Allow-by-exception | Enforced allowlisting is the control; audit is how you build the list |
| NIST SP 800-53 Rev. 5 | CM-4 Impact Analyses, CM-3 Configuration Change Control | Audit data is the impact analysis; the switch is a controlled change |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring, CA-7 Continuous Monitoring | Monitoring mode changes, audit events and enforcement events |
| NIST CSF 2.0 | PR.PS-05, PR.PS-01, DE.CM-09 | Unauthorised software prevented; configuration management; runtime monitoring |
| ISO/IEC 27001:2022 Annex A | 8.32 Change management | Enforcement and rollback are recorded changes |
| MITRE ATT&CK v20 | T1685 Disable or Modify Tools, T1059 Command and Scripting Interpreter | Detect mode tampering; enforced script control limits interpreter abuse |
Practitioner checklist
- List every blocking control you own and record its current mode, owner and date it entered audit.
- Set a maximum audit duration per control and a named owner for the enforcement decision.
- Forward audit events centrally before tuning begins and confirm reports are actually arriving.
- Write exit criteria covering coverage, business cycle, triage, residual rate, rollback and support.
- Prefer narrow exceptions with owners and review dates over disabling rules or reverting to audit.
- Enforce by ring and test rollback in a pilot ring before broad deployment.
- Run a stricter candidate policy in audit alongside the enforced baseline.
- Alert on any change from enforcement back to audit or off, and restrict who can make it.
- Report enforcement coverage, not deployment, to leadership and auditors.
Standards and references
- Microsoft Learn: Understand App Control for Business policy rules and file rules
- Microsoft Learn: Understanding App Control event IDs
- Microsoft Learn: Test attack surface reduction rules
- Microsoft Learn: Enable attack surface reduction rules
- W3C: Content Security Policy Level 3
- Kubernetes: Pod Security Admission
- Kubernetes: Validating Admission Policy
- OPA Gatekeeper: Handling Constraint Violations
Related NHI Mgmt Group resources: App Control for Business (WDAC) · How to Deploy Attack Surface Reduction Rules · Content Security Policy Guide · Kubernetes Admission Control Guide · Hardening Exceptions and Compensating Controls Template