Microsoft Ships Audit-First SMB Hardening to Discover Incompatible Clients Before Enforcement

Microsoft has rolled out built‑in auditing for two critical SMB server hardening features—signing and Extended Protection for Authentication (EPA)—giving administrators a safe, pre‑enforcement discovery phase that pinpoints incompatible devices and applications before they cause production outages. The update, linked to CVE-2025-55234 and delivered in the September 9, 2025 Windows security patches, introduces new Group Policy settings, registry keys, and a dedicated event log channel that together let teams gather actionable telemetry and plan remediation with minimal business disruption.

For years, SMB signing and EPA have been available as powerful defenses against credential relay and tampering attacks on Windows file shares. Enforcing them universally, however, has been a high‑stakes gamble: legacy network‑attached storage, embedded systems, old printers, and custom line‑of‑business applications often choke when a server suddenly demands signed packets or a service principal name during authentication. The new audit‑first approach removes that gamble by letting organizations log who would fail before they ever flip the enforcement switch.

The two hardening features and why auditing matters

SMB Server signing adds cryptographic signatures to every SMB packet. Any tampering or replay attempt becomes immediately detectable, which shuts down a whole class of relay attacks. EPA, meanwhile, binds the authentication exchange to a specific service identity—typically via the Kerberos SPN—so an attacker cannot redirect a user’s ticket to an unintended target. Both are mature, well‑understood controls that Microsoft has long recommended.

“In a lot of shops, the fear of breaking something has kept these protections turned off,” one senior administrator noted in community discussions. “We knew we needed to get tighter, but we had no way to see the blast radius without causing a Sev‑1 ticket.” The new audit events answer that exact anxiety. They appear in the Applications and Services Logs\Microsoft\Windows\SMBServer\Audit channel and reveal, connection by connection, whether a client supports signing, whether it sends an SPN, and—critically—whether the server would have rejected the session were enforcement active.

Configuration options: Group Policy, registry, and PowerShell

The audit controls are exposed through three familiar management surfaces, so they fit naturally into existing baselines and infrastructure‑as‑code pipelines.

Group Policy (server‑side)

• Navigate to Computer Configuration → Administrative Templates → Network → Lanman Server.
• Two new policies appear:
• Audit client does not support signing
• Audit SMB client SPN support (for EPA)

Registry

• Path: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
• The key for signing audit is AuditClientDoesNotSupportSigning (REG_DWORD: 0 = Disabled, 1 = Enabled).
• For EPA audit, the value name is AuditClientSpnSupport; despite the different name, setting it to 1 enables EPA auditing when configured via policy.

PowerShell

Enable server‑side audit with two cmdlets:

Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbServerConfiguration -AuditClientSpnSupport $true

These settings are non‑disruptive: they instruct the SMB server to log warnings for clients that would fail a future enforcement, but the server still accepts the connection as before.

Event IDs: what to collect and what they mean

When auditing is active, the system writes detailed events to the SMBServer/Audit channel. Unlike generic network logs, these include the client name, user name, server policy state, and the specific SPN sent (or missing). This context makes it practical to assign remediation to the right team.

SMBv1 caveat (3027): Because SMB1 historically did not advertise signing capability reliably, event 3027 must be treated as an indicator, not absolute proof. “SMB1 devices can generate false positives or negatives,” Microsoft warns. Functional testing is still necessary before concluding a legacy SMB1 appliance is truly non‑compliant.

A phased, audit‑first deployment playbook

Community experience and Microsoft’s documentation converge on a four‑phase rollout that has become the de facto standard for SMB hardening.

Phase 1: Audit (non‑disruptive discovery)

1. Enable server‑side audit settings on a pilot group of file servers.
2. Set a collection window of two to four weeks to capture daily, weekly, and monthly connection patterns.
3. Optionally, turn on client‑side audit (Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true) for a cross‑check.

Phase 2: Analyze telemetry

Pull the SMBServer/Audit log and export events 3021, 3024–3027. Correlate each entry with:
- Asset inventory (hostname, OS version, IP)
- Application owner and service account
- Device type (printer, NAS, IoT, POS terminal)

Sample SIEM/EDR query (EQL style):

EventLog == "Microsoft-Windows-SMBServer/Audit" and EventID in (3021,3024,3025,3026,3027)
| group by ClientName, EventID
| count

Tier the findings by risk. SMB1 devices generating 3027 events are automatically high‑priority; modern Windows clients that show 3021 occasionally may just need a configuration tweak.

Phase 3: Remediate

• Windows clients: Ensure they are fully patched; enable RequireSecuritySignature where feasible; prefer Kerberos over NTLM.
• Third‑party appliances: Engage the vendor. Many NAS and storage arrays have received firmware updates that add signing and EPA support. If no update is available, isolate the device to a restricted VLAN with firewall rules that permit SMB only to trusted, patched servers.
• Applications sending no SPN or an incorrect one: Configure the service account with a proper SPN, or use application‑specific exception lists with compensating controls.
• SMBv1 holdouts: Treat as an existential risk. Plan replacement or strict network segmentation, and use additional validation because of the protocol’s ambiguity.

Phase 4: Controlled enforcement

Once telemetry shows that high‑value traffic is coming from compliant clients:
- Enable RequireSecuritySignature or RequireExtendedProtection on a small ring of servers.
- Continue monitoring the audit log. An unexpected spike in 3021 events after enforcement may reveal a client that was previously silent because it wasn’t advertising.
- Expand enforcement gradually, maintaining exception records and rollback procedures.

“The audit‑first model turns a high‑risk change into a measured project,” a veteran infrastructure engineer wrote in a widely‑circulated community post. “We went from 40% signing‑ready to 98% in six weeks, and the business never noticed.”

Operational caveats and false‑positive scenarios

The audit events are designed to be safe, but a few real‑world quirks demand attention:

• Non‑advertising but capable clients: Some SMB clients support signing but don’t announce it during the pre‑negotiation. They will still succeed when the server mandates signing. Cross‑check: if a client generates event 3021, temporarily require signing on a test server and see if the connection breaks.
• SPN anomalies: Event 3026 (empty SPN) might mean the client deliberately turned off EPA, but it could also be a misconfigured application. Check the application documentation or debug with a network trace.
• Performance overhead: Signing and EPA validation consume CPU. On heavily loaded file servers, measure the impact in a staging environment. Most modern hardware handles it without noticeable degradation, but storage‑focused servers serving thousands of concurrent sessions may require capacity planning.
• Backup and clustering software: Ensure that backup agents, antivirus scanner accounts, and failover cluster configurations are tested with signing and EPA enforced. A backup job that suddenly fails because its service account doesn’t send an SPN can lead to a silent protection gap.

SIEM integration and detection engineering

Because the audit channel is a standard Windows event log, it can be forwarded to any SIEM or log analytics platform. Build alert rules that prioritize frequency and asset criticality:

• Threshold alert: Fire an alert if any single client generates more than 5 occurrences of 3021 or 3024 within 24 hours. Tune the number based on your environment’s normal noise level.
• SMB1 presence: Any occurrence of 3027 should trigger a high‑severity notification, ideally linked to a replacement project ticket.
• Anomalous SPN values: Monitor for unrecognized SPN strings (event 3025) and map them to known application identity records. An SPN that looks like a random string may indicate a misconfiguration or a malicious tool.

Enrich SMB audit events with network metadata to spot outbound SMB connections to external IPs—often a sign of a compromised client trying to mount a hacker‑controlled share.

Why audit‑first is the correct operational model

Mandating signing and EPA overnight is the most secure state, but it risks a cascade of support calls from every department whose printer, scanner, or legacy app suddenly stops working. Audit‑first gives organizations three decisive advantages:

1. Actionable visibility: A concrete list of non‑compliant endpoints, complete with user and application context, so remediation is targeted rather than theoretical.
2. No outage drama: Business‑critical workflows stay online while teams schedule fixes during maintenance windows. Vendor conversations become collaborative, not emergency‑driven.
3. Measurable security progress: Audit metrics allow security leaders to show a clear improvement curve, making it easier to get sign‑off for eventual enforcement.

The approach mirrors Microsoft’s own journey with Kerberos hardening and NTLM auditing, patterns that proved effective in large enterprises.

Limitations and recommended validation

While the documentation is unambiguous, administrators should independently validate the following in their own labs:

• SMBv1 audit events may behave differently across OEM firmware versions. Treat any event 3027 as a prompt for physical verification, not a definitive statement of compliance.
• Third‑party SMB stacks (embedded NAS, Samba‑based appliances, virtualization hosts) often have idiosyncratic implementations. A vendor’s marketing claim of “supports signing” does not guarantee compatibility with Windows Server’s EPA handshake. Pilot enforcement in an isolated test network before touching production.
• The registry value name AuditClientSpnSupport may be superseded in future updates; always check the latest Microsoft Learn article for any renaming or consolidation.

Conclusion

With the September 2025 update, Microsoft has handed Windows administrators the missing instrumentation to tackle SMB hardening without fear. By turning on the new audit settings, collecting Events 3021 and 3024‑3027, and following a phased deployment, organizations can systematically eliminate weak SMB endpoints and move to a posture where signing and EPA are the default—not the exception. The path is clear: audit first, analyze the telemetry, remediate the gaps, and then enforce the protections. It’s the difference between a planned security uplift and an unplanned outage.