ASD ISM 2109 Pre-boot authentication for encrypted system volume media
What it says
Pre-boot authentication using passwords, or managed network-based key release, is implemented for media containing encrypted system volumes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDevices with encrypted system volumes must require a password at start-up, or release the unlock key through a managed network, before the device boots.
A "system volume" is the part of a computer's storage that holds the operating system and start-up files, and encryption scrambles that storage so it cannot be read without the right key. This control means that before such a device will start up, it must either prompt the user for a password, or automatically receive its unlock key from a trusted system on your network. This matters because if a laptop or device is lost or stolen, this start-up barrier stops a thief from simply turning it on and reading everything inside.
Free. Save your status, tasks and notes.
Why it matters
A lost or stolen device with no pre-boot authentication can be switched on and its encrypted system volume read in full, exposing all data and credentials it holds.
How to implement
IT administrators should turn on full disk encryption with pre-boot authentication on every device that holds a system volume, for example by enabling BitLocker with a start-up PIN or password on Windows, or FileVault on Apple computers, so the device asks for a password before it will boot.
IT administrators should choose between the two approved methods for each device type: a pre-boot password that the user types in at start-up, or a managed network-based key release where a trusted server on your network hands the device its unlock key automatically when it is connected.
Where network-based key release is used, IT teams should configure the key server so it only releases unlock keys to recognised devices on the corporate network, meaning a stolen device taken off-site cannot obtain its key and will not boot.
The person managing devices should set and document a strong pre-boot password or PIN policy (for example a minimum length and no reuse of common passwords) and record recovery keys securely in a separate, access-controlled location.
Whoever issues new laptops and portable devices should add 'encrypted system volume with pre-boot authentication enabled' to the standard build checklist, so no device is handed to a staff member until this protection is switched on and tested.
Keep it running
Re-check pre-boot authentication whenever devices are re-imaged, reissued, or after operating system upgrades, since major updates can reset encryption settings.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the IT administrator for the list of devices with encrypted system volumes and the authentication method used for each.
Look at
whether every applicable device is covered.
Good evidence
is a complete inventory showing each device has either pre-boot password or managed network key release enabled.
- Check 2 of 5What an auditor asks for
Ask for
to watch a device being started up.
Look at
whether it demands a password before the operating system loads, or whether it pauses to receive a key from the network server.
Good evidence
is the device clearly refusing to boot until authentication succeeds.
- Check 3 of 5What an auditor asks for
Ask for
the configuration or policy settings that enforce pre-boot authentication (for example BitLocker or FileVault settings, or the key server configuration).
Look at
whether the settings are applied centrally and cannot be turned off by the user.
Good evidence
is a documented, enforced policy rather than per-device manual setup.
- Check 4 of 5What an auditor asks for
Ask for
how the managed network-based key release server decides which devices get a key.
Look at
whether it only releases keys to known devices on the corporate network.
Good evidence
explains that a device removed from the network or unknown to the server will not be unlocked.
- Check 5 of 5What an auditor asks for
Ask for
where pre-boot passwords and recovery keys are stored and who can access them.
Look at
whether recovery keys are kept separately from the devices and access is restricted.
Good evidence
shows recovery keys held in a controlled vault with limited, logged access.
Mappings
Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.5.
ISM-2109 mandates pre-boot authentication (password or managed network key release) for devices with encrypted system volumes before the operating system boots. ISO/IEC 27001:2022 Annex A 8.5 requires implementation of secure authentication technologies and procedures, which can encapsulate boot-time authentication for encrypted endpoints. Annex A 8.5 is broader since it concerns authentication across systems and access scenarios, unlike ISM-2109, which specifies a technical requirement tied to pre-boot disk encryption.
This control partially overlaps A.5.17.
ISM-2109 mandates implementing pre-boot authentication using passwords or managed network-based key release for encrypted system volumes. Annex A 5.17 covers the management and governance of authentication information, such as boot passwords and recovery secrets, for use in pre-boot authentication. This overlaps in the context of handling authentication information, though ISM-2109 specifically focuses on the enforcement at boot time.
This control partially overlaps A.8.24.
ISM-2109 requires pre-boot authentication or managed network-based key release as part of unlocking encrypted system volumes. Annex A 8.24 involves rules for cryptographic key management, crucial for managing full-disk encryption keys and protectors. The mapping is justified as ISM-2109 is a specific implementation aspect of the broader cryptography management covered by Annex A 8.24.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.