ASD ISM 1928 Encrypt and restrict access to Microsoft AD and Entra Connect server backups
What it says
Backups of Microsoft AD DS domain controllers, Microsoft AD CS servers, Microsoft AD FS servers and Microsoft Entra Connect servers are encrypted using ASD-approved cryptography, stored securely and only accessible to backup administrator accounts.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBackups of domain controllers, AD CS, AD FS and Entra Connect servers must be encrypted with ASD-approved cryptography, kept in secure storage, and readable only by backup administrator accounts.
A backup of a domain controller, an Active Directory Certificate Services (AD CS) server, an Active Directory Federation Services (AD FS) server or a Microsoft Entra Connect server is not just a copy of a machine. It contains the most sensitive secrets in the organisation: the password hashes for every account in the domain (including the KRBTGT account used to mint Kerberos tickets), the private keys of the internal certificate authority, the token-signing keys that federated cloud services trust, and the credentials Entra Connect uses to synchronise identities to the cloud. Whoever holds an unencrypted copy of one of these backups can extract those secrets offline, at leisure, without ever touching the live server. That is enough to forge Kerberos tickets, issue trusted certificates, sign fraudulent federation tokens or pivot into Microsoft 365. Backups are often the weakest link because they sit on file shares, tape, or cloud storage that many people can reach, long after the live server has been locked down. This control closes that gap in three ways. The backup data must be encrypted using cryptography approved by the Australian Signals Directorate (ASD), so a stolen or misplaced backup is useless without the key. The backups must be stored securely, so the encrypted files cannot be casually copied, altered or deleted. And only backup administrator accounts may access them, so the number of identities that could ever read or restore these backups is small, known and separate from everyday accounts.
Free. Save your status, tasks and notes.
Why it matters
If these backups are unencrypted, stored loosely, or readable by general accounts, an attacker (or a curious insider) who obtains a single backup file can extract every domain password hash, the enterprise CA private key, the AD FS token-signing key and the Entra Connect sync credentials. That enables golden ticket forgery, fraudulent certificate issuance, forged cloud sign-in tokens and silent persistence that survives password resets. The compromise is effectively a full identity-plane breach, typically requiring a domain-wide credential reset, CA and federation key rollover and prolonged incident response, all without any alert from the live systems.
How to implement
The backup platform owner enables backup encryption using an ASD-approved algorithm (for example AES-256 as listed in the ISM cryptographic guidelines) as a mandatory, non-overridable setting on every backup job that targets domain controllers, AD CS servers, AD FS servers and Entra Connect servers.
The identity or Tier 0 administrator creates a dedicated backup administrator group and accounts (separate from domain admin and everyday admin accounts), then grants that group, and only that group, read, write and restore permissions on the backup jobs and the repository holding these server backups.
The infrastructure or storage team places these backups in a hardened repository (an isolated backup server, immutable or write-once storage, or an encrypted vault) with network access limited to the backup servers, and removes any general file-share or open bucket access to the location.
The security team or key custodian stores the backup encryption keys or passphrases in an approved key management system or password vault under a separate access list, so that the keys are never kept alongside the backup files or in the backup job configuration in clear text.
The backup platform owner enables audit logging on the backup software and repository, and reviews the logs of backup access and restore operations for these servers on a set schedule to confirm that only backup administrator accounts are touching them.
Keep it running
Day to day, this control lives in the backup platform and the identity of the accounts that run it. Backup jobs for domain controllers, AD CS, AD FS and Entra Connect servers should run with ASD-approved encryption switched on by default, so no operator has to remember to enable it per job. Encryption keys or passphrases for those backups need their own custodianship, separate from the backups themselves, so that a compromise of the storage does not also hand over the key.
The backup repository (disk, tape, object storage or immutable vault) should be treated as a Tier 0 asset with the same care as the servers it protects. Access is limited to dedicated backup administrator accounts; day-to-day administrator, help desk and service accounts should have no read, write or restore rights to these backup sets. When staff join or leave the backup team, the membership of the backup administrator group should be updated promptly.
Restores of these servers should be performed only by backup administrator accounts and recorded, because every restore is also a decryption event. Periodic checks that the encryption is actually applied (not just configured), that the storage location remains locked down, and that the access list has not drifted keep the control effective between audits.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the backup job configuration for the domain controllers, AD CS, AD FS and Entra Connect servers, including the encryption settings.
Look at
Confirm that every one of those server types is actually covered by a job and that encryption is enabled with an algorithm and key length that the ISM lists as ASD-approved.
Good evidence
All four server types are in scope, encryption is on for each job as an enforced setting, and the algorithm named matches ASD-approved cryptography rather than a vendor default or legacy cipher.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the list of accounts and groups that have permissions on the backup repository and on the backup jobs for these servers.
Look at
Check whether the permitted identities are dedicated backup administrator accounts, and whether domain admins, help desk staff, service accounts or broad groups such as Everyone or Authenticated Users also have access.
Good evidence
Only a small, named set of backup administrator accounts holds read, write and restore rights, and there is a clear separation from everyday and privileged administrator accounts.
- Check 3 of 5What an auditor asks for
Ask for
Ask where the encrypted backups are physically or logically stored and what protects that location.
Look at
Review the storage configuration (share permissions, bucket policies, immutability or write-once settings, network restrictions, physical controls for tape or removable media).
Good evidence
The repository is isolated from general user access, protected against modification or deletion, and reachable only from backup infrastructure and by backup administrator accounts.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the backup encryption keys or passphrases are generated, stored and who can retrieve them.
Look at
Check that the key is held in a key management system or vault with its own access list, not stored in clear text in the backup job or beside the backup files.
Good evidence
Keys are kept separately from the backups under restricted custodianship, and the people who can obtain the key are documented and limited.
- Check 5 of 5What an auditor asks for
Ask for
Ask for backup and restore audit logs for these servers covering a recent period.
Look at
Compare the accounts that performed backup, read and restore actions against the approved backup administrator list, and look for any access by other accounts.
Good evidence
Every recorded access and restore is attributable to an approved backup administrator account, and the organisation can show it reviews these logs periodically.
Mappings
Closest match in ASD Essential Eight: E8-RB-ML3.2, Privileged user accounts cannot access their own backups, which this control covers in full and more.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1928 requires strict logical access control for AD/Entra Connect server backups, limiting access to backup administrator accounts and applying ASD-approved encryption to protect confidentiality. ISO/IEC 27001:2022 Annex A 5.15 requires establishing and implementing access control policies and procedures for information and associated assets, which would include defining who can access backups and under what conditions. ISM-1928 is a specific access-control application to a particular asset class (identity-server backups) and adds an explicit cryptography requirement beyond generic access policy expectations.
This control partially meets A.8.13.
ISM-1928 requires a specific set of backup protection measures for Microsoft identity infrastructure servers, including ASD-approved encryption, secure storage, and limiting access to backup administrator accounts. ISO/IEC 27001:2022 Annex A 8.13 requires maintaining and regularly testing backups in line with a policy, which encompasses defining protections such as encryption and access controls for backups. ISM-1928 is a prescriptive, high-risk-system-specific instantiation of the broader backup-and-recovery procedural requirements in Annex A 8.13.
This control depends on A.8.24.
ISM-1928 requires backups of AD DS/AD CS/AD FS/Entra Connect servers to be encrypted using ASD-approved cryptography and stored securely with tightly restricted access. ISO/IEC 27001:2022 Annex A 8.24 establishes the organisational rules for effective cryptography and cryptographic key management that are needed to implement ISM-1928's encryption requirement correctly. ISM-1928 is a specific application for particular backup types and access conditions, while Annex A 8.24 is a broader governance control for cryptography across the organisation.
ASD Essential Eight: 7 mappings
This control is broader than E8-RB-ML3.2.
E8-RB-ML3.2 requires privileged accounts (excluding backup administrator accounts) cannot access their own backups to reduce the risk of misuse and unauthorised disclosure. ISM-1928 restricts access to specific high-value backups so they are solely accessible to backup administrator accounts, inherently preventing most privileged accounts from accessing those backups. ISM-1928 is broader in technical safeguards but narrower in system scope, while E8-RB-ML3.2 generally applies across privileged users and their own backups.
This control partially overlaps E8-RB-ML1.3.
ISM-1928 requires backups of AD DS/AD CS/AD FS/Entra Connect servers to be encrypted using ASD-approved cryptography, stored securely, and accessible only to backup administrator accounts. E8-RB-ML1.3 similarly requires backups to be retained securely and in a resilient manner, which aligns with the secure storage and protection intent in ISM-1928. However, ISM-1928 is more specific on encryption standards (ASD-approved) and strict access limitation to backup administrator accounts, while E8-RB-ML1.3 is broader and less prescriptive about cryptography and access roles.
This control partially overlaps E8-RB-ML1.6.
ISM-1928 requires encryption and strict access restrictions for sensitive identity infrastructure backups (domain controllers, AD CS/FS and Entra Connect), limiting access to backup administrator accounts. E8-RB-ML1.6 requires preventing unprivileged accounts from modifying and deleting backups, which complements ISM-1928's intent to protect backup integrity through restricted access. ISM-1928 focuses on confidentiality and controlled readability of specific backups, whereas E8-RB-ML1.6 focuses on integrity protection against unprivileged users and does not mandate encryption or specify identity-system backups.
This control partially overlaps E8-RB-ML2.1.
ISM-1928 mandates that backups of AD DS/AD CS/AD FS/Entra Connect servers are only accessible by backup administrator accounts and are encrypted using ASD-approved cryptography. E8-RB-ML2.1 requires privileged accounts (excluding backup administrator accounts) cannot access backups belonging to other accounts, reinforcing the privileged-access boundary that ISM-1928 relies on to keep sensitive backups confidential. ISM-1928 is narrower and system-specific (identity infrastructure backups) and includes encryption and secure storage requirements, while E8-RB-ML2.1 is a broader backup access-control rule not tied to cryptographic controls.
This control partially overlaps E8-RB-ML2.2.
ISM-1928 requires backups of AD DS/CS/FS and Entra Connect servers to be encrypted, stored securely, and accessible only to backup administrator accounts. E8-RB-ML2.2 requires privileged accounts (excluding backup administrator accounts) be prevented from modifying or deleting backups, which supports the separation of duties implied by ISM-1928's restriction to backup administrators. ISM-1928 is primarily about confidentiality (encryption and limiting access) for specific high-value systems, while E8-RB-ML2.2 is primarily about integrity (preventing modification/deletion) across backups more generally.
This control partially overlaps E8-RB-ML3.1.
ISM-1928 requires AD-related server backups to be securely stored and only accessible (readable) by backup administrator accounts, with ASD-approved encryption. E8-RB-ML3.1 requires that unprivileged accounts cannot access their own backups, aligning with the access restriction principle in ISM-1928. ISM-1928 is more targeted (specific Microsoft identity servers) and adds explicit cryptographic requirements, while E8-RB-ML3.1 is a general access-control requirement for backups regardless of system type.
This control partially overlaps E8-RB-ML3.3.
ISM-1928 requires backups of specific identity services (AD DS, AD CS, AD FS and Entra Connect) to be encrypted, stored securely, and only accessible to backup administrator accounts. E8-RB-ML3.3 complements this by adding an immutability requirement that prevents even backup admin accounts from modifying or deleting backups, enhancing protection against tampering. ISM-1928 focuses on confidentiality and restricted access, while E8-RB-ML3.3 emphasizes integrity/availability of backups.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.