Security guide

1. Introduction and Scope

Purpose, audience, conventions, and shared responsibilities

1.1 Purpose and Audience

Cayosoft Guardian plays a critical role in managing and protecting organizational Active Directory infrastructure. It collects AD data, detects unauthorized changes, and enables comprehensive forest recovery. Given this privileged position, robust security practices are essential to safeguard against data breaches, unauthorized access, and operational disruptions. This document provides security guidance for all parties involved in deploying and operating Cayosoft Guardian:

• Security teams — responsible for approving the Cayosoft Guardian deployment posture, reviewing audit controls, and responding to security events.
• System administrators — responsible for configuring, patching, and maintaining Cayosoft Guardian servers and supporting infrastructure.
• Compliance and audit teams — using this document to assess alignment with applicable regulatory and internal frameworks.

This guide covers identity and access management, network security, data encryption, infrastructure hardening, patching, logging, backup protection, incident response, and compliance baseline configuration.

1.2 Document Conventions

This document uses the following requirement language, consistent with RFC 2119:

References to external standards, such as “NIST 800-53 AC-2,” are provided for traceability. Where a control maps to multiple frameworks, the most commonly applicable one is cited.

1.3 Compliance Frameworks Covered

The security controls in this document are aligned with the following frameworks. Organizations SHOULD map applicable sections to their own control libraries.

• NIST SP 800-53 Rev 5 — Security and privacy controls for information systems.
• NIST SP 800-171 — Protecting Controlled Unclassified Information.
• CIS Benchmarks — Windows Server and SQL Server hardening.
• SOC 2 Type II — Security, Availability, and Confidentiality trust service criteria.
• ISO/IEC 27001:2022 — Information security management systems.
• PCI DSS v4.0 — For environments processing cardholder data.
• STIG — DoD hardening standards for Windows and SQL Server.

1.4 Security Posture and Tier 0 Classification

Cayosoft Guardian is an identity security and recovery platform with direct visibility into, and control over, the Active Directory and cloud identity control plane. Due to the sensitivity of the data it processes and the impact of the operations it can perform, Cayosoft Guardian and its supporting infrastructure MUST be treated as Tier 0 assets under the Microsoft Enterprise Access Model.

Tier 0 assets are systems that directly or indirectly control identity, authentication, authorization, or recovery of directory services. Compromise of a Tier 0 system results in full domain or tenant compromise.

Cayosoft Guardian Tier 0 components include, but are not limited to:

• Cayosoft Guardian application servers
• Supporting SQL Server or Azure SQL infrastructure
• Forest Recovery agents and recovery orchestration services
• Backup storage access paths and recovery site infrastructure

As Tier 0 assets, Cayosoft Guardian components MUST be protected with the same security rigor applied to domain controllers and identity control plane systems.

2. Identity and Access Management

Authentication, authorization, privileged access, and session controls

2.1 Authentication Methods

Cayosoft Guardian supports multiple authentication methods to meet the needs of enterprises of all sizes, from small organizations to highly regulated federal agencies. Authentication is configured under Settings > Service Settings > Authentication Settings.

At least one authentication method must remain enabled at all times to prevent administrator lockout. Cayosoft Guardian enforces this constraint in the UI.

2.1.1 Phishing-Resistant Multi-Factor Authentication

All administrative access to the Cayosoft Guardian portal and Cayosoft Guardian Tier 0 infrastructure MUST be protected using phishing-resistant multi-factor authentication.

Phishing-resistant MFA uses cryptographically bound authentication mechanisms that cannot be replayed or intercepted by adversary-in-the-middle attacks. This is a mandatory requirement for Tier 0 systems.

Supported phishing-resistant authentication methods include:

• FIDO2 security keys
• Windows Hello for Business using key-based authentication
• Certificate-based authentication
• Microsoft Entra ID Authentication Strength policies enforcing phishing-resistant MFA

The following authentication methods DO NOT meet the phishing-resistant MFA requirement and SHOULD NOT be used for Cayosoft Guardian administrative access:

• SMS-based and voice call MFA
• One-time passcodes without cryptographic binding
• Push-only MFA without phishing-resistant enforcement

Organizations using Entra ID authentication SHOULD enforce phishing-resistant MFA using Conditional Access Authentication Strength policies and SHOULD additionally require compliant or hybrid-joined devices.

Failed authentication alerting: Cayosoft Guardian's Threat Detection engine includes built-in rules that monitor for repeated failed authentication attempts, including brute force (CTD-000106, CTD-000107), Kerberos enumeration (CTD-000108, CTD-000110), NTLM failures from invalid users (CTD-000118), and failures against privileged accounts (CTD-000124). These rules are disabled by default due to potential load in large environments and SHOULD be enabled in environments actively monitoring for brute force or password spraying.

2.2 Role-Based Access Control

Cayosoft Guardian implements a granular Role-Based Access Control (RBAC) model enabling organizations to delegate permissions with precision. Six built-in roles can be assigned individually or in combination to any user or group under Settings > Delegation.

Notably, Forest Recovery initiation is restricted to Global Administrator only. Operators and readers cannot trigger recovery operations. This separation ensures that the most destructive capability in the product is protected by the highest access tier.

Principle of least privilege: Assign the most restrictive role that meets each user's operational need. A security analyst monitoring threats requires only Threat Alerts Reader. A SOC operator needs Threat Detection Operator. Only system administrators managing the full platform require Global Administrator.

gMSA service accounts: Group Managed Service Accounts (gMSA) are created for each domain or partition managed by the Cayosoft Guardian service. These accounts are used to collect Active Directory data and security log events from domain controllers. Cayosoft Guardian supports both read-only gMSA and admin gMSA models, depending on whether rollback is required.

Key requirements:

• Read-only gMSA accounts MUST NOT be granted permissions beyond those required for data collection.
• gMSA account membership in administrative groups MUST be reviewed periodically.
• For event log collection, the gMSA account must be a member of Remote Management Users and Event Log Readers groups on domain controllers, and ADSyncOperators on Entra Connect instances (on DCs: AD group; on member servers: local groups ADSyncOperators and Remote Management Users).

Two-tier gMSA model: Cayosoft Guardian supports two gMSA types with different privilege levels:

Built-in gMSA security settings:

• Password rotation: every 7 days, managed automatically by Active Directory; no manual rotation required.
• Kerberos encryption: AES-256 only.
• Account delegation: disabled.
• Allowed principals: limited to computer accounts where Guardian is installed.

JIT elevation for rollback: When a rollback operation requires elevated rights, the Guardian delegated admin provides credentials for a privileged AD account to temporarily add the gMSA to the appropriate admin group, specifically Domain Admins, Enterprise Admins, or Schema Admins, depending on the change type. Once the rollback is complete, admin rights are immediately revoked from the gMSA.

gMSA and Forest Recovery use separate credential models: gMSA is the connection account model for Change Monitoring and Threat Detection. Forest Recovery uses a different credential model: automatically generated break-glass accounts scoped to the recovery environment. These are two independent features with separate authentication paths; configuring gMSA for Change Monitoring has no effect on Forest Recovery operations. See Section 2.3 and Section 8.4 for break-glass account details.

An error is thrown if the designated privileged account cannot update its membership within the required administrative groups. Monitor Cayosoft Guardian service logs for this error, as it indicates a configuration problem that may affect data collection.

For full configuration details, refer to Using gMSA in Cayosoft Guardian.

Shared administrative accounts MUST NOT be used for Cayosoft Guardian administration. Each administrator MUST have an individual named account to ensure accountability and support forensic investigation.

2.3 Privileged Access Management

Administrative access to Cayosoft Guardian servers and the Cayosoft Guardian portal carries elevated risk due to the product's access to sensitive AD data. The following controls SHOULD be implemented:

Privileged Access Workstations (PAW): Cayosoft Guardian administrators SHOULD perform all administrative tasks from dedicated workstations that are hardened, monitored, and restricted from general-purpose internet browsing and email. This limits the attack surface for credential theft targeting privileged sessions.

Just-in-time (JIT) access: Where a PAM solution or equivalent privileged access control is available, such as Microsoft Entra PIM, CyberArk, or BeyondTrust, administrator access to Cayosoft Guardian SHOULD be granted on-demand with a defined expiration window, rather than as permanent standing access.

Break-glass accounts: During Active Directory Forest Recovery operations, certain Microsoft-mandated actions require elevated credentials. Cayosoft Guardian Forest Recovery handles this through automatically generated, temporary break-glass accounts:

• Customers are not required to store privileged credentials in the product.
• Break glass accounts are created automatically during recovery plan creation.
• A separate break glass account is created in each domain; all receive different UPNs but the same password.
• A secure password is automatically generated and shown only once at plan creation time. It MUST be copied and stored securely by the administrator immediately. The password is not retrievable after the plan is saved.
• Accounts are usable only within the isolated recovery environment.
• Accounts MUST be removed immediately after recovery access is complete.

NOTE: The break-glass account password is displayed only once during recovery plan creation. It cannot be retrieved afterwards. Administrators MUST copy it using the provided copy icon and store it in a secure, offline location, such as a physical safe or an offline password manager, before saving the plan.

Break-glass account configuration can be modified on existing recovery plans: navigate to Forest Recovery > Recovery Plans, select the plan, and click Configure break glass accounts. The feature can be enabled or disabled post-creation. Unchecking Create break glass accounts removes the credentials from the plan and stops them from being used in future deployments.

2.4 Access Lifecycle Management

Cayosoft Guardian access rights MUST be managed across the full user lifecycle to prevent accumulation of unnecessary privileges over time.

Onboarding: Access requests MUST be formally approved and assigned to the minimum required role. Access MUST NOT be provisioned based on verbal requests alone.

Periodic access reviews: All Cayosoft Guardian user accounts MUST be reviewed at least quarterly. Reviews MUST confirm that role assignments remain appropriate for each user's current job function. Accounts for departed employees MUST be disabled or removed within 24 hours of offboarding.

Offboarding: When an administrator leaves the organization or changes roles, their Cayosoft Guardian access MUST be revoked before or on their last active day. Active Entra ID refresh tokens MUST be revoked to invalidate existing portal sessions.

2.5 Session Management

Cayosoft Guardian portal sessions are controlled via the Refresh token lifetime parameter in Settings > Service Settings > Authentication Settings. The out-of-box default session lifetime is 1 day. The configurable maximum is capped at 90 days. Organizations MUST set a session timeout appropriate for a privileged management portal. Cayosoft recommends a maximum of 8 hours for standard administrators and 1–2 hours for highly privileged roles.

Additional session security requirements:

• Sessions MUST time out after a defined period of inactivity.
• Users MUST re-authenticate after session expiry; no silent renewal of privileged sessions.
• Concurrent active sessions from multiple geographic locations SHOULD trigger an alert.

2.6 Microsoft 365 and Entra ID App Registration Security

When Cayosoft Guardian connects to Microsoft 365 services, including Entra ID, Exchange Online, and Teams, it uses application-only authentication via a single-tenant Entra ID app registration. This approach eliminates the need to store or use Global Administrator user credentials for routine operations.

How it works:

• Cayosoft Guardian creates a single-tenant application in Entra ID and a corresponding enterprise application in each managed tenant.
• A certificate credential is generated and securely stored for authentication; no client secrets are used.
• The certificate is automatically rotated every 30 days and can also be manually renewed in the UI.
• This eliminates the need to store, manage, or rotate privileged user credentials in the product.

For Azure-hosted Cayosoft Guardian deployments, System-Managed Identity (also known as Managed Identity) is also supported as an alternative to certificate authentication.

2.6.1 Microsoft Graph API Permissions — Read-Only Mode

The following Graph API application permissions are requested for change monitoring and auditing. Permissions are grouped by the app registration they are granted on.

Additional permissions required for rollback/restore in write mode: When Cayosoft Guardian is configured to perform object rollback or restoration, additional write-scoped permissions are required. These should only be granted if rollback functionality is enabled.

If your Cayosoft Guardian deployment is used for monitoring and threat detection only, not rollback or restoration, grant only the read-only permission set. Write permissions significantly increase the potential damage if the service principal is ever compromised.

Azure RBAC permissions: Cayosoft Guardian's Entra application account requires the Reader role in read-only mode or User Access Administrator role in write mode on the tenant root management group. The User Access Administrator role is required to monitor and restore Azure RBAC role assignments.

Exchange Online: Cayosoft Guardian creates a custom role named Cayosoft View-Only Mail Recipients, derived from the native Mail Recipients role, for read-only mailbox property collection. In write mode, the Entra application account is added to the built-in Organization Management role group. No broader Exchange permissions are requested.

Environment changes — audit transparency: When Cayosoft Guardian onboards a tenant, it automatically applies certain environment prerequisites (enabling Unified Audit Log, creating Exchange customizations, registering the app). All of these changes are recorded in Cayosoft Guardian's internal change tracking system, providing full transparency to security and compliance teams.

Entra ID permissions — least privilege alternative: The Global Administrator role is not a hard requirement for Cayosoft Guardian's Entra ID connection. The following lower-privilege roles can be combined to provide the required access:

Customers can review and approve all Entra ID app registration permissions before deployment via the Entra ID Enterprise Applications blade. The complete and current permission list is documented in Connection Accounts in Cayosoft Guardian.

Azure SQL — passwordless connection: For cloud-hosted deployments using Azure SQL, Guardian supports System-Managed Identity (SMI) authentication, eliminating the need for any SQL username or password in the configuration. This is the recommended approach for Azure VM deployments. See Passwordless Connection for Azure SQL in Cayosoft Guardian.

IMPORTANT: During tenant onboarding, Cayosoft Guardian automatically enables the Microsoft 365 Unified Audit Log if not already enabled. This change cannot be reversed. It is a prerequisite for Guardian's Exchange Online and Teams audit collection. Customers SHOULD be aware of this before initiating tenant onboarding.

Deploy in monitoring / read-only mode initially. Only enable write permissions when rollback or restoration functionality is explicitly required and approved by your security team.

3. Network Security

Zero Trust posture, ports, protocols, TLS, encryption of AD management channels, and segmentation

3.1 Network Security Principles

Because Cayosoft Guardian holds privileged access to Active Directory and cloud identity data, the network hosting Cayosoft Guardian MUST be treated as a high-trust zone requiring strict access controls. Apply the following principles to Cayosoft Guardian deployments:

• Authenticate and authorize every inbound connection to the Cayosoft Guardian portal and Cayosoft Guardian Service; do not rely on network location as an implicit trust signal.
• Restrict outbound connections from Cayosoft Guardian servers to only the destinations required for its operation: domain controllers, SQL, Azure/AWS endpoints, and Cayosoft update servers.
• Treat Cayosoft Guardian servers as high-value targets and apply the same access restrictions as you would to domain controllers: no general-purpose internet browsing, no email clients, no software installations outside of change management.
• Monitor all inbound connections to Cayosoft Guardian servers for anomalous source IPs, unusual access times, and repeated authentication failures.

3.2 Authentication Protocols

Cayosoft Guardian uses Windows authentication to communicate with Active Directory, domain controllers, and supporting services. Because Cayosoft Guardian operates as a high-trust identity security platform, authentication protocols MUST be configured to meet modern security standards and eliminate legacy dependencies wherever possible.

3.2.1 Kerberos Authentication (Required)

When Cayosoft Guardian is deployed using Group Managed Service Accounts (gMSA), Kerberos authentication MUST be used exclusively for all authentication between the Cayosoft Guardian server and Active Directory.

Kerberos provides mutual authentication, ticket-based access, and strong cryptographic protections that align with Zero Trust principles and Microsoft's current security guidance.

Kerberos is the expected and supported authentication protocol for all production Cayosoft Guardian deployments using gMSA. The following conditions MUST be met to ensure Kerberos is used and NTLM fallback does not occur:

• The Cayosoft Guardian server MUST be domain-joined.
• Service Principal Names (SPNs) for the gMSA MUST be correctly registered.
• DNS forward and reverse name resolution MUST function correctly.
• Time synchronization between the Guardian server and domain controllers MUST be within Kerberos tolerance.
• Network connectivity to domain controllers MUST allow Kerberos traffic.

When these conditions are met, NTLM authentication is not required for Guardian operations.

3.2.2 Validation and Monitoring

Organizations SHOULD validate Kerberos usage by monitoring authentication events on domain controllers. Kerberos ticket activity should be observed, and NTLM authentication events SHOULD NOT be present for Guardian service activity.

Any NTLM authentication originating from the Guardian server MUST be treated as a configuration defect and investigated immediately.

3.2.3 NTLM Authentication (Exception Only)

NTLM authentication is a legacy protocol that lacks mutual authentication and is vulnerable to relay and credential-theft attacks. Microsoft has deprecated NTLM and is actively encouraging its removal from enterprise environments.

NTLM is not required and not recommended for Cayosoft Guardian deployments that use gMSA.

The presence of NTLM authentication in a gMSA-based Cayosoft Guardian deployment indicates one or more of the following:

• SPN misconfiguration
• DNS or name resolution issues
• Time synchronization problems
• Improper service account configuration
• Environmental constraints that prevent Kerberos from functioning

These conditions MUST be remediated. NTLM MUST NOT be accepted as a permanent or supported fallback for Guardian authentication when gMSA is in use.

3.2.3.1 Limited NTLM Scenarios

NTLM may be observed only in specific, constrained scenarios outside the Cayosoft Guardian server's primary authentication path, such as:

• Backup or recovery agents operating across non-trusted forests
• Legacy environments where Kerberos prerequisites cannot be met

These scenarios SHOULD be treated as transitional and SHOULD NOT represent the target-state security posture for Guardian.

3.2.4 NTLM Restriction and Hardening Guidance

Organizations deploying Cayosoft Guardian SHOULD actively restrict NTLM usage on Guardian servers:

• Enable NTLM auditing to identify legacy usage.
• Restrict outgoing NTLM authentication from the Guardian server using Group Policy.
• Enforce NTLMv2 only where NTLM cannot yet be eliminated.
• Plan for full NTLM removal in alignment with Windows Server 2025 and later guidance.

In a correctly configured gMSA deployment, NTLM authentication should never be required for Cayosoft Guardian operations.

3.2.5 Security Posture Summary

• Kerberos is mandatory for gMSA-based Guardian deployments.
• NTLM is not a supported fallback and indicates misconfiguration.
• Guardian is designed to operate without legacy authentication protocols.
• Eliminating NTLM materially reduces identity attack surface and audit risk.

3.3 TLS Configuration

Cipher suite configuration SHOULD follow Microsoft's recommended cipher suite order for Windows Server. Weak ciphers, specifically RC4, DES, 3DES, and export-grade ciphers, MUST be disabled.

3.4 Network Segmentation

Cayosoft Guardian servers and their supporting SQL instances SHOULD be isolated from the general corporate network using segmentation controls. Recommended topology:

• Place Cayosoft Guardian servers and SQL in a dedicated management VLAN or subnet with restricted inbound access.
• Allow inbound connections to Cayosoft Guardian only from designated administrator workstations (PAWs) and monitoring infrastructure.
• Ensure outbound connectivity is limited to domain controllers, Azure/AWS endpoints used for backup, and Cayosoft update services.
• Do not co-locate Cayosoft Guardian servers with general-purpose application servers or user workstations.

Standby recovery site — virtual network size requirement: When configuring the virtual network for a standby recovery site, the address space MUST be /24 or larger. This ensures sufficient IP addresses for all deployed components during recovery operations. Smaller subnets, for example /27 with 32 addresses, will cause deployment failure.

3.5 LDAP connection security, sealing and LDAPS

Cayosoft Guardian communicates with Active Directory domain controllers by using LDAP and ADSI for change monitoring, event collection, GPO operations, and Forest Recovery. All LDAP traffic generated by Cayosoft Guardian is encrypted on the wire. Cayosoft Guardian provides this protection in one of the following ways, depending on the port in use:

• SASL sealing on port 389 and Global Catalog port 3268 — Connections use Negotiate authentication, Kerberos with NTLM fallback, with LDAP_OPT_ENCRYPT, also known as sealing. Encryption and integrity are provided at the SASL layer.

• TLS on port 636 and Global Catalog over SSL port 3269 — Connections use LDAP over SSL/TLS, also known as LDAPS. Encryption and integrity are provided by the TLS transport.

When TLS is active, SASL sealing and signing are not applied. These mechanisms are mutually exclusive on the System.DirectoryServices.Protocols stack used by Cayosoft Guardian, and the TLS transport already provides equivalent or stronger protection.

3.5.1 Scope of LDAP encryption

LDAP encryption, through sealing or LDAPS, is applied to the following Cayosoft Guardian components and operations:

• Change monitoring jobs — LDAP-based data collection and queries performed as part of change monitoring.

• Forest Recovery Agent — Domain controller inventory and recovery-related metadata collection.

• Threat detection jobs — LDAP queries used to evaluate security exposures and threat conditions.

• AD connector — LDAP and ADSI connection paths used for communication with Active Directory.

3.5.2 LDAPS configuration

Two system-level settings, configured in System Settings > Active Directory, control LDAPS behavior.

The default value of ldapsSkipCertificateValidation = true is provided for compatibility with enterprise environments that commonly use self-signed or internal CA domain controller certificates. For compliance-driven deployments, set this value to false and ensure that the issuing CA chain is installed in the Trusted Root Certification Authorities and Intermediate Certification Authorities stores on every Guardian and Forest Recovery Agent host.

3.5.3 Connection behavior matrix

The same logic applies to Global Catalog connections. By default, Cayosoft Guardian uses port 3268 with automatic fallback to port 3269. When useLdaps = true, Cayosoft Guardian uses port 3269 only.

3.5.4 Channel binding and signing, ADV190023

Cayosoft Guardian is compatible with the Microsoft hardening described in ADV190023. In environments that require LDAP channel binding and signing, or environments where port 389 has been disabled entirely, set useLdaps = true to ensure that every Cayosoft Guardian and Forest Recovery Agent LDAP connection is established over TLS.

3.5.5 Auditing LDAP transport

The following log events can be used to confirm which transport is in use.

Connecting to {host}:{port} using LDAPS

LDAPS connection to {host}:636 established

LDAP connection to {host}:389 failed. Attempting LDAPS fallback on port 636.

LDAPS fallback to {host}:636 succeeded.

LDAPS fallback to {host}:636 also failed.

LDAPS certificate — Subject: {subject}, Issuer: {issuer}, Thumbprint: {thumbprint}

3.5.6 Verifying LDAP signing compliance on port 389

The existing LDAP signing audit procedure, based on Event ID 2889 verification on domain controllers, applies only to connections on port 389. LDAPS connections on port 636 do not generate signing audit events because integrity is enforced at the TLS layer.

After upgrading Cayosoft Guardian, run the LDAP signing audit cycle on any domain controller that still exposes port 389.

3.6 WinRM Connection Security (Encrypted Transport)

Cayosoft Guardian uses Windows Remote Management (WinRM) to execute remote PowerShell sessions on domain controllers and managed hosts. All WinRM sessions initiated by Cayosoft Guardian are encrypted in transit. Cayosoft Guardian does not transmit plaintext PowerShell commands or results over the network on any transport.

Cayosoft Guardian supports both the HTTP, port 5985, and HTTPS, port 5986, WinRM transports. In both cases, the session content is encrypted, as described in Security guide.

3.6.1 Encryption Mechanism

WinRM supports two layers of encryption:

• Message-level encryption — When using HTTP, port 5985, Kerberos or NTLM authentication automatically encrypts the session payload at the message level. Even though the transport protocol is HTTP, the content of each message is encrypted by the authentication provider, and no plaintext is transmitted on the wire. Cayosoft Guardian uses this mechanism by default for WinRM sessions on port 5985.
• Transport-level encryption (HTTPS) — When using HTTPS, port 5986, TLS encrypts the entire transport channel in addition to the authentication provider's message-level encryption. This provides defense in depth and is recommended for environments that require transport-level encryption compliance or for traffic that crosses untrusted network segments.

In both cases, no plaintext PowerShell commands or results are transmitted on the wire. The HTTP, port 5985, transport is therefore an encrypted channel, not an unencrypted one. References to HTTP describe the WinRM transport, not the protection applied to the data.

3.6.2 WinRM Transport Mode Configuration

Cayosoft Guardian allows the WinRM transport used for remote PowerShell sessions to be selected. This setting can be configured globally and, for Forest Recovery, overridden per backup plan and per domain controller.

The available transport modes are:

• HTTP only — Connect using port 5985 only. This is the default and preserves the behavior of earlier releases.
• HTTPS only — Connect using port 5986 only. Use this mode in hardened environments where port 5985 is closed by policy and only WinRM over SSL/HTTPS is permitted.
• Auto (HTTPS preferred) — Attempt HTTPS, port 5986, first on each host. If HTTPS is unavailable, Cayosoft Guardian falls back to HTTP, port 5985, for that specific host. This mode is recommended for mixed environments.
• Auto (HTTP preferred) — Attempt HTTP, port 5985, first on each host. If HTTP is unavailable, Cayosoft Guardian falls back to HTTPS, port 5986, for that specific host.

In both Auto modes, the transport decision is made independently for each host. Because both transports are encrypted, an HTTPS-to-HTTP fallback does not expose plaintext on the wire. It changes only the encryption layer, from transport-level TLS to message-level Kerberos or NTLM encryption. Every fallback event is logged with the host name and the reason.

Organizations with strict transport-level encryption requirements should select HTTPS only so that no fallback to the HTTP transport can occur.

The HTTPS listener port is configurable. The default port is 5986. Administrators can also define a per-domain-controller transport override to assign an explicit transport to individual domain controllers or groups. When configured, the override takes precedence over the global setting.

3.6.3 TLS Certificate Validation for HTTPS Transport

When connecting over HTTPS, port 5986, Cayosoft Guardian validates the TLS certificate presented by each host's WinRM HTTPS listener. By default, certificate validation is enabled and the following checks apply:

• Certificate is present, not expired, and not yet valid — If a check fails, Cayosoft Guardian skips the affected host or, in an Auto mode, falls back to HTTP and logs the event.
• Subject or SAN match and trust chain to a trusted root — A mismatch or untrusted chain is logged as a warning, and the connection continues. The trust-chain check can be configured to be treated as an error.
• Self-signed certificate — The condition is logged as a warning, and the connection continues.

For environments that use self-signed or non-standard certificates, administrators can enable the Skip certificate validation option, which is equivalent to skipping the CN and CA checks. Disabling validation reduces assurance that the remote endpoint is authentic and should be used only when the network path is otherwise trusted.

An optional trusted-thumbprint list can be configured to permit specific certificates without disabling validation entirely.

Cayosoft Guardian uses TLS 1.2 or TLS 1.3 for the HTTPS transport. Cayosoft Guardian does not modify the WinRM configuration of the target host.

3.6.4 Scope of WinRM Usage

Encrypted WinRM sessions are used for Cayosoft Guardian operations that invoke remote PowerShell, including:

• Forest Recovery Agent communication with domain controllers, including AD topology metadata collection across all domain controllers in the forest.
• GPO backup, restore, and reporting operations.
• Remote data collection from managed hosts.
• Domain controller health checks during recovery operations.

3.6.5 Validation

Organizations should validate that Cayosoft Guardian WinRM traffic is encrypted by performing a network capture on port 5985 or 5986 and confirming that no plaintext PowerShell commands or results are visible.

To validate using Wireshark or an equivalent tool, capture traffic on the network interface between the Cayosoft Guardian server, or Forest Recovery Agent, and a target domain controller. Filter for TCP port 5985 or 5986, and inspect the payloads. All content must be encrypted and unreadable.

For environments with strict compliance requirements mandating transport-level encryption, configure WinRM HTTPS listeners, port 5986, on all domain controllers and managed hosts, and set the Cayosoft Guardian WinRM transport mode to HTTPS only.

3.7 SMB Protocol Security (SMBv3 Encryption)

Cayosoft Guardian uses the SMB protocol to access network file shares during backup, restore, and other file-based operations. All SMB connections from Cayosoft Guardian-managed hosts SHOULD use SMBv3 with encryption enabled.

3.7.1 SMBv3 Enforcement

Cayosoft Guardian uses the SMB implementation provided by the underlying Windows operating system. SMB protocol negotiation, dialect selection, signing, and encryption enforcement are controlled by Windows and Group Policy, not by Cayosoft Guardian itself. To protect file transfers used by Cayosoft Guardian workflows, disable SMBv1, require SMB encryption where supported, and, on supported operating systems, restrict negotiated SMB dialects to SMB 3.x.

Required actions

1. Disable SMBv1 on all Cayosoft Guardian servers and on any domain controllers, file servers, or other hosts that participate in Cayosoft Guardian-related SMB file access. SMBv1 is deprecated and should not be used because of known security weaknesses.

   Copy

   Set-SmbServerConfiguration -EnableSMB1Protocol $false
                   Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
   

   NOTE: The Disable-WindowsOptionalFeature command requires a restart.

2. Require SMB encryption on SMB servers that host shares used by Cayosoft Guardian. This enforces encryption for inbound SMB connections to that server.

   Copy

   Set-SmbServerConfiguration -EncryptData $true

3. Require SMB encryption on SMB clients only where supported. Global outbound SMB client encryption mandate is supported beginning with Windows 11 version 24H2 and Windows Server 2025. On earlier operating systems, the -RequireEncryption parameter is not available.

   Copy

   Set-SmbClientConfiguration -RequireEncryption $true
   

   To configure the same setting through Group Policy, use: Computer Configuration > Administrative Templates > Network > Lanman Workstation > Require encryption.

4. If the objective is to enforce SMB 3.x only, configure SMB dialect minimum and maximum values on supported operating systems. Dialect control through PowerShell and Group Policy is supported beginning with Windows 11 version 24H2 and Windows Server 2025. Without dialect control, requiring encryption does not by itself provide an SMBv3-only guarantee across all Windows versions.

   To allow SMB 3.0.0 through SMB 3.1.1 on the SMB server:

   Copy

   Set-SmbServerConfiguration -Smb2DialectMin SMB300 -Smb2DialectMax SMB311

   To require SMB 3.1.1 only on the SMB client:

   Copy

   Set-SmbClientConfiguration -Smb2DialectMin SMB311 -Smb2DialectMax SMB311

   To configure SMB dialects through Group Policy, use these settings:

   • Server:
     Computer Configuration > Administrative Templates > Network > Lanman Server > Mandate the Minimum version of SMB
     

   • Client:
     Computer Configuration > Administrative Templates > Network > Lanman Workstation > Mandate the minimum version of SMB
     

5. Verify the effective configuration after applying changes.

   Copy

   Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EncryptData, Smb2DialectMin, Smb2DialectMax
                   Get-SmbClientConfiguration | Select-Object RequireEncryption, Smb2DialectMin, Smb2DialectMax

NOTE: If you must support older SMB servers that do not support SMB 3.0 or SMB encryption, test carefully before enforcing client-side encryption or restricting dialect negotiation, because those systems may no longer be able to connect.

3.7.2 Validation

After enforcing SMBv3 encryption, customers SHOULD verify that all Cayosoft Guardian operations that use file shares, including backup and restore operations, complete successfully:

1. Enable SMBv3 encryption enforcement on a test domain controller.
2. Disable SMBv1 and SMBv2 on the test domain controller.
3. Run Cayosoft Guardian backup and restore operations.
4. Confirm that all operations complete without errors and that no fallback to unencrypted SMB occurs.

Use the following PowerShell command to verify the current SMB configuration:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol, EncryptData

Apply SMBv3 encryption enforcement across all servers in the Cayosoft Guardian environment as part of the standard OS hardening baseline described in Section 5.1.

4. Data Protection and Encryption

Encryption at rest, in transit, key management, and token security

4.1 Encryption at Rest

Cayosoft Guardian encrypts sensitive data at rest using industry-standard algorithms. The following protections are applied by default or available for configuration:

• Database credentials and passwords — encrypted in the Cayosoft Guardian database using AES-256-CBC. Plaintext passwords are never stored in any Guardian database or log file.
• SQL Server database — all Cayosoft Guardian database content MAY be protected with SQL Server Transparent Data Encryption (TDE), which encrypts data files at the OS level. Cayosoft recommends enabling TDE on all production Cayosoft Guardian databases. Refer to Microsoft documentation: Transparent Data Encryption (TDE) — SQL Server.
• Active Directory backups — encrypted with Windows BitLocker before leaving the domain controller, using one of the following algorithms: AES-CBC 128, AES-CBC 256, XTS-AES 128, or XTS-AES 256. XTS-AES 256 is recommended for new deplCents.
• Entra ID app registration credentials — stored as certificate credentials, not client secrets. No plaintext secrets are stored. See Section 2.6.

4.2 Encryption in Transit

All data in transit between Cayosoft Guardian components, clients, and managed infrastructure is protected using encryption. The following table summarizes the encryption applied to each communication channel:

Passwords submitted to Cayosoft Guardian from client browsers are protected by HTTPS/TLS and never transmitted in plaintext.

Every network channel used by Cayosoft Guardian, including LDAP to domain controllers, WinRM for remote management, SMB for file share access, HTTPS for web portal and cloud connectivity, and TDS for database communication, is encrypted in transit. No unencrypted protocol variants are used in production Guardian deployments.

4.3 Encryption Key Management

Cayosoft Guardian uses AES-256-CBC to encrypt sensitive data in its database. The encryption keys are managed by the Cayosoft Guardian Service on the host server. The following requirements apply:

• The Cayosoft Guardian server host MUST be protected with full-disk encryption. BitLocker is required so that encryption keys cannot be extracted from an offline disk.
• For SQL Server deployments using Transparent Data Encryption (TDE), the TDE certificate MUST be backed up and stored separately from the SQL data files. Loss of the TDE certificate means the database cannot be recovered.
• BitLocker recovery keys for Cayosoft Guardian server disks MUST be stored in a secure, offline location, such as a hardware security module (HSM), Azure Key Vault, or a physically secured offline store, and NOT on the Cayosoft Guardian server itself.
• Key material MUST be rotated when a Cayosoft Guardian administrator with access to the server leaves the organization.

4.4 Data Collection Scope and Minimization

Cayosoft Guardian collects only the data required for its stated functions: change monitoring, threat detection, and forest recovery. The following table documents what is collected from each connected environment.

Change records are stored in structured JSON format including object name, object class, object path, initiator identity, initiator SID, timestamp, correlation ID, operation type, and modified properties with previous and new values. No email content, Teams chat, or other collaboration content is collected or stored by Cayosoft Guardian.

Attribute-level control: Customers can configure which AD attributes and Entra ID properties are collected or excluded through Cayosoft Guardian's change monitoring configuration. This supports data minimization requirements under GDPR and similar frameworks.

Retention and purging: Cayosoft Guardian provides configurable retention rules to automatically purge collected data after a defined period. Retention policies can be set by time, by count, or by object attributes. Separate retention rules can be applied to change history, change alerts, threat alerts, and archive databases. See Section 9 for recommended retention settings aligned with compliance frameworks.

5. Infrastructure Hardening

OS, SQL Server, web portal, endpoint protection, and remote access controls

5.1 Operating System Hardening

Servers hosting Cayosoft Guardian and its SQL database MUST be hardened prior to deployment. Guardian supports the following server operating systems:

• Windows Server 2016, 2019, 2022, and 2025
• Windows 10 Pro for management workstation deployments

Co-installation not supported: Installing the Cayosoft Administrator Service and Cayosoft Guardian on the same server is not supported. They MUST be installed on separate servers to ensure optimal performance and maintain a clean security boundary.

.NET Framework minimum requirement: Cayosoft Guardian running on Windows Server 2016 requires .NET Framework 4.7.2 or later as the minimum supported runtime version. Earlier .NET Framework versions, including .NET 4.5.1 and .NET 4.6.x, do not fully support LDAP sealing and modern encryption options required by Guardian. The legacy Audit Collector service, which previously targeted .NET 4.5.1, has been updated to require .NET Framework 4.7.2 or later.

Organizations running Cayosoft Guardian on Windows Server 2016 MUST verify that .NET Framework 4.7.2 or later is installed before upgrading. Use the following registry check to confirm:

(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release -ge 461808

A return value of True confirms .NET Framework 4.7.2 or later is installed. If the value is False, install the required .NET Framework version from Microsoft before proceeding with the Cayosoft Guardian upgrade.

Minimum hardware for Cayosoft Guardian servers:

Active Directory functional level requirements: Cayosoft Guardian supports AD Forest and Domain Functional Levels of 2012 R2, 2016, and 2025.

Supported web browsers for the Cayosoft Guardian portal:

• Google Chrome — versions released within the past 12 months
• Apple Safari — versions released within the past 12 months; version 14.x or higher only
• Microsoft Edge based on Chromium

Microsoft Internet Explorer is not supported by the Cayosoft Guardian web portal and MUST NOT be used for administrative access.

Cayosoft recommends applying configurations from the following established hardening benchmarks:

• DISA STIG for Windows Server — apply all Category I (high) findings as a minimum; address Category II (medium) findings based on risk assessment.
• CIS Benchmark for Windows Server — Level 1 profile as a minimum baseline; Level 2 for high-security environments.

Specific OS hardening actions SHOULD include:

• Disable all unnecessary Windows roles and features, such as IIS, print spooler, and SNMP if not in use.
• Remove unnecessary local user accounts; rename the local Administrator account.
• Enable Windows Defender Firewall and configure rules per Section 3.2.
• Configure Windows Event Log sizes and retention appropriate for SIEM forwarding.
• Enable and configure Windows Defender Credential Guard on supported hardware.

Azure recovery-site deployments — use Desktop Experience: For Azure-based recovery site deployments, use Windows Server with Desktop Experience. Server Core is not supported in this topology even if the source environment uses Server Core.

AWS deployments with Windows Server 2025 — UEFI instance type required: When deploying domain controllers with Windows Server 2025 in AWS-based Forest Recovery scenarios, the EC2 instance type MUST support UEFI boot mode. Older instance types such as t2.medium are not compatible and will cause provisioning failures. Cayosoft Guardian defaults to t3 instances, which are supported. Customers using legacy recovery plans MUST manually update the instance type.

5.2 SQL Server Hardening

The SQL Server instance hosting the Cayosoft Guardian database is a high-value target. The correct database configuration must be selected for the deployment scale before hardening is applied.

Supported database options:

Important: The built-in SQL Server Express LocalDB option, with a 50 GB maximum, is intended for evaluation and small local deployments only. SQL Server 2017 or later, Azure SQL, or SQL Server on AWS is strongly recommended for all production workloads.

Hardening requirements — apply in addition to the OS hardening in Section 5.1:

• Apply the CIS Benchmark for Microsoft SQL Server, Level 1 profile at minimum.
• Disable the sa account and any other default SQL Server accounts not required for operation.
• Use Windows Authentication for SQL Server connections wherever possible; avoid SQL Server Authentication.
• Restrict SQL Server network access to Guardian service accounts and authorized DBAs only.
• Disable unnecessary SQL Server features using the SQL Server Surface Area Configuration tool, such as xp_cmdshell and OLE Automation Procedures.
• Enable SQL Server Audit to log login attempts, configuration changes, and privileged operations.
• Enable TDE as described in Section 4.1.

5.3 Web Portal Hardening

The Cayosoft Guardian web portal MUST be configured with standard HTTP security headers to protect against common web application attacks. The following headers MUST be present in all responses from the Guardian portal:

Verify header presence using the Security Headers scanner or equivalent tooling after deployment.

5.4 Endpoint Protection

Cayosoft Guardian servers MUST run a supported antivirus (AV) or Endpoint Detection and Response (EDR) solution. The EDR solution provides real-time threat detection and response capability for the Guardian host and its SQL database server.

Required exclusions: To avoid performance issues or interference with Guardian's AD monitoring operations, configure the following exclusions in your AV/EDR solution. Exclusions reduce the protection scope, so apply only what is documented and needed.

• Exclude the Cayosoft Guardian service process from real-time scanning.
• Exclude the Cayosoft Guardian database files from continuous file scanning; TDE provides encryption-at-rest protection.

Organizations SHOULD implement application control using Windows Defender Application Control (WDAC) on Cayosoft Guardian servers. WDAC prevents unauthorized executables from running on the server, significantly reducing the impact of a supply chain or malware attack.

5.5 Remote Access Restrictions

Remote Desktop Protocol (RDP) is the most commonly exploited remote access vector in ransomware and lateral movement attacks. Cayosoft Guardian servers MUST have RDP and other remote management protocols restricted:

• RDP MUST NOT be exposed to general corporate networks or the internet. Access MUST be restricted to the management VLAN or PAW subnet via Windows Firewall rules.
• WinRM (Windows Remote Management) MUST be restricted to authorized management systems only.
• All RDP and WinRM sessions MUST be logged, using Event IDs 4624, 4625, and 4634.
• Organizations SHOULD use a PAM solution, such as Microsoft Entra PIM or CyberArk, to broker and record all privileged remote sessions to Guardian servers.

If a PAM solution with session recording is in place, it provides a comprehensive audit trail of all privileged activity on Guardian servers, which may satisfy external log collection requirements described in Section 7.2.

6. Patch and Vulnerability Management

OS patching, Cayosoft Guardian updates, vulnerability scanning, and advisory process

6.1 OS and Firmware Patching

All operating systems and firmware on servers hosting Cayosoft Guardian components MUST be kept current with security patches. Cayosoft recommends the following patching cadence for Cayosoft Guardian hosts:

• Apply Microsoft Patch Tuesday updates within 30 days of release.
• Apply out-of-band emergency patches for actively exploited vulnerabilities in the CISA KEV catalog within 72 hours of release.
• Apply firmware and driver updates on a quarterly basis or within 30 days if a critical vulnerability is published.
• Use a patch management solution, such as WSUS, MECM, or Intune, to track and enforce patch compliance across all Guardian servers and SQL hosts.

Cayosoft Guardian servers MUST be patched in a maintenance window with a tested rollback procedure. Because Cayosoft Guardian is a critical monitoring service, unplanned downtime during patching must be minimized. Schedule patches during low-activity periods and verify Cayosoft Guardian service health immediately after each update cycle.

7. Logging, Monitoring, and Alerting

Cayosoft Guardian audit logging, log integrity and tamper protection, retention, and health monitoring

7.1 Cayosoft Guardian Audit Logging

Cayosoft Guardian maintains two distinct audit log streams that together provide a complete record of all security-relevant activity within the product and the environments it monitors.

Internal audit log — Cayosoft Guardian management plane: Every administrative action performed within the Cayosoft Guardian interface is captured in the Internal Audit log. Events are stored in the Cayosoft Guardian database and visible via Change History; filter by System type = Guardian. Each event records the actor identity, timestamp, target object, action type, and before/after values. Internal audit is enabled by default. To verify, go to Settings > Service Settings > Internal Audit Settings > Disabled and ensure it is unchecked.

The internal audit log captures the following events:

• All Cayosoft Guardian portal sign-in and sign-out events for every user
• Job execution, including running or scheduling jobs
• Creating, modifying, or deleting rules, connections, domains, tenants, and other entities
• Role delegation changes, including when a role is assigned directly, inherited indirectly through a group, or when multiple roles are assigned to a single user
• Recovery plan configuration changes

Change Audit log — monitored environments: Cayosoft Guardian captures a full record of all changes made to connected AD domains, Entra ID tenants, Exchange Online, and Teams. Each change record includes the initiator identity, timestamp, object affected, operation type, and every modified property with previous and new values.

Initiator (Who) attribution for AD changes requires Windows Security Event Log audit policies to be correctly enabled on domain controllers. Without them, the Who field may show as unknown or time out. For required policy settings, see Events Collected by Cayosoft Guardian from the Windows Event Log Related to the Active Directory Operations.

Background system jobs: Some internal events triggered by Cayosoft Guardian background jobs may show Who = Unknown. This is expected behavior and should not be treated as unidentified access.

Cayosoft Guardian does not collect or log email message bodies, Teams chat content, or other collaboration content. See Section 4.4 for the full data collection scope.

Read-only deployment: Cayosoft Guardian can operate in a read-only monitoring capacity, collecting changes and detecting threats without making any modifications to AD, Entra ID, Exchange, or Teams. To achieve this, assign read-only connection account permissions, specifically Directory Readers for Entra ID and Replicating Directory Changes for AD, and do not configure rollback or recovery operations.

7.2 Log Integrity and Tamper Protection

Audit logs stored only in the Cayosoft Guardian database or on the Cayosoft Guardian server are vulnerable to modification if an attacker gains administrator-level access. The following controls MUST be applied:

• Cayosoft Guardian application logs and Windows Security Event Logs MUST be forwarded to an out-of-band log management system, such as a SIEM platform, Azure Monitor, or equivalent, that is inaccessible from the Cayosoft Guardian server.
• The forwarding destination SHOULD use write-once or append-only storage. Logs must not be modifiable by any party, including security team members.
• The log forwarding pipeline MUST be monitored for interruption. A gap in log ingestion is itself a security signal and MUST trigger an alert.
• Log forwarding configuration MUST be change-controlled and protected from unauthorized modification.
• Rollback of internal audit events is not supported. The audit record of any Cayosoft Guardian administrative action cannot be undone.

7.2.1 External Log Forwarding

Cayosoft Guardian supports forwarding both Threat Alert events and Change Audit events to Windows Event Log for collection by any SIEM agent or Windows Event Forwarding (WEF) subscription. Both channels are disabled by default and must be enabled under Settings > Service Settings > Windows Event Log Settings. See How to Enable Integration with SIEM Solutions via Windows Event Log Events.

Both Azure Monitor Logs and AWS CloudWatch support immutable log archiving. If Cayosoft Guardian uses Azure-hosted backup storage, centralizing Cayosoft Guardian logs in the same Azure Log Analytics workspace provides unified visibility, retention management, and write-once protection.

7.3 Log Retention

Log retention MUST meet the following minimum requirements, aligned with SOC 2 and NIST SP 800-92:

Organizations subject to specific regulatory requirements, such as HIPAA, PCI DSS, or FedRAMP, MUST comply with whichever retention period is longer. Cayosoft Guardian's internal retention rules for change history and threat alert data are configurable under Configuration > Retention Rules.

7.4 Health Monitoring

Guardian includes a built-in Health Check that automatically validates its own critical components: system and archive databases, managed AD domains, Entra ID tenants, domain controllers, and connection account credentials. It can be run manually or on a schedule under Settings > Service Settings > Health Check Settings, and sends alert emails with attached health reports when issues are detected.

The health check provides early warning for credential expiry, database connectivity failures, and domain controller accessibility issues, all of which can silently degrade Cayosoft Guardian's ability to collect changes and detect threats if left unmonitored.

7.5 Cayosoft Guardian's Detection Capabilities

Change Monitoring: Cayosoft Guardian detects AD and cloud identity changes using the DirSync control for on-premises AD and API-based monitoring, including Entra ID, Exchange Online, and Teams. It surfaces changes that bypass native AD security logs, including changes made directly at the database level or via tools that circumvent standard auditing. Cayosoft Guardian ships with built-in alerting rules covering high-risk events such as AdminSDHolder ACL modifications, privileged group membership changes, Global Administrator role changes, Exchange mailbox delegation (such as full access, SendAs, and forwarding rules), and Teams guest access policy changes.

Threat Detection: Cayosoft Guardian's Threat Detection engine applies a continuously updated library of threat definitions across four severity levels: Critical, High, Medium, and Low. Definitions are updated over-the-air automatically. Some detection rules that monitor high-volume events, specifically those monitoring failed authentication patterns, are disabled by default due to the load they can generate in large environments. See Threats Disabled by Default in Cayosoft Guardian.

Kerberoasting honeypot detection: Cayosoft Guardian can detect Kerberoasting attacks with near-zero false positives using a decoy service account with a fake SPN, a 32-character random password, all logon types denied, and delegation disabled. Any authentication request against it is definitively malicious. Cayosoft Guardian monitors Event ID 4768 (Kerberos TGT / AS-REQ) and Event ID 4771 (Kerberos pre-authentication failure) for this purpose. Cayosoft Guardian raises a Critical alert, Cayosoft Guardian alert CTD000183, including the attacker's username, client IP, and domain controller.

8. Backup and Recovery Security

Backup strategy, encryption, access control, credentials, and RTO/RPO

8.1 Backup Protection Strategy

Cayosoft Guardian implements a comprehensive backup strategy for Active Directory. Customers SHOULD align their Cayosoft Guardian backup configuration with the 3-2-1-1-0 rule:

• 3 — maintain at least three copies of backup data
• 2 — store backups on at least two different media types, such as local disk and cloud object storage
• 1 — keep at least one copy offsite, such as Azure Blob Storage or AWS S3
• 1 — keep at least one copy offline or air-gapped, inaccessible to ransomware
• 0 — verify zero errors through regular restore testing

Cayosoft Guardian supports the following backup storage tiers:

Permanent backup locations are defined in the backup plan and do not change. Encrypted backup files are stored here. A copy is also maintained on the domain controllers configured in the plan. Additionally, a copy used to create the standby forest is stored in the customer's Azure subscription, within a resource group created by Cayosoft Guardian. Retention policy and behavior are configurable in the Cayosoft Guardian backup plan.

Temporary backup locations are generated during standby forest creation. These locations must be publicly accessible during the standby forest creation process; however, access is tightly controlled using SAS tokens and the same encryption protections as permanent locations. Temporary locations are used to sync backups and retrieve logs from the recovery site, which are critical for building a healthy standby forest. Cayosoft Guardian automatically deletes these locations based on the Standby Forest Recovery Plan retention settings.

Default retention and storage sizing: Cayosoft Guardian ships with two default retention rules, configurable under Configuration > Retention Rules. Local DC backup storage retains the two most recent copies per domain controller. Network backup storage applies a 30-day time-based window with no object count limit. To estimate required storage for the network rule:

Storage required = Average backup size × Number of DCs in backup plan(s) × Number of backups to retain per DC

8.2 Backup Encryption

Active Directory backups created by Guardian are encrypted with Windows BitLocker before leaving the domain controller. This ensures that storage administrators in Azure, AWS, or on-premises cannot access raw backup files.

Supported BitLocker algorithms (XTS-AES 256 is recommended for new deployments):

• AES-CBC 128
• AES-CBC 256
• XTS-AES 128
• XTS-AES 256 — recommended

Data transferred to Azure Blob Storage or AWS S3 is additionally protected by HTTPS with TLS encryption in transit.

8.3 Backup Access Control

Azure Blob Storage — SAS tokens: During backup or recovery operations, Cayosoft Guardian issues SAS tokens with a 24-hour expiration window, scoped to a single container. Only Directory Recovery agents located on the domain controllers defined in the Backup Plan use these tokens to access backup storage. Permanent access keys are never used. Azure Blob Storage containers created by Cayosoft Guardian do not have permanent access configured. Access is exclusively granted to Cayosoft Guardian Directory Recovery agents, even when public network access is enabled. Once a token expires, no credentials remain that could be used to access the location.

By default, Cayosoft Guardian creates Azure Blob Storage containers accessible from public networks. This may expose containers to unauthorized access if not properly secured. Customers MUST restrict access by navigating to Azure Portal > Storage accounts > [Your Storage Account] > Networking > Firewalls and virtual networks and allowing only:

• The Cayosoft Guardian host when backups are written via a network share topology
• Domain controllers with Cayosoft Guardian agents installed when domain controllers write directly to blob storage

Azure — secure copy for recovery (AzCopy): If the recovery agent cannot access the backup blob container securely, Cayosoft Guardian performs the following steps:

1. Before starting recovery, Cayosoft Guardian evaluates whether the recovery agent can access the backup blob container securely.
2. If secure access is not available, Cayosoft Guardian uses AzCopy to transfer the required backup files into a temporary blob container located within the recovery site subscription.
3. The temporary container is private by default and accessible only by the Cayosoft Guardian service or the recovery agent identity.
4. After recovery completes, the temporary blob container is automatically deleted to clean up any residual data.

Important: AWS does not provide equivalent network-level restrictions for S3 buckets. Network-level access restriction for AWS backup storage is not yet supported in Cayosoft Guardian.

AWS S3: Cayosoft Guardian uses AWS Security Token Service (STS) to obtain temporary session credentials with least-privilege access to S3 buckets. Permanent IAM keys are never stored or used. The following AWS permissions are required for Forest Recovery operations:

• AmazonS3FullAccess — store recovery site backups, logs, and configurations; retrieve backup data from S3 when initiating recovery
• AmazonSSMFullAccess — automate recovery processes via AWS Systems Manager, including instance management and configuration
• AmazonEC2FullAccess or equivalent — provision EC2 instances for recovery workloads

AWS account isolation: Cayosoft recommends creating a separate AWS organization and dedicated accounts for Forest Recovery. This ensures Cayosoft Guardian service accounts can only access resources required for recovery and have no access to production workloads. The potential impact of a compromised recovery account is then contained entirely within the recovery environment.

8.4 Privileged Credential Handling in Forest Recovery

Cayosoft Guardian Forest Recovery is designed to minimize the use and exposure of privileged credentials wherever possible. Forest Recovery performs backup operations without privileged accounts; no high-level credentials are required or stored for standard backup activities. During recovery operations that require domain controller promotion and specific AD recovery actions, Microsoft-mandated operations that cannot be completed without elevated privileges, Guardian uses the following controls:

• Customers are not required to store privileged credentials in the product.
• A separate break-glass account is created automatically in each domain; each has a different UPN but all share the same password.
• A secure password is automatically generated and displayed only once, at plan creation time.
• Accounts are usable only within the isolated recovery environment by authorized Cayosoft Guardian administrators.
• Accounts MUST be removed immediately after initial recovery access is completed.

Note: The break-glass account password is shown only once when the recovery plan is first created or when break-glass accounts are reconfigured. It is not stored in Guardian and cannot be retrieved after the plan is saved. Administrators MUST copy and securely store it immediately, such as in an offline password manager or physical safe, before saving.

This approach ensures no standing privileged credentials exist within Guardian Forest Recovery, and privileged access is limited to recovery scenarios only.

8.5 Recovery Time and Recovery Point Objectives

Organizations MUST define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for Active Directory recovery scenarios and validate that Guardian backup configurations support those targets.

Cayosoft recommends documenting RTO and RPO targets in the organization's Business Continuity Plan and referencing them in the Cayosoft Guardian backup plan configuration.

8.6 Recovery Testing

Organizations MUST test Active Directory recovery using Cayosoft Guardian on a regular cadence:

• Perform a full Forest Recovery test in an isolated environment at least annually.
• Validate that restored AD data is complete and consistent.
• Document recovery time achieved and compare against the RTO target.
• Update the recovery plan if personnel, infrastructure, or procedures have changed since the last test.

8.6.1 Standby Forest Health Validation Procedure

After bringing a standby (recovery) forest online, whether for a test or a real failover, perform the following verification steps to confirm the environment is functioning correctly before relying on it:

1. Power on the recovery site infrastructure hosting the recovered domain controllers.
2. Deploy a new test virtual machine and join it to one of the recovered domains. Use Azure Bastion or Azure VPN Gateway to access cloud VMs from on-premises.
3. Verify the directory structure is intact: check that organizational units, users, and computers are present as expected.
4. Create a test user or group to confirm write operations are working in the recovered domain.
5. Attempt to sign in as the new test user to validate authentication end-to-end.
6. Run dcdiag on the recovered domain controllers to check DC health and identify any replication or service issues.
7. Confirm DNS resolution and replication are functioning correctly before reconnecting to production networks.

Cayosoft Guardian integrates security-focused tests into its SDLC to detect regressions in recovery functionality. Security-specific regression tests are maintained to ensure vulnerabilities do not reemerge in subsequent releases.

8.7 Recovery Authorization and Privilege Escalation Controls

Recovery operation authorization: Forest Recovery is a high-impact operation restricted to the Global Administrator role only. No other Cayosoft Guardian role can initiate or modify recovery plans. Organizations SHOULD implement an additional out-of-band approval step for recovery plan execution using their change management or PAM solution before the Cayosoft Guardian Global Administrator initiates recovery. This compensating control reduces the risk of an unauthorized or erroneous recovery.

Backup integrity verification: Cayosoft Guardian performs a health check on backup data before and during recovery operations. The Standby Forest Recovery health check feature provides continuous validation that backup data is accessible, consistent, and current. For manual recovery scenarios, administrators SHOULD verify BitLocker encryption status and backup timestamps before initiating recovery to confirm the backup predates the incident.

Protection against privilege escalation via Cayosoft Guardian: Cayosoft Guardian's architecture reduces the risk of a compromised administrator using the tool to escalate privileges or persist access:

• No standing privileged credentials are stored in Cayosoft Guardian. Break glass accounts are generated at recovery time and scoped to the isolated recovery environment only.
• The gMSA accounts used for AD data collection are read-only and cannot be used to write changes to AD.
• Recovery operations executed via Cayosoft Guardian are fully logged with initiator identity. See Section 7.1.
• All cloud resources provisioned during recovery are created in the customer's own subscription and tagged by Cayosoft Guardian for visibility and cleanup.
• Temporary recovery containers for Azure Blob Storage are automatically deleted after recovery completes, leaving no persistent cloud credentials.

DSRM logon behavior: Cayosoft Guardian Forest Recovery Settings include a DSRM administrator logon behavior option that controls when a Directory Services Restore Mode account can be used to log into a recovered domain controller. The setting has three values:

• DSRM logon in DSRM only — the default and most restrictive value; a domain controller can only be accessed via DSRM when it is running in DSRM mode. This is the correct security posture and MUST be maintained for normal operations.
• DSRM logon when NTDS service is stopped — allows DSRM login when NTDS is stopped or when the domain controller is in DSRM mode; increases attack surface.
• DSRM logon at any time — labeled “unsecure” in the product; allows DSRM login regardless of DC state. Organizations MUST NOT use this setting in production and MUST NOT leave it enabled after recovery operations complete.

FR agent certificate validation: The Validate Guardian service certificate on the agent side setting, found under Forest Recovery Settings, enforces TLS certificate validation between the Cayosoft Guardian Service and its Forest Recovery agents. This prevents tampering and man-in-the-middle attacks during recovery. This setting MUST remain enabled at all times.

9. Compliance and Data Governance

Framework mapping, deployment checklist, responsibilities, and data governance

9.1 Supported Compliance Frameworks

The following table maps compliance frameworks to the primary Cayosoft Guardian controls that support them.

9.2 Deployment Security Checklist

Use this checklist as a deployment gate before promoting a Cayosoft Guardian installation to production. All Required items MUST be completed. Recommended items SHOULD be completed unless a documented exception exists.

9.3 Responsibility Matrix

The following RACI matrix clarifies security control ownership across Cayosoft and customer teams.

R = Responsible (does the work) · A = Accountable (owns the outcome) · C = Consulted (provides input) · I = Informed (notified of outcome)

9.4 Data Governance and Regulatory Compliance

This section addresses common regulatory and data governance questions raised during security evaluations of identity management tools.

Data retention and automatic purging: Cayosoft Guardian provides fully configurable retention rules that automatically purge collected data after a defined period. Retention policies can be configured per data type, specifically change history, change alerts, and threat alerts, and per storage location, covering the active database and archive database. Three policy types are supported:

• Retention by time — retain records for a specified number of days, then automatically delete.
• Retention by count — keep the most recent N records and delete older ones.
• Retention by object attribute — delete based on specific object properties or values.

To configure retention rules, navigate to Configuration > Retention Rules in the Cayosoft Guardian web portal. Separate rules can be created for the active database and each archive database. Retention jobs can be run immediately or on a schedule.

Retention rules for archive databases must be explicitly enabled. They do not apply automatically. Ensure your archive backup strategy is aligned before enabling deletion from archive. See Managing Retention Rules in Cayosoft Guardian.

GDPR, HIPAA, and data protection regulations: Cayosoft Guardian's data collection is limited to identity and directory object metadata. It does not collect email message bodies, Teams chat content, or other high-sensitivity personal communication data. See Section 4.4. The structured change records it retains, including user object attributes, group memberships, and policy assignments, may constitute personal data under GDPR where they relate to identifiable individuals. Organizations SHOULD:

• Define retention periods for change history and threat alert data aligned with their GDPR records management obligations.
• Configure Guardian retention rules to enforce automatic purging at the defined retention limit.
• Use attribute-level collection controls to exclude sensitive personal attributes not required for their operational use case.
• Contact Cayosoft for Data Processing Agreement (DPA) documentation where required under GDPR Article 28.

Data residency: All Cayosoft Guardian data, including the configuration database, change history database, archive database, and AD backup files, resides entirely within infrastructure controlled by the customer. No data is processed or stored in Cayosoft-owned cloud infrastructure. For cloud-connected deployments:

• Azure Blob Storage and AWS S3 backup containers are provisioned in the customer's own Azure subscription or AWS account, in the region the customer selects.
• Recovery VMs, VNets, and storage accounts are provisioned in the customer's subscription in the target Azure region or AWS region.
• Customers can restrict data to specific geographic regions by selecting their Azure or AWS region during backup and recovery plan configuration.

Vendor data access commitment: Cayosoft does not access, process, or use customer data for any purpose beyond support and service delivery. All cloud resources provisioned by Cayosoft Guardian are created in the customer's own subscription and are fully visible and controllable by the customer. Cayosoft Guardian does not transmit identity data, AD content, or backup data to Cayosoft systems. Customers requiring contractual commitments on data use, including Data Processing Agreements or data handling addenda, should contact Cayosoft through their account team.