Audit-First SMB Hardening in Windows Server: Signing and EPA Readiness

Microsoft has added built‑in auditing to help administrators safely roll out two proven SMB server hardening features—SMB Server signing and SMB Server Extended Protection for Authentication (EPA)—so that organizations can discover compatibility gaps before they require those hardening controls by policy. The change, published on September 9, 2025, introduces new Group Policy, registry and event‑log hooks that let operators run audit-first assessments and gather actionable telemetry for remediation planning. (support.microsoft.com)

Background and why this matters​

SMB remains the dominant protocol for Windows file sharing and network file access across enterprise estates. While features such as SMB signing and SMB Server EPA significantly reduce the risk of credential relay and tampering attacks, enforcing them universally can break legacy devices, embedded systems, third‑party NAS appliances and certain custom applications that do not implement these protections correctly.
To address that operational friction, Microsoft enabled audit events that report whether a connecting SMB client supports signing or EPA so administrators can identify problematic endpoints before flipping a hard enforcement switch. This capability was delivered alongside Windows updates released on and after September 9, 2025 and is intended to give teams visibility into compatibility gaps across SMBv1, SMBv2 and SMBv3 clients. (support.microsoft.com)
Microsoft’s guidance and how SMB hardening maps to risk:

• SMB Server signing adds cryptographic message signatures to SMB packets to detect tampering and block relay attacks; it’s a core defensive control and now can be audited before being required. (learn.microsoft.com)
• SMB Server EPA (Extended Protection for Authentication) binds authentication to channel and service identity, blocking certain relay-style attacks and preventing authentication to unintended targets; audit events reveal whether clients send an SPN (Service Principal Name) during negotiation. (support.microsoft.com)

---

What Microsoft shipped: audit knobs, registry names and events​

Configuration surfaces (Group Policy and registry)​

Microsoft exposes audit capabilities both through Group Policy and direct registry settings so administrators can integrate checks into existing management pipelines and baselines.

• Group Policy path (Server-side):
  • Computer Configuration → Administrative Templates → Network → Lanman Server
  • Policy names: Audit client does not support signing and Audit SMB client SPN support (for EPA). (support.microsoft.com)
• Registry keys:
  • HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  • Value: AuditClientSpnSupport (REG_DWORD) — 0 = Disabled (default), 1 = Enable auditing. The same value name is used for SPN/EPA auditing when set via policy. (support.microsoft.com)

These settings let administrators enable server‑side auditing without immediately rejecting connections, enabling a discovery posture with minimal disruption. (support.microsoft.com)

Key audit Event IDs (what to log and where)​

When auditing is enabled, Windows writes events under the Applications and Services Logs\Microsoft\Windows\SMBServer\Audit channel. The important event IDs introduced or documented for these checks are:

• 3021 (SMB2/SMB3) — Warning: The SMB server observed that the client doesn't support signing. Useful fields: client name, user name, whether the server requires signing. (support.microsoft.com)
• 3027 (SMB1) — Warning: The SMBv1 server observed that the SMBv1 client does not have signing enabled. Note: SMBv1 auditing can be ambiguous because the protocol historically did not advertise signing capability consistently; extra verification is required. (support.microsoft.com)

EPA related events:

• 3024 — Warning: Client did not send an SPN during authentication (indicates no EPA support or disabled on client). (support.microsoft.com)
• 3025 — Warning: Client sent an unrecognized SPN during authentication. (support.microsoft.com)
• 3026 — Warning: Client sent an empty SPN (capable but chose not to supply one). (support.microsoft.com)

These events include textual fields that indicate the client identity, SPN status, and server policy state—information that makes triage and exception tracking feasible at scale. (support.microsoft.com)

---

Cross‑validation and authoritative references​

The audit controls and the concept of auditing before enforcement align with Microsoft’s broader SMB signing and enforcement documentation, which explains signing mechanics and administration commands (PowerShell) for both client and server sides. The Microsoft Learn documentation shows how to check and set SMB signing state and also lists related audit flags and PowerShell commands (for example, Set‑SmbServerConfiguration -AuditClientDoesNotSupportSigning). Using these management APIs helps automate detection and remediation workflows. (learn.microsoft.com)
Community and operational guidance published in technical forums and administration communities emphasizes the same pattern: run an audit phase, collect event telemetry, remediate or isolate incompatible endpoints, and then enforce the stricter posture. These operational recommendations mirror past Microsoft rollouts for related identity/SMB hardening changes and have been shared broadly by administrators.

---

Practical deployment plan — audit, analyze, remediate, enforce​

A pragmatic, low‑risk rollout consists of four phases. Each phase includes concrete steps and example commands.

1. Audit (discovery, non‑disruptive)​

• Enable server‑side auditing via Group Policy or registry:
  • Set the Group Policy “Audit client does not support signing” to Enabled (or set AuditClientSpnSupport = 1 in the server registry path). (support.microsoft.com)
• Optionally enable the client‑side audit equivalents if you want server–client cross‑checks (Set‑SmbClientConfiguration -AuditServerDoesNotSupportSigning $true). (learn.microsoft.com)
• Allow logs to accumulate for a defined observation window (two to four weeks depending on SMB usage cycles).

2. Collect and analyze telemetry​

• Pull the SMBServer/Audit event channel and export occurrences of Event IDs 3021, 3027, 3024, 3025, 3026.
• Correlate events with:
  • Host inventory (IP / hostname / OS version)
  • Application owners and service accounts
  • Device type (printer, POS, NAS, IoT)
• Example SIEM/EQL query pattern: search for EventLog == "Microsoft‑Windows‑SMBServer/Audit" and EventID in (3021,3024,3025,3026,3027) then group by ClientName and count. Use timestamps to determine whether an endpoint is periodically connecting only during business hours or continuously (useful to prioritize remediation).

3. Remediation (targeted fixes or workarounds)​

• For Windows clients: ensure OS builds are patched, enable appropriate SMB client configuration (RequireSecuritySignature where feasible), and prefer Kerberos for authentication. Use commands shown in Microsoft Learn to set signing and audit options via PowerShell. (learn.microsoft.com)
• For third‑party devices: engage vendors and firmware teams. If no update is available:
  • Isolate the device to a restricted VLAN
  • Implement firewall rules that limit SMB flows to only trusted servers
  • Replace the device when feasible
• For legacy SMBv1 devices (where 3027 events appear): treat as high risk—plan replacement or strict network segmentation. Note: SMBv1 semantics may produce false positives/negatives because of historical protocol limitations; use extra validation. (support.microsoft.com)

4. Controlled enforcement​

• Once telemetry shows acceptable compatibility and remediation actions are completed for high‑value systems, enable requirement for SMB signing or EPA on servers in a phased manner.
• Continue monitoring the audit logs and maintain exception tracking. Prepare rollback and business‑impact communication if a system unexpectedly fails after enforcement.

Numbered rollout checklist:

1. Configure audit settings in a pilot domain or collection of file servers. (support.microsoft.com)
2. Collect SMBServer/Audit events for 2–4 weeks.
3. Triage by owner, system role and urgency.
4. Remediate or isolate incompatible devices.
5. Enforce signing/EPA on pilot rings; monitor for errors.
6. Gradually expand enforcement to the entire estate.

---

Detection recipes and SIEM playbooks​

Administrators should build rule sets that prioritize event frequency and asset criticality. Example detection guidance:

• Alert on any client generating more than X events of 3021/3024 per day where X is tuned to your environment (start with X=5). Correlate alerts with unexpected process names that initiate SMB network connections (Explorer.exe, indexing services).
• Flag devices that generate 3027 (SMB1 signing missing) and are not scheduled for replacement—treat as high priority.
• When 3024/3025/3026 events appear, record the SPN string and map to known service names. An empty SPN (3026) indicates the client can provide an SPN but did not, which could be a configuration issue or an application that explicitly disables EPA.
• Enrich SMB audit events with Netflow/PCAP metadata to identify destination servers and external connections (detect if an internal client ever attempts SMB to an external IP).

Sample PowerShell commands for collection and setting:

• Enable server audit (PowerShell):
  Set‑SmbServerConfiguration ‑AuditClientDoesNotSupportSigning $true
  Set‑SmbServerConfiguration ‑AuditClientDoesNotSupportEncryption $true
  Set‑SmbServerConfiguration ‑AuditClientSpnSupport $true
  (These commands are documented on Microsoft Learn.) (learn.microsoft.com)

---

Compatibility risks, false positives, and operational caveats​

The audit model intentionally errs on the side of caution, but administrators should be aware of several pitfalls:

• SMBv1 ambiguity: SMBv1 historically did not advertise signing capability reliably. Event 3027 is therefore a useful flag but may require further functional testing to prove lack of signing capability. Microsoft explicitly warns that SMBv1 events can yield false positives or negatives and recommends deeper evaluation for SMBv1 endpoints. (support.microsoft.com)
• False positives from non‑advertising but capable clients: Some clients support signing but don’t advertise it properly, which can cause an audit hit even though the client will actually negotiate signing if the server requires it. That nuance must be handled by cross‑checking whether a failed session is actually rejected when signing is required. (support.microsoft.com)
• Vendor interoperability: Storage arrays, NAS devices, virtualization platforms and Samba implementations may behave differently. Test every vendor‑supplied appliance against a signing/EPA enforcement pilot before rolling out widely. Community threads and field reports repeatedly stress vendor coordination when tightening SMB defaults.
• Performance and compatibility tradeoffs: Enabling signing and EPA can change session behavior and sometimes increase CPU for signing verification on heavily loaded file servers; measure performance impact in staging. Also confirm backup and snapshot tools, antivirus scanning integrations, and clustering software behave correctly.

---

Remediation tactics and practical fixes​

• For Windows clients and servers:
  • Ensure fully patched builds and prefer Kerberos (Negotiate) over NTLM. Use Group Policy or PowerShell to require signing where possible. (learn.microsoft.com)
  • For managed fleets, deploy the registry or GPO update that enables auditing first, then a second change that enforces signing after validation.
• For unmanaged or legacy appliances:
  • Engage vendor support and request firmware or SMB stack updates.
  • If updates are unavailable, isolate the device in ACLs and firewall rules that allow only necessary SMB traffic to known, patched servers.
  • If device replacement is not immediately feasible, document exception timelines and track them in a remediation ticket system.
• For applications that do not send SPNs or supply empty SPNs:
  • Reconfigure the application or its service account to use proper service principal names.
  • If that’s not possible, consider using application‑specific exceptions with compensating network controls.

---

Why audit‑first hardening is the right operational model​

A straight requirement for signing/EPA across an organization is the most secure posture, but it risks widespread outages if done without inventory, telemetry and remediation. The audit‑first model offers three decisive advantages:

• Visibility: Administrators get concrete lists of incompatible endpoints with contextual fields—host, user, SPN—so remediation work can be directed where it matters. (support.microsoft.com)
• Low disruption: By auditing, teams avoid breaking business‑critical devices and can schedule fixes without emergency rollbacks. Community experience around similar rollouts shows that staged auditing reduces incidents and makes vendor conversations more productive.
• Measurable progress: Audit events provide metrics to show when it’s safe to move to enforcement (e.g., when 95% of traffic originates from signing/EPA‑capable clients).

---

Operational checklist and quick reference​

• Enable audit settings for SMB Server signing and EPA via Group Policy or registry on a pilot scope. (support.microsoft.com)
• Run log collection for 2–4 weeks and export Event IDs 3021, 3027, 3024, 3025, 3026.
• Correlate logs with CMDB/asset inventory and prioritize high‑value systems.
• Engage vendors for non‑Windows devices; apply firmware updates or plan replacements.
• Test enforcement on a small ring and monitor logs for unexpected rejections.
• Scale enforcement across business units once telemetry and remediation coverage meet your risk threshold.

---

Limitations, unverifiable points and recommended validation​

Microsoft’s support article and Learn documentation define the new audit events and recommended configuration steps, but the following require cautious validation in each environment:

• The phrasing about when and how SMBv1 advertises signing may vary by vendor implementation and historical patches. Administrators should treat SMBv1 audit events as indicators rather than absolute proof and follow up with functional tests. (support.microsoft.com)
• Third‑party SMB stacks (embedded NAS, non‑Windows SMB servers) frequently have implementation quirks that produce unexpected SPN strings or signing behaviors; vendor testing and limited enforcement pilots are the only reliable way to validate compatibility at scale. Community posts corroborate that multiple vendors needed firmware updates when Windows tightened defaults in previous cycles.

If a claim about a specific vendor’s exact behavior is needed (for example, whether a given NAS model advertises signing correctly), test it directly against a Windows server with auditing enabled or obtain vendor documentation. Where public vendor statements are absent, treat the compatibility posture as unknown and isolate until proven.

---

Conclusion​

The addition of server‑side auditing for SMB Server signing and SMB Server EPA represents an operationally sound step: it reduces the risk of breaking production while enabling organizations to move toward a more secure SMB posture. By using the new Group Policy and registry audit controls and consuming Event IDs 3021, 3024–3027 and 3027 (for SMBv1), administrators can build an evidence‑driven remediation program that systematically eliminates weak SMB endpoints and prepares estates for enforcement.
Adopting the audit‑first approach—collect, triage, remediate, enforce—lets teams protect credentials and file traffic without disrupting business workflows. The plan must include vendor coordination, careful handling of SMBv1 edge cases, and clear SIEM integrations to make the audit events actionable at scale. These new audit events provide the missing instrumentation to do that work with confidence. (support.microsoft.com, learn.microsoft.com)

---

Source: Microsoft Support Support for Audit Events to deploy SMB Server Hardening—SMB Server Signing & SMB Server EPA - Microsoft Support