Windows Failover Cluster Security: Protect Cluster Identities, Networks and Storage

A Windows Server failover cluster concentrates the most valuable workloads, Hyper-V hosts, SQL Server instances and file servers, onto a few nodes that share identities, networks and storage, so one misconfigured setting exposes all of them. Clusters are built for availability, and several of their security settings default to compatibility: intra-cluster storage traffic for Cluster Shared Volumes (CSV) and Storage Spaces Direct (S2D) is sent in clear text by default, and the cluster name object (CNO) is often given more Active Directory rights than it needs. This guide covers the cluster-specific layer: CNO and virtual computer object (VCO) accounts, cluster administration, cluster network roles, signing and encryption of cluster and storage traffic, BitLocker on CSV, logging and a hardening baseline. It applies to Windows Server 2016 to 2025 and is for Windows platform, virtualisation and identity engineers. Hardening of each node's operating system is in the Windows Server Hardening Guide and is not repeated here.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The CNO is a machine identity with delegated AD rights. It creates VCOs for clustered roles, so prestage it in a dedicated OU, protect it from deletion and scope its Create Computer objects right to that OU only.
• Encrypt storage traffic deliberately. Cluster communication is signed by default (SecurityLevel 1), but CSV and S2D storage bus traffic defaults to clear text; set the storage security level to signed or encrypted, knowing that SMB encryption disables RDMA.
• Keep cluster networks private. Use network role 1 (cluster only) for storage, live migration and heartbeat networks, role 3 only where clients must connect, and role 0 for networks the cluster should ignore, such as iSCSI.
• Protect data at rest with BitLocker on CSV. Add the CNO-based ADAccountOrGroup protector or use the cluster-managed protector, encrypt each node's system volume too, and escrow recovery keys outside the cluster.
• Clusters no longer need NTLM. Since Windows Server 2019, failover clustering uses Kerberos and certificates only, so clusters can run where NTLM is blocked.

How identity and access work in a failover cluster

A cluster has more identities than its node count suggests. Each node has its own computer account; the cluster has a CNO; each clustered role with a client access point has a VCO; and a local account, CLIUSR, together with certificates, lets nodes form the cluster even when no domain controller is reachable. Since Windows Server 2019 the cluster uses Kerberos and certificate-based authentication exclusively, with no NTLM dependency.

Prestaging the CNO and VCOs

Prestaging lets a cluster administrator create a cluster without holding Create Computer objects on the OU, and gives domain administrators control over naming and placement. Microsoft's procedure is:

1. Create a dedicated OU for cluster objects (Domain Admins or equivalent).
2. Create a computer object with the cluster name, tick Protect object from accidental deletion, and disable the account so cluster creation can confirm the name is unused.
3. Grant the user or group creating the cluster Full control on that CNO.
4. Choose how VCOs are created: either grant the CNO Create Computer objects on the cluster OU (Applies to: This object and all descendant objects), or prestage each VCO in that OU, protect it and grant the CNO Full control. Prestaging VCOs suits organisations that want to control which roles can be created.

If the CNO sits in the default Computers container, it can create up to 10 VCOs without extra configuration, which is a reason to move cluster objects into their own OU where rights are explicit. Review the OU's ACL with the same discipline as any delegation; see the Active Directory Delegation guide.

Admin roles and privileged access

• Who is a cluster administrator: full control on the cluster is granted through the cluster security descriptor, and node local administrators have it. Keep node local Administrators to a dedicated cluster admin group plus break-glass, managed with LAPS for the local account; see the LAPS Guide.
• Tiering: a cluster that hosts domain controllers, or Hyper-V clusters that run tier zero virtual machines, is tier zero, and so is anyone who can administer it. Apply the Tiered Administration and Enterprise Access Model Guide.
• Management tools: Failover Cluster Manager and the FailoverClusters PowerShell module run over WinRM and RPC. If you use Windows Admin Center, note that its RBAC roles are not supported for cluster management where CredSSP-dependent features are needed, and that its Updates tool for Cluster-Aware Updating uses CredSSP. See Windows Admin Center Security.
• Privileged access workstations: administer clusters from a privileged access workstation, not from a node itself or a general purpose desktop.
• Virtual machine administrators: on Hyper-V clusters, separate people who manage guest workloads from people who manage hosts; host administrators can read every guest's disk. The Hyper-V Security Guide covers host-level controls.

Integrations, API tokens and service accounts

Clusters run workloads that bring their own service identities, and the cluster itself holds secrets.

• Clustered role service accounts: SQL Server failover cluster instances and other clustered services need an account valid on every node. Prefer group managed service accounts, which every node can retrieve, over shared passwords; see the gMSA Guide. Service principal names on these accounts are Kerberoasting targets (T1558.003) if a password-based account is used.
• Witness: a file share witness or cloud witness is part of quorum. A cloud witness uses a storage account access key, which is a secret to store, rotate and restrict. File share witnesses on DFS Namespaces shares are blocked since Windows Server 2019; host the share on a server outside the cluster with access limited to the CNO.
• BitLocker recovery material: recovery passwords and .BEK key files are secrets. Escrow them in AD or a vault outside the cluster; a .BEK file copied to a share for provisioning should be removed from that share afterwards, as Microsoft notes.
• Backup and replication agents: backup software that protects CSVs typically runs with high rights on every node. Isolate its identity from the cluster admin identity; see the Backup Identity Isolation Guide.
• Cluster-Aware Updating: CAU adds an updating role and runs updates with administrative rights across nodes. Treat its configuration as privileged and control where its update sources and any hotfix share live.

Cluster networks and traffic protection

Each cluster network has a role that decides what the cluster uses it for. Microsoft's overview recommends dedicated private networks for heartbeat and cluster traffic, separate from client networks.

The value 2 (client access only) is not supported. Check roles with Get-ClusterNetwork after every network change, because a new adapter can be picked up with a role you did not intend.

Microsoft's Failover Clustering team announced the storage property as SecurityLevelToStorage, and readers report the name on current builds as SecurityLevelForStorage; list the properties with Get-Cluster | Format-List * on your build before scripting. Encryption over SMB disables RDMA, so on RDMA-based S2D fabrics measure the impact first. Since Windows Server 2019, intra-cluster SMB for CSV and S2D uses certificates (cluster hardening), which protects authentication even where you leave traffic signed rather than encrypted. Unencrypted storage traffic on a shared network invites interception (T1040, T1557); a non-routed, cluster-only VLAN is the first control, encryption the second.

Encrypting data at rest on CSV and S2D

BitLocker supports physical disk resources and CSV 2.0 volumes on Windows Server 2016 to 2025, on NTFS. Two protector models exist.

1. Plan maintenance: enabling BitLocker on an existing CSV needs the resource in maintenance mode (Suspend-ClusterResource), which stops roles using the volume.
2. Encrypt before adding: volumes must be encrypted, or have started encryption, before they are added to CSV.
3. Add the protector: use PowerShell or manage-bde; the Control Panel does not show CSV mount points or offer the AD protector.
4. Escrow recovery: add a recovery password, store it outside the cluster, and record the protector ID.
5. Protect system volumes: with the cluster-managed protector, an unencrypted system volume weakens the scheme; Event 1824 warns of exactly this.
6. Test recovery: practise bringing a disk online with Start-ClusterPhysicalDiskResource and a recovery password or key file before you need it.

Microsoft documents CSV and physical disk resources; check current S2D guidance for your version before applying the same steps to S2D volumes. General BitLocker design is in the BitLocker guide.

Logging and detection

Cluster events are written to the Microsoft-Windows-FailoverClustering/Operational channel on each node, alongside the System and Security logs. The detailed cluster debug log is controlled by the ClusterLogLevel and ClusterLogSize properties.

Forward these channels to the SIEM from every node; see the Active Directory Security Monitoring and Event IDs Guide for the AD side.

Metrics:

• Percentage of clusters with storage security level 1 or 2.
• Percentage of CSVs with BitLocker enabled and recovery keys escrowed outside the cluster.
• Clusters whose CNO and VCOs are in a dedicated OU with explicit rights (target: all).
• Number of members in each cluster's admin group and node local Administrators.
• Cluster networks carrying storage or live migration traffic with role 3 (target: zero).

Hardening baseline

1. AD objects: dedicated OU, prestaged and protected CNO, Create Computer objects scoped to that OU, VCOs prestaged where naming control matters.
2. Admins: dedicated cluster admin group, LAPS on nodes, administration from privileged access workstations, tier aligned to the workloads hosted.
3. Networks: non-routed VLANs with role 1 for cluster, storage and live migration; role 0 for iSCSI; role 3 only for management and clients.
4. Traffic protection: SecurityLevel 1 or 2, storage security level 1 or 2 after performance testing.
5. Authentication: block or audit NTLM on nodes, since clusters from Windows Server 2019 do not need it; see the Kerberos Security Guide.
6. At rest: BitLocker on CSVs and on node system volumes, recovery keys escrowed outside the cluster.
7. Service identities: gMSAs for clustered services, witness secrets rotated, backup identity isolated.
8. Logging: FailoverClustering/Operational, Security and PowerShell logs forwarded from every node.

Rollout and rollback: make changes on a test cluster first, then one production cluster at a time in a maintenance window. Storage security level changes affect CSV performance immediately, so record baseline IOPS and latency, change the value, measure, and set it back with the same property if the impact is unacceptable. BitLocker changes need maintenance mode; plan role downtime. Network role changes take effect at once, so confirm heartbeat paths before removing a network from cluster use.

Small vs large estates: a two-node cluster in a branch office gains most from steps 1, 2 and 6 plus a cloud or file share witness under control. Large Hyper-V or S2D estates should script the baseline, check it with cluster validation and configuration drift reports, and give storage encryption a performance budget at design time rather than retrofitting it.

Common misconfigurations

• Storage traffic left in clear text: the storage security level defaults to 0, so CSV redirected I/O and S2D traffic cross the network unprotected unless someone changes it.
• CNO with broad rights: granting the CNO Create Computer objects on a large OU, or leaving it in the Computers container, widens what a compromised cluster can create in AD.
• Storage or live migration on a client network: role 3 on a network that carries storage traffic exposes it to every client on that segment.
• BitLocker recovery keys only inside the cluster: if the cluster database is lost, so is access to the volumes.
• Shared admin accounts across nodes: one password on every node means one theft compromises the cluster; use LAPS and named accounts.
• Backups reachable from cluster admin accounts: ransomware operators who gain cluster admin go after snapshots and backups next; keep recovery outside that blast radius, as in the Backup Security and Immutable Backup Guide.

Framework mapping

Practitioner checklist

• Move CNOs and VCOs into a dedicated, protected OU and scope the CNO's Create Computer objects right to it.
• Create a dedicated cluster admin group and remove broad groups from node local Administrators.
• Set cluster network roles: 1 for cluster, storage and live migration, 0 for iSCSI, 3 only for clients.
• Confirm SecurityLevel and raise the storage security level to signed or encrypted after testing.
• Enable BitLocker on CSVs and node system volumes and escrow recovery keys outside the cluster.
• Run clustered services under gMSAs and rotate witness secrets.
• Block or audit NTLM on Windows Server 2019 and later nodes.
• Forward FailoverClustering/Operational, Security and PowerShell logs from every node.
• Test BitLocker recovery and backup restore for a CSV at least yearly.

Standards and references

• Microsoft Learn: Prestage Cluster Computer Objects in Active Directory Domain Services
• Microsoft Learn: Protect Cluster Shared Volumes and Storage Area Networks with BitLocker
• Microsoft Learn: BitLocker on Cluster Shared Volumes
• Microsoft Failover Clustering Blog: Security Settings for Failover Clustering
• Microsoft Learn: CLUSTER_NETWORK_ROLE Enumeration
• Microsoft Learn: MSCluster_Cluster Class
• Microsoft Learn: Failover Clustering Overview
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Windows Server Hardening Guide · Hyper-V Security Guide · Group Managed Service Accounts (gMSA) Guide · BitLocker · Windows Admin Center Security