Log in
In this post I go over some tools and techniques exist for hardening Windows Server. As always, apply controls according to the server's role, test them against representative workloads before production rollout, document approved exceptions, and maintain tested console and recovery access in case a security control affects management or application compatibility.
Apply the role-specific Windows Server 2025 baseline with OSConfig
Security baselines turn hundreds of individual security decisions into a consistent, role-aware desired state. Using OSConfig reduces exposure caused by insecure defaults, legacy protocols, inconsistent administrator choices, and configuration drift that attackers can exploit for credential theft, lateral movement, or persistence.
You can use use OSConfig at build time to apply the Microsoft security baseline that matches the server role: SecurityBaseline/WindowsServer/2025/MemberServer, SecurityBaseline/WindowsServer/2025/DomainController, or SecurityBaseline/WindowsServer/2025/WorkgroupMember. The baseline contains more than 300 settings covering network exposure, credentials, lateral movement, persistence resistance, and auditing. It can be managed through PowerShell, Windows Admin Center, or Azure Policy for Azure Arc-enabled servers.
You can keep OSConfig drift control enabled so unauthorized or accidental changes are detected and corrected. Pilot the baseline with each workload, record required exceptions, and manage those exceptions centrally rather than weakening the baseline broadly.
Implementation steps: Identify the server's role and the management authority that will own its settings, install the OSConfig PowerShell module, review the matching scenario, and apply it first to a representative test server. Validate application and management access, deploy the scenario in controlled rings, schedule and complete the restart required after applying the baseline, verify the desired configuration and compliance results, enable drift control, and record any approved exceptions and recovery procedures.
Possible drawbacks: A baseline can disrupt legacy applications, authentication methods, network flows, or management tools that depend on weaker settings. Drift control can also reverse intentional emergency changes if they aren't recorded through the correct authority, so staged testing, documented exceptions, and tested recovery access are essential.
Documentation on Learn: OSConfig security configuration for Windows Server | Deploy Windows Server 2025 security baselines with OSConfig | OSConfig security settings repository
Use Secured-core hardware and enable platform security
Windows Server secured-core combines hardware, firmware, virtualization, and operating-system protections to establish trust before Windows starts and preserve that trust while it runs. These controls mitigate bootkits, malicious or vulnerable kernel drivers, direct memory access attacks, firmware tampering, and attempts to extract credentials from the operating system.
You deploy on hardware or virtual machines that support TPM 2.0, UEFI Secure Boot, virtualization-based security, DMA protection, and the other Secured-core requirements. Enable the OSConfig SecuredCore scenario and verify that Credential Guard, hypervisor-protected code integrity, kernel protections, and the signed boot chain are active.
You need to keep system firmware, TPM firmware, hypervisor components, and hardware drivers current. Test older drivers before enabling enforcement because incompatible kernel drivers can prevent security features from activating or can affect boot reliability.
Implementation steps: Confirm that the physical server or virtual-machine platform meets the Secured-core requirements, update firmware and drivers, and enable TPM 2.0, Secure Boot, virtualization extensions, and DMA or IOMMU protection in the platform configuration. Apply the OSConfig SecuredCore scenario or configure the features through Windows Admin Center, restart as required, verify that each protection is active, record evidence of the hardware capabilities and running Windows protections rather than only the assigned policy, and monitor for driver or workload compatibility issues.
Possible drawbacks: Secured-core features require compatible hardware, firmware, hypervisors, and signed drivers, which can increase procurement costs or rule out older systems. Virtualization-based protections can introduce a workload-dependent performance impact, and incompatible drivers or firmware can cause application failures, feature activation problems, or difficult boot recovery.
Documentation: What is Secured-core server? | Configure Secured-core server | Windows Server 2025 secured-core hardware requirements
Deploy Server Core and minimize installed components
Attack-surface reduction removes code, services, interfaces, and utilities that an attacker could exploit or misuse after gaining access. A minimal Server Core deployment lowers the number of vulnerabilities that require patching and reduces opportunities for interactive attacks, malicious browsing, persistence, and abuse of unnecessary administrative tools.
Install Server Core unless a supported workload specifically requires Desktop Experience. Server Core has a smaller local interface and component footprint, reducing exposed code, maintenance requirements, and opportunities for interactive misuse. Windows Server 2025 can't convert between Server Core and Server with Desktop Experience after installation, so changing this choice later requires a clean installation.
Install only the roles, features, management agents, and application components required for the server's purpose. Remove obsolete utilities and unused software, avoid browsing the web from servers, and disable unnecessary services only after confirming role and application dependencies. Where practical, dedicate each server to a single security or workload role.
Implementation steps: Confirm that the workload and vendor support Server Core, formally record the installation-option decision before deployment, select Server Core during installation, and define the minimum roles, features, agents, and software required for the server's purpose. Install only those components, configure remote management and recovery access, remove or disable unused components after dependency testing, and verify that the application, monitoring, backup, patching, and support processes still function.
Possible drawbacks: Server Core can make local troubleshooting less familiar and increases reliance on remote management, automation, and command-line skills. Some vendor applications, support tools, or administrators require Desktop Experience, and removing roles or disabling services without dependency testing can break workloads, monitoring, backup, or recovery operations.
Documentation: What is the Server Core installation option? | Server Core and Desktop Experience installation options
Ensure rapid patching and continuous vulnerability management
Patching and vulnerability management identify and close known weaknesses before attackers can reliably exploit them. This practice reduces exposure to remote-code execution, privilege escalation, ransomware, vulnerable drivers, compromised third-party components, and attacks that target publicly documented vulnerabilities soon after disclosure. Make sure you are aware if any of your server workloads have not got the latest security updates deployed
Maintain an inventory of operating-system, application, driver, firmware, and management-agent versions. Use deployment rings to test updates quickly, meet defined remediation deadlines, install out-of-band security updates when required, and monitor update compliance and pending restarts. Azure Update Manager can provide centralized assessment and orchestration for Azure and Azure Arc-enabled servers.
Use Microsoft Defender Vulnerability Management or an equivalent platform to discover exposures, prioritize remediation by exploitability and business impact, and verify that fixes actually remove the vulnerability. Patching Windows while leaving internet-facing applications, drivers, or firmware obsolete does not adequately harden the server.
Implementation steps: Inventory servers and every supported update source, define remediation deadlines and deployment rings, and configure Azure Update Manager or another actively developed orchestration platform. Windows Server Update Services remains supported and available but is deprecated and should be treated as a legacy option rather than the preferred platform for a new long-term design. Run vulnerability assessments, prioritize exposed and actively exploited weaknesses, test updates, deploy them with coordinated reboots, verify compliance after installation, and maintain rollback and exception procedures.
Possible drawbacks: Updates can require reboots, consume maintenance windows, or introduce application, driver, and performance regressions. Vulnerability scanners and management agents also consume resources and can generate false positives, so organizations need test rings, rollback procedures, maintenance coordination, and a risk-based process for temporary deferrals.
Documentation: Azure Update Manager overview | Cloud-native patch management for Azure Arc-enabled servers | Microsoft Defender Vulnerability Management | Deprecated Windows Server features
Implement Microsoft Defender Antivirus and endpoint detection and response
Antivirus and endpoint detection and response combine prevention with behavioral monitoring and investigation. They mitigate malicious files, ransomware, web and network-delivered payloads, suspicious process activity, persistence mechanisms, credential theft, and attacks that evade simple signature-based detection.
Run Microsoft Defender Antivirus in active mode unless a documented and tested security architecture requires another antimalware product. Enable real-time protection, behavior monitoring, cloud-delivered protection, automatic sample submission, and frequent security-intelligence updates. Use the OSConfig Defender/Antivirus/WindowsServer/2025 scenario as the recommended Server 2025 configuration starting point.
Onboard servers to Microsoft Defender for Endpoint or Microsoft Defender for Servers for endpoint detection and response, investigation, and centralized visibility. Enable tamper protection and keep exclusions narrow, workload-specific, and regularly reviewed; broad path, process, or extension exclusions create useful hiding places for attackers.
Implementation steps: Confirm licensing, connectivity, proxy, and third-party antivirus requirements, then apply the OSConfig Defender Antivirus scenario or an equivalent centrally managed policy. Enable real-time, behavior, cloud-delivered, sample-submission, and tamper protections; onboard the server to Defender for Endpoint or Defender for Servers; review Microsoft's built-in, automatic server-role, and workload-specific exclusions before adding any manual exclusion; verify sensor health, signature currency, alert delivery, and investigation access; and periodically confirm that every manual exclusion remains necessary.
Possible drawbacks: Real-time scanning and endpoint telemetry can add CPU, memory, disk I/O, network, and licensing costs, particularly on high-throughput workloads. False positives or quarantine actions can interrupt services, while cloud-delivered capabilities can raise connectivity, privacy, or data-residency considerations; performance exclusions must therefore be tested and kept narrowly scoped.
Documentation: Microsoft Defender Antivirus in Windows | Microsoft Defender for Endpoint on Windows | Defender Antivirus exclusions | Protect against security-setting tampering
Deploy attack surface reduction and network protection on your Windows Server workloads
Attack surface reduction rules prevent high-risk behaviors rather than waiting for a specific malicious file to be identified, while network protection blocks access to known or suspicious destinations. Together they mitigate ransomware, credential theft, malicious scripts, abuse of trusted tools, vulnerable drivers, command-and-control traffic, and payload delivery.
Configure Microsoft Defender attack surface reduction rules to block common behaviors used by ransomware, credential theft, malicious scripts, vulnerable signed drivers, and executable content. Begin with audit or warning mode, review telemetry for legitimate workload dependencies, create narrowly scoped exclusions, and then move suitable rules to block mode on a defined schedule.
Enable network protection where supported to prevent processes from reaching malicious or untrusted destinations. Manage these controls centrally through Group Policy, Microsoft Defender for Endpoint security settings management, or another supported policy platform.
Implementation steps: Inventory server workloads and make a rule-by-rule applicability decision for each server role rather than reusing a generic workstation ASR profile unchanged. Create a centrally managed ASR and network-protection policy that initially uses audit or warning mode, collect and review events, confirm business-critical dependencies, create narrowly scoped exclusions, move applicable rules to block mode through deployment rings, verify that protected applications remain functional, and continuously review detections and exception use.
Possible drawbacks: ASR rules can block legitimate automation, administrative tools, installers, scripts, or line-of-business applications that exhibit high-risk behavior. Audit mode can produce substantial telemetry, and broad exclusions can undermine the protection, so successful deployment requires workload testing, event review, careful exception design, and ongoing tuning.
Documentation: Attack surface reduction capabilities | Evaluate Microsoft Defender Antivirus and ASR rules using Group Policy
Allow only trusted code with App Control for Business
Application control changes the execution model from allowing everything except known malware to allowing only code that satisfies an approved policy. This technique mitigates unknown malware, ransomware, unauthorized administrative utilities, malicious scripts, unapproved drivers, and opportunistic payloads that antivirus has not yet classified.
Use App Control for Business to define which executables, scripts, installers, libraries, and drivers may run. Windows Server 2025 includes OSConfig scenarios for Microsoft's default policy and application blocklist. Start in audit mode, collect Code Integrity event ID 3076, create required supplemental allow policies, and move to enforcement only after representative workload testing. There are some good GUI tools written by MVPs published on GitHub that make this very easy. https://github.com/HotCakeX/Harden-Windows-Security
Monitor blocked-code event ID 3077 after enforcement and maintain a controlled process for policy updates and emergency recovery. Application allowlisting is substantially stronger than relying only on malware signatures because unapproved code is prevented from running even when it has not yet been classified as malicious.
Implementation steps: Verify that the device is running a production-signed Windows Server 2025 build because the OSConfig default policy doesn't permit flight-signed binaries. Inventory approved applications, scripts, drivers, publishers, and update mechanisms, then deploy the default policy and application blocklist through OSConfig in audit mode. Collect event ID 3076, build and deploy required supplemental policies, and sign policies only when the additional tamper resistance is required and certificate lifecycle, policy servicing, removal, and offline recovery have been tested. Test application updates and recovery, move the policy to enforcement in stages, and monitor event ID 3077 and policy health after deployment.
Possible drawbacks: Poorly designed policies can block legitimate applications, updates, scripts, drivers, or boot-critical components and can cause a severe service outage. Maintaining allow policies creates operational overhead, especially for frequently changing software, and approved tools can still be abused, so audit-mode deployment, controlled updates, and offline recovery procedures are necessary. Signed policies provide stronger tamper resistance but are intentionally harder to remove, including during recovery.
Documentation: Configure App Control for Business by using OSConfig | App Control for Business
Keep Windows Defender Firewall enabled with restrictive rules
A host firewall limits which systems and applications can communicate with the server, even when upstream network controls are absent or bypassed. Restrictive rules reduce exposure to service exploitation, scanning, lateral movement, remote administration abuse, command-and-control traffic, and accidental publication of listening services.
Enable Windows Defender Firewall on Domain, Private, and Public profiles. Retain the default block for unsolicited inbound traffic and create only the rules required by the server role. Scope rules by program or service, protocol, local port, remote address, interface, and profile rather than creating broad port-based or any-source exceptions.
Log dropped packets and successful connections where operationally appropriate, centrally monitor policy changes, and review stale rules. Apply explicit outbound restrictions to high-value or tightly controlled servers where feasible, especially when they should communicate with only a small set of update, identity, management, and application endpoints.
Implementation steps: Inventory listening services and required inbound and outbound flows, enable the firewall on all profiles, and create narrowly scoped rules for the server role. Decide whether locally created rules may merge with centrally deployed rules for each profile, verify the effective policy on representative servers, remove obsolete or duplicate rules, test application, domain, cluster, backup, and management traffic, enable appropriate logging, deploy the policy centrally, and monitor rule changes and blocked connections before introducing selective outbound restrictions.
Possible drawbacks: Incorrect firewall rules can interrupt application traffic, clustering, domain operations, monitoring, backup, or remote management and can make diagnosis difficult. Detailed connection logging consumes storage, while restrictive outbound policies require continuous maintenance as service endpoints change, so rules should be documented, tested, and deployed with recovery access.
Documentation: Windows Firewall rule recommendations | OSConfig baseline network protections
Harden Remote Desktop and remote administration
Remote administration exposes privileged authentication and interactive control paths that are attractive targets for brute-force attacks, credential theft, session hijacking, and exploitation of internet-facing services. Gateways, multifactor authentication, encrypted sessions, restricted source networks, and credential isolation reduce the likelihood that a stolen password or exposed management port leads directly to server compromise.
Disable Remote Desktop Services when it is not required. When it is required, use a VPN or Remote Desktop Gateway, require multifactor authentication and Network Level Authentication, restrict source networks and authorized groups, use trusted TLS certificates, and configure sensible idle and disconnected-session limits. Disable clipboard, drive, printer, port, and device redirection unless the operational need outweighs the data-transfer risk.
Use Remote Credential Guard only for compatible direct RDP administration of Active Directory-joined targets using Kerberos so credentials aren't sent to the remote host. Remote Credential Guard isn't supported through Remote Desktop Gateway or Remote Desktop Connection Broker. For helpdesk access to a potentially compromised host, use Restricted Admin mode instead of Remote Credential Guard. Never expose TCP port 3389 directly to the internet, and avoid using saved privileged credentials on ordinary administrator workstations.
Implementation steps: Disable RDP on servers that don't require it. For brokered or externally initiated access, place RDP behind a VPN or MFA-protected Remote Desktop Gateway and restrict permitted users and source networks. For compatible direct RDP administration of Active Directory-joined targets, configure Remote Credential Guard separately; use Restricted Admin mode for appropriate helpdesk scenarios. Configure Network Level Authentication, trusted TLS certificates, session limits, and required redirection controls, test routine and emergency access, and monitor remote logons and gateway activity.
Possible drawbacks: Gateways, VPNs, MFA services, and secure administrative hosts add licensing, infrastructure, and support dependencies, and their outage can block legitimate administration. Device-redirection restrictions can hinder support workflows, while Network Level Authentication and Remote Credential Guard have compatibility and delegation limitations; a separately secured emergency access path is therefore required.
Documentation: Plan multifactor authentication for Remote Desktop Services | Remote Credential Guard
Enforce least privilege and separate administrative identities
Least privilege limits each identity and session to the minimum actions required for its task. Separating standard and privileged accounts constrains the damage caused by phishing, token or password theft, malicious insiders, vulnerable administrative tools, and compromised lower-trust devices, while reducing opportunities for privilege escalation and persistence.
Give administrators standard user accounts for routine work and separate privileged accounts for administrative duties. Minimize membership of local Administrators, Domain Admins, Enterprise Admins, and other powerful groups; review membership and assigned user rights regularly; and prevent highly privileged identities from signing in to lower-trust servers and workstations.
Use Just Enough Administration endpoints, Windows Admin Center role-based access control, and time-limited elevation where possible. Delegate specific tasks rather than granting unrestricted interactive or PowerShell access, and maintain separately protected emergency accounts for identity-service outages.
Implementation steps: Inventory privileged human accounts, service principals, managed identities, service and automation credentials, scheduled tasks, local group membership, duties, and logon locations. Create separate standard and administrative identities, remove unnecessary standing memberships, delegate tasks through role groups, JEA endpoints, Windows Admin Center RBAC, or time-limited elevation, restrict high-tier logons to secured administrative hosts, test that each role can perform its approved duties, and monitor privileged-group, role, automation, and emergency-account use.
Possible drawbacks: Designing roles, JEA endpoints, approval processes, and time-limited access requires ongoing engineering and governance. Excessively narrow delegation can delay troubleshooting or incident response, while separate accounts add friction for administrators, so permissions should be tested against real duties and emergency access should remain tightly controlled but usable.
Documentation: Just Enough Administration | Windows Admin Center user access options | Enterprise access model
Deploy Windows LAPS for local administrator credentials
Windows LAPS replaces shared or manually maintained local administrator passwords with unique, random, automatically rotated credentials. It mitigates password reuse, pass-the-hash attacks, credential dumping, and broad lateral movement in which compromise of one server's local administrator credential grants access to many others.
Use Windows Local Administrator Password Solution to assign a unique, random, automatically rotated local administrator password to every server. The backup destination depends on join state: Active Directory-only devices can use only Active Directory, Microsoft Entra-only devices can use only Microsoft Entra ID, and hybrid-joined devices can use either destination but not both simultaneously. Tightly restrict and audit password retrieval, configure password history and post-authentication rotation, and monitor policy-processing failures.
Never reuse a common local administrator password across servers because one compromised password or hash can enable broad lateral movement. OSConfig provides the LAPS/WindowsServer/2025/MemberServer scenario for member servers. Workgroup systems can be managed through LAPS for Azure Arc, which Microsoft currently documents as a preview feature. On domain controllers, use Windows LAPS to manage the Directory Services Restore Mode password where appropriate.
Implementation steps: Select the password-backup destination permitted by the device's join state, prepare Active Directory or Microsoft Entra ID, and identify the local account to manage. For workgroup systems, evaluate the operational and support implications of the preview LAPS for Azure Arc service before adoption. Configure password length, complexity, age, history, and post-authentication actions through policy or OSConfig; configure DSRM password management for applicable domain controllers; delegate password read and reset permissions to a small approved group; pilot the policy; verify password backup and rotation; test authorized recovery; and monitor LAPS processing and retrieval events.
Possible drawbacks: LAPS introduces directory, policy, permissions, auditing, and recovery dependencies that must be designed correctly. Scripts or applications that rely on a fixed local password can fail, password rotation can disrupt active sessions or automation, and overly broad rights to retrieve stored passwords can create a new privileged credential repository for attackers to target.
Documentation: What is Windows LAPS? | OSConfig Windows LAPS scenario | LAPS for Azure Arc
Replace static service-account passwords with managed service accounts
Managed service accounts replace human-managed, long-lived service passwords with complex credentials that Active Directory changes automatically. This reduces exposure to password theft, reuse, weak password selection, expired credentials, secrets embedded in scripts, and persistence based on service accounts whose passwords are rarely rotated.
Use group managed service accounts for supported Windows services, scheduled tasks, and application pools in Active Directory environments. gMSAs provide automatic password management and reduce the need to store or manually rotate long-lived service credentials.
Windows Server 2025 also introduces delegated Managed Service Accounts for supported migrations from traditional service accounts. A dMSA binds authentication to approved machine identities, uses managed randomized keys, and disables use of the original service-account password. dMSA deployment requires a discoverable Windows Server 2025 domain controller, and an existing gMSA can't be migrated to a dMSA.
Grant each gMSA only the logon rights, resource permissions, and password-retrieval scope it requires. Do not make service accounts members of privileged groups unless unavoidable, prohibit interactive sign-in, remove obsolete accounts promptly, and monitor changes to the hosts permitted to retrieve each managed password.
Implementation steps: Inventory service identities and application dependencies, then select a gMSA for supported services that can directly use a managed account or evaluate a dMSA for a supported Windows Server 2025 migration from a traditional service account. For a gMSA, confirm Active Directory and key-distribution prerequisites, limit which hosts may retrieve its password, assign only required logon rights, permissions, and service principal names, install and test the account on approved hosts, migrate the service or task, and disable or remove the former static-password account. For a dMSA, confirm a discoverable Windows Server 2025 domain controller and follow the documented migration and rollback process.
Possible drawbacks: Managed service accounts depend on Active Directory and are not supported by every application, installer, or cross-platform workload. Migration can involve service-principal-name, delegation, permission, and clustering changes, while an overly broad password-retrieval scope allows additional hosts to use the identity. dMSA also requires Windows Server 2025 domain-controller availability and has migration rules that differ from gMSA, so compatibility, rollback, and access boundaries require careful testing.
Documentation: Secure group managed service accounts | Delegated Managed Service Accounts overview | Delegated Managed Service Accounts FAQ
Protect credentials and phase out legacy authentication
Credential isolation and modern authentication reduce the value of secrets that an attacker can extract or relay. Credential Guard, LSA protection, Kerberos AES, and retirement of weak authentication mitigate memory scraping, pass-the-hash, pass-the-ticket, NTLM relay, downgrade attacks, and cracking of obsolete password representations.
Verify that Credential Guard and Local Security Authority protection are active where hardware and workload compatibility permit. Windows Server 2025 enables Credential Guard by default on eligible domain-joined systems that aren't domain controllers, but the state should still be verified and centrally enforced where required. Use Negotiate with Kerberos and modern AES encryption for domain authentication, prevent storage of LM hashes or reversibly encrypted passwords, and keep delegated credentials non-exportable. NTLMv1 is removed in Windows Server 2025, and deprecated NTLMv2 should be treated only as a temporary compatibility fallback rather than an end state.
Audit NTLM and other legacy authentication dependencies before restricting or disabling them, then remove those dependencies in a controlled sequence. Do not disable legacy protocols blindly on production servers, but do not leave them enabled indefinitely solely because their consumers have not been inventoried.
Implementation steps: Confirm hardware and driver support, verify the default Credential Guard state, and use OSConfig or centrally managed policy to enforce Credential Guard and LSA protection where required. Enable NTLM auditing, inventory clients and services using legacy authentication, configure Negotiate and Kerberos AES, update affected service accounts, remediate dependencies, assign an owner and retirement date to every NTLMv2 exception, introduce NTLM restrictions in stages, and monitor authentication failures before broader enforcement.
Possible drawbacks: Virtualization-based credential protection requires compatible hardware and can have a workload-dependent performance or compatibility impact. Legacy devices, applications, trusts, or service configurations may still depend on NTLM or weaker cryptography, and disabling them without complete auditing can cause widespread authentication failures or outages.
Documentation: Credential Guard overview | OSConfig baseline credential protections | Deprecated Windows Server features
Harden SMB and file-server access
SMB hardening protects Windows file sharing and related management traffic against protocol downgrade, relay attacks, on-path tampering, brute-force authentication, guest access, data disclosure, and exploitation of obsolete implementations such as SMBv1. Signing verifies message integrity, while encryption protects sensitive content in transit.
Remove SMBv1, prevent insecure guest logons, retain and verify the Windows Server 2025 default requirement for inbound and outbound SMB signing, use SMB encryption for sensitive or untrusted network paths, and use SMB 3.x for modern file services. Treat any relaxation of signing for an incompatible third-party device as a documented, isolated, and time-bound exception. Windows Server 2025 also provides SMB authentication rate limiting and stronger signing and encryption capabilities that should be retained unless a documented compatibility requirement exists.
Restrict TCP port 445 to approved clients and servers, apply share and NTFS permissions according to least privilege, enable access-based enumeration where appropriate, and audit access to sensitive shares. Do not publish traditional SMB directly to the internet; use a supported secure access design such as SMB over QUIC when its requirements and threat model fit.
Implementation steps: Inventory SMB clients, servers, protocol versions, shares, and access requirements, then remove SMBv1 and insecure guest access. Verify that inbound and outbound signing remain required, document and isolate any temporary third-party compatibility exception, configure encryption, authentication rate limiting, and firewall scope according to the workload, review share and NTFS permissions, pilot changes with older clients and high-throughput workloads, and monitor SMB security, authentication, and performance events after enforcement.
Possible drawbacks: Mandatory SMB signing and encryption consume processor resources and can reduce throughput or increase latency on demanding file workloads. Older storage appliances, scanners, applications, or clients might not support modern SMB requirements, and overly restrictive port or permission changes can disrupt file access, administration, Group Policy, or backup operations.
Documentation: SMB security hardening | Secure SMB traffic in Windows Server
Require modern TLS and manage certificates securely
Modern TLS protects application and management traffic by authenticating endpoints and encrypting data in transit. Requiring current protocol versions, strong cipher suites, and trusted certificates mitigates eavesdropping, man-in-the-middle attacks, protocol downgrade, weak-cryptography attacks, and impersonation using invalid or compromised certificates.
Require TLS 1.2 or later and prefer TLS 1.3 where the application stack supports it. Windows Server 2025 disables TLS 1.0 and TLS 1.1 by default; verify that these protocols and obsolete SSL versions remain disabled and prevent unauthorized re-enablement. Disable weak cipher suites and obsolete hashes through a tested baseline rather than ad hoc registry changes. Inventory old agents, middleware, and network appliances first so incompatible dependencies can be upgraded instead of becoming permanent exceptions.
Use certificates from a trusted public or enterprise certification authority, protect private keys with restrictive access control, select appropriate key sizes and algorithms, monitor expiration, and automate renewal. After dependency review, remove expired, untrusted, orphaned, or unnecessary certificates from server stores.
Implementation steps: Inventory listening services, clients, protocol versions, cipher dependencies, and installed certificates, then replace weak or expiring certificates and confirm application support for modern TLS. Verify that TLS 1.0 and TLS 1.1 remain disabled, apply tested Schannel or OSConfig settings in stages, disable other legacy protocols and weak ciphers, validate every client and integration, rescan the endpoints, remove only certificates confirmed to be unnecessary, and implement automated certificate enrollment, renewal, expiration alerting, and private-key access review.
Possible drawbacks: Disabling old protocols and ciphers can break legacy clients, middleware, monitoring agents, or network devices with no modern TLS support. Certificate issuance, private-key protection, renewal automation, and revocation checking add operational complexity, and an expired or incorrectly deployed certificate can cause a complete service outage.
Documentation: TLS/SSL and Schannel overview | OSConfig baseline protocol protections | Deprecated Windows Server features
Encrypt operating-system and data volumes with BitLocker
BitLocker encrypts data at rest so possession of a disk or offline copy does not provide immediate access to its contents. It mitigates data theft from lost or stolen servers, removed drives, improperly decommissioned hardware, offline password-reset attacks, and attempts to read files by booting an alternate operating system.
Enable BitLocker on operating-system and data volumes, using TPM-backed protectors and additional startup authentication where the physical threat model and availability requirements justify it. Use virtual TPMs and supported host or cloud protections for virtual machines. Encryption protects data on removed drives, decommissioned hardware, stolen systems, and offline copies.
Escrow recovery information in a protected, recoverable directory or management service before enforcement. Limit access to recovery keys, audit retrieval, include key recovery in incident procedures, and test recovery on representative systems so encryption does not become an availability risk.
Implementation steps: Inventory operating-system and data volumes, confirm TPM or virtual TPM readiness, select protectors that meet the physical and availability threat model, and configure a protected recovery-key escrow location. Enable BitLocker in controlled stages, verify encryption and key backup, test normal reboot and recovery scenarios, document break-glass procedures, and continuously monitor encryption and protector compliance. Suspend protection for firmware or boot-chain maintenance only through an approved procedure, then verify that BitLocker protection resumes afterward.
Possible drawbacks: Lost recovery material can make encrypted data permanently inaccessible, while firmware, TPM, boot, or hardware changes can unexpectedly trigger recovery. Encryption can add some performance and operational overhead, and startup PINs can conflict with unattended reboot requirements, so protector selection, key escrow, and recovery testing must reflect the server's availability needs.
Documentation: BitLocker planning guide | BitLocker operations guide | BitLocker recovery overview
Configure detailed auditing and protect local logs
Detailed auditing records security-relevant activity so suspicious behavior can be detected, investigated, and attributed. Authentication, privilege, process, PowerShell, policy, and firewall logs help expose brute-force attempts, credential misuse, privilege escalation, persistence, defense evasion, and attacker efforts to alter system configuration.
Enable advanced audit policy for successful and failed logons, credential validation, account and group changes, sensitive privilege use, process creation with command-line capture, policy changes, removable storage, file shares, firewall activity, and other events relevant to the server role. The OSConfig baseline enables a broad audit configuration and increases important log sizes to improve forensic coverage.
Enable PowerShell module and script block logging, and use protected event logging where appropriate because command content can contain sensitive data. Increase log capacity and retention for the expected event volume, restrict permissions to clear or modify logs, monitor audit-policy changes, and synchronize time with trusted sources.
Implementation steps: Define the activities and events required for detection, investigation, and compliance, then apply advanced audit policy through OSConfig or Group Policy. Enable process command-line and PowerShell logging, measure event volume during a representative pilot, size and protect each log and forwarding path from the observed rates, configure trusted time synchronization, generate representative test events to confirm collection, and review event volume, retention, and policy health regularly.
Possible drawbacks: Detailed auditing can generate large volumes of events, consume storage and processing resources, and overwhelm analysts with noise if collection isn't tuned. Command-line and PowerShell logs can contain credentials or other sensitive data, while undersized logs may overwrite useful evidence, so access, retention, filtering, and capacity require deliberate design.
Documentation: OSConfig baseline auditing and visibility | Recommended audit policy for Windows Event Forwarding | PowerShell logging on Windows
Centralize security telemetry and alert on suspicious activity
Centralized telemetry moves evidence away from the system that generated it and correlates activity across servers, identities, and networks. This improves detection of distributed attacks, limits an intruder's ability to erase local evidence, and shortens response time for credential attacks, lateral movement, persistence, defense evasion, and destructive actions.
Forward security-relevant logs away from each server using Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM such as Microsoft Sentinel, or another protected collection platform. Include Security, System, Windows Defender, PowerShell, Code Integrity, Windows Firewall, Windows LAPS, and role-specific operational logs.
Create actionable alerts for repeated authentication failures, new or changed administrators, unexpected service or scheduled-task creation, security-control changes, Defender detections, App Control blocks, log clearing, unusual remote administration, and backup deletion. Restrict access to collectors and retention systems so an attacker who compromises a server cannot erase the centralized evidence.
Implementation steps: Select Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM, or a combination; define prioritized detection use cases and role-specific retention before selecting log channels and verbosity; design resilient collectors, access control, and capacity; and deploy the required agents or subscriptions. Onboard the prioritized channels, verify end-to-end ingestion and timestamps, create and test high-value detections and notifications, restrict access to the monitoring platform, and continuously monitor collection health and tune noisy rules.
Possible drawbacks: Central collection introduces bandwidth, storage, ingestion, licensing, retention, and analyst costs and can expose sensitive operational data if the monitoring platform is poorly secured. Collector failures create visibility gaps, while poorly tuned rules produce false positives and alert fatigue, so the design needs resilience, health monitoring, access controls, and continuous tuning.
Documentation: Use Windows Event Forwarding for intrusion detection | Microsoft Defender for Endpoint security capabilities
Maintain ransomware-resilient backups and test recovery
Ransomware-resilient backups preserve a trustworthy recovery path when production data, operating systems, or identity services are encrypted, deleted, or corrupted. Isolated and immutable copies mitigate ransomware, destructive administrators, compromised backup credentials, accidental deletion, hardware failure, and attacks intended to eliminate both systems and their recovery data.
Keep multiple protected backup copies, including a copy that is offline, immutable, or otherwise isolated from normal server and domain administrator credentials. Use separate backup administration identities, multifactor authorization for destructive operations, encryption, soft delete or immutability controls, and alerts for policy changes or mass deletion. Hypervisor snapshots alone are not an adequate backup strategy.
Back up application data and configuration as well as system state and bare-metal recovery data where required by the server role. Define recovery-point and recovery-time objectives, test file, application, system-state, and full-server restoration regularly, and record the evidence. Domain controllers, certificate authorities, and other identity infrastructure require workload-aware recovery procedures.
Implementation steps: Classify workloads and define recovery-point and recovery-time objectives, then select local, offsite, offline, and immutable backup targets appropriate to the risk. Use separate backup identities and MFA, schedule application data, configuration, system-state, and bare-metal backups as required, enable encryption and deletion protections, and monitor every job and policy change. Perform regular isolated restore tests that verify application consistency and role-specific recovery semantics for identity systems, not only successful restoration of files or virtual disks, and maintain documented recovery runbooks.
Possible drawbacks: Multiple isolated copies, immutable storage, long retention, and regular restore exercises increase storage, network, licensing, staffing, and operational costs. Backups can create false confidence when they are incomplete, stale, infected, or untested, and strong credential separation can slow routine administration, so restore validation and lifecycle management are as important as backup creation.
Documentation: Design a ransomware-resilient backup architecture | Azure Backup security best practices | Back up Windows Server system state
---
This isn't everything you can do, but it's a start. What other techniques do you use to harden your Windows Server deployments?
