ASD ISM 1327 Access controls, encryption and user authentication for X.509 certificates
What it says
X.509 certificates are protected by logical and physical access controls and encryption, with those issued to human users requiring authentication before use.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep X.509 certificates and their private keys locked down logically, physically and cryptographically, and make people prove who they are before their personal certificates can be used.
An X.509 certificate binds an identity (a person, a server, a device or a service) to a cryptographic key. Anything that holds a valid certificate and its private key is, for practical purposes, that identity: it can sign, decrypt and authenticate as the named party. That makes certificate stores and the key material behind them high-value targets. This control asks for four things. First, logical access controls, so that only authorised accounts and processes can read or use certificate stores and private keys. Second, physical access controls, so that the hardware the certificates live on (servers, hardware security modules, smart cards, tokens, backup media) cannot simply be picked up or plugged into. Third, encryption, so that a certificate and private key copied out of a store, a backup or a transit path is still unusable without the protecting secret. Fourth, for certificates issued to human users specifically, the person must authenticate (for example with a PIN, passphrase or other credential) before the certificate can be used, so possession of the card, token or file alone is not enough. The real-world risk is impersonation. A stolen server certificate lets an attacker stand up a convincing fake service or intercept traffic; a stolen user certificate lets them sign documents, decrypt email or log in as that person; a compromised issuing certificate undermines trust in every certificate beneath it. Because certificates are trusted automatically by the systems that rely on them, misuse is quiet and hard to spot after the fact, which is why the control focuses on stopping unauthorised access up front.
Free. Save your status, tasks and notes.
Why it matters
If X.509 certificates are not protected, anyone who gains access to the certificate store, the private key file, the token or the backup can act as the identity the certificate represents. Attackers can impersonate servers to intercept or spoof communications, impersonate staff to sign, decrypt or authenticate on their behalf, and, if an issuing certificate is exposed, mint further trusted certificates. Because the relying systems trust the certificate rather than the person holding it, the misuse is often invisible until damage is done, and recovery means revoking and reissuing certificates across every dependent system, with the outages and cost that brings.
How to implement
The PKI or platform owner inventories where X.509 certificates and their private keys are held (certificate authorities, servers, appliances, hardware security modules, smart cards and tokens, software key stores, backups) so that every location can be brought under the same protections.
System administrators apply logical access controls to each certificate store, restricting read and use of private keys to the specific service account or role that needs them, removing general administrator or group access, and enabling logging of access to the store.
The security or facilities team places certificate authority hardware, hardware security modules and any offline key media in access-controlled rooms, cabinets or safes, and records who is permitted to enter or retrieve them and when items are issued and returned.
Engineers protect certificates and private keys with encryption at rest and in transit, generating keys inside a hardware security module or encrypted key store where possible, and using passphrase-protected containers and encrypted channels whenever a certificate has to be exported, moved or backed up.
The identity team issues certificates to human users only onto smart cards, tokens or protected software stores that require a PIN, passphrase or equivalent authentication before the certificate can be used, and configures those stores so the authentication prompt cannot be switched off by the user.
Keep it running
Day to day this control lives with whoever runs the public key infrastructure and the platform teams that consume certificates. Certificate stores on servers and appliances should be readable only by the service account that needs them, with administrator access limited and logged. Private keys should be generated and held in encrypted form (a hardware security module, a smart card or token, an operating system key store or a passphrase-protected container) rather than as plain files sitting alongside the certificate.
Physical protection is mostly inherited: certificate authority servers and hardware security modules sit in access-controlled rooms or cabinets, and smart cards, tokens and any offline root media are kept in secured storage with an issue and return record. User certificates are normally provisioned onto a card, token or protected software store that prompts for a PIN or passphrase at use, and that prompt must not be disabled for convenience.
Expect ongoing housekeeping: reviewing who can access certificate stores when staff change roles, checking that new deployments follow the same key-protection pattern, keeping the encryption on stores and backups in place when systems are migrated, and making sure certificates exported for reuse (for example to load balancers or cloud services) are encrypted in transit and at rest and are not left in shared drives, tickets or chat.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the inventory or register of where X.509 certificates and private keys are stored across the environment.
Look at
Check that it covers certificate authorities, servers and appliances, hardware security modules, user cards and tokens, and backup or export locations, and that each entry names the protections applied.
Good evidence
A current list with no obvious gaps, where every location shows logical access restrictions, physical protection and encryption rather than a few well-protected stores and many unknown ones.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the access control configuration and access logs for a sample of certificate stores and private key locations.
Look at
Look at which accounts and groups can read or use the private keys, and whether access events are recorded.
Good evidence
Only the service account or a small named role can access each key, broad administrator or everyone groups are absent, and the logs show access being recorded and periodically reviewed.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see how certificate authority hardware, hardware security modules, tokens and offline key media are physically secured.
Look at
Check the room, cabinet or safe controls, the list of people with physical access, and the issue and return records for cards, tokens and media.
Good evidence
Physical access is limited to a small set of named people, entries and retrievals are logged, and no certificate hardware or media is found in unsecured areas.
- Check 4 of 5What an auditor asks for
Ask for
Ask how private keys are encrypted when stored, backed up and moved between systems.
Look at
Look at the key store or hardware security module configuration, backup encryption settings and the procedure used when certificates are exported or transferred.
Good evidence
Private keys are generated and kept in encrypted or hardware-backed stores, exports are passphrase protected and sent over encrypted channels, and no plain-text keys appear in file shares, tickets or repositories.
- Check 5 of 5What an auditor asks for
Ask for
Ask for a demonstration of a human user using their issued certificate, for example to log in, sign or decrypt.
Look at
Watch whether the user is prompted for a PIN, passphrase or other credential before the certificate can be used, and check the provisioning standard that sets this behaviour.
Good evidence
Every use of a user certificate requires the person to authenticate first, the setting is enforced centrally rather than left to the user, and the same applies to certificates held in software stores as well as on cards or tokens.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 8 mappings
This control partially meets A.5.15.
ISM-1327 requires concrete protections for X.509 certificates and private keys (logical and physical access controls plus encryption) and authentication before personal certificate use. Annex A 5.15 requires establishing and implementing rules to control physical and logical access to information assets, which provides the policy/procedural basis to control access to certificate stores and key custody arrangements. ISM-1327 is narrower because it applies those access control rules to a specific asset class (X.509 certificates and keys) and adds an explicit authentication-before-use requirement.
This control partially meets A.5.17.
ISM-1327 requires authentication before human-user X.509 certificates can be used and requires protections for the certificate/private key material. Annex A 5.17 governs allocation and management of authentication information, including how credentials (e.g., PINs, passphrases, key unlock secrets) are handled and communicated to personnel. ISM-1327 is narrower because it targets certificate use and safeguarding of certificate/key assets, while Annex A 5.17 covers authentication information management across all authentication methods and systems.
This control partially meets A.5.18.
ISM-1327 requires X.509 certificates and their private keys to be protected with logical and physical access controls and encryption and requires authentication before human-user certificates can be used. Annex A 5.18 covers provisioning, review, modification and removal of access rights to information assets, which would include controlling access to certificate stores, HSMs and key material used with certificates. ISM-1327 is a technology-specific application of access-rights management focused on certificates and key protection, while Annex A 5.18 applies broadly across all information assets and the access-rights lifecycle.
This control partially meets A.8.3.
ISM-1327 focuses on restricting access to X.509 certificates and private keys using logical/physical controls and encryption, plus requiring authentication for human-user certificate use. Annex A 8.3 requires restricting access to information and associated assets in line with access control policy, which would include certificate repositories, private key files and HSM key slots. ISM-1327 is a specific instance of Annex A 8.3 with added certificate-specific expectations (encryption of certificate material and authentication gating of user certificate use).
This control partially meets A.8.5.
ISM-1327 mandates that human-user X.509 certificates require authentication prior to use and that certificates/private keys are protected via access controls and encryption. Annex A 8.5 requires secure authentication technologies and procedures based on access restrictions, which encompasses certificate-based authentication and controls like PIN/biometric-protected private key use. ISM-1327 is narrower because it applies the authentication requirement specifically to the use of user-issued X.509 certificates, whereas Annex A 8.5 addresses authentication mechanisms across the organisation more generally.
This control partially meets A.8.24.
ISM-1327 requires encryption protections for X.509 certificates and private keys and controls over their use, particularly for human users. Annex A 8.24 requires defining and implementing rules for effective cryptography use and cryptographic key management, which includes how private keys are generated, stored (e.g., HSM/TPM), backed up, rotated and revoked. ISM-1327 is narrower as it applies cryptography and key-protection expectations specifically to X.509 certificate material rather than all cryptographic keying material.
This control partially overlaps A.7.2.
ISM-1327 requires certificates used for network authentication to be protected using logical and physical access controls, encryption, and user authentication. ISO/IEC 27001:2022 Annex A 7.2 focuses on entry controls for secure areas, which helps protect physical locations where certificate authorities, HSMs, or servers holding certificate private keys are hosted. ISM-1327 also requires logical controls, encryption, and authentication that Annex A 7.2 does not address, so the overlap is limited to physical protection of environments holding certificate material.
This control partially overlaps A.7.3.
ISM-1327 requires certificates used for network authentication to be protected using logical and physical access controls, encryption, and user authentication. ISO/IEC 27001:2022 Annex A 7.3 requires physical security for offices, rooms and facilities, which can reduce the risk of theft or tampering of systems that store certificate private keys. ISM-1327 extends beyond facility security by requiring logical access controls and cryptographic protections directly applied to certificate storage and use.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.