ASD ISM 1324 Generating X.509 certificates with evaluated CA or HSM
What it says
X.509 certificates are generated using an evaluated certificate authority or hardware security module.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery X.509 certificate an organisation issues must come from a certificate authority product or hardware security module that has passed formal security evaluation.
X.509 certificates are the digital identity cards behind TLS, VPNs, code signing, smart cards and device authentication. A certificate is only as trustworthy as the system that generated it and the private key that signed it. This control requires that certificates are generated using either an evaluated certificate authority (CA) product or an evaluated hardware security module (HSM), meaning a product that has passed a recognised security evaluation rather than a home-grown script, an unevaluated software tool or a general-purpose server holding keys on disk. Why it matters: if the CA signing key or the key generation process is weak or exposed, an attacker can mint certificates that your systems will trust without question. That enables impersonation of internal services, interception of encrypted traffic, forged code signatures and fraudulent user or device identities. Because certificates chain to a root of trust, a single compromised or poorly generated signing key can undermine every certificate beneath it. Using an evaluated CA or HSM gives assurance that key generation, storage and signing operations are performed with sound randomness and tamper-resistant protection.
Free. Save your status, tasks and notes.
Why it matters
Certificates generated by an unevaluated CA or software-only key store may rely on weak randomness or keys that can be copied from disk. Compromise of the signing key lets an attacker issue trusted certificates at will, enabling service impersonation, interception of encrypted sessions, forged software signatures and bypass of certificate-based authentication. Recovery typically means revoking and reissuing every certificate in the affected chain, with widespread outages and loss of trust in the organisation's PKI.
How to implement
The PKI or security architecture lead inventories every point where X.509 certificates are currently generated (root CA, issuing CAs, automated enrolment services, DevOps pipelines, appliances that self-sign) and records which product and key store is used for each.
The procurement and security teams select a certificate authority product or hardware security module that holds a recognised security evaluation, confirming the evaluated version and configuration match what will be deployed.
The PKI team migrates root and issuing CA signing keys into the evaluated HSM, or onto the evaluated CA platform, through a documented key generation ceremony with named participants and signed records.
The platform and DevOps teams reconfigure automated enrolment tools, pipelines and appliances so that certificate signing requests are sent to the evaluated CA rather than generating certificates locally, and disable local self-signing where it is no longer needed.
The PKI team adds a check to the change and upgrade process so that any new version or replacement of the CA product or HSM is confirmed as still evaluated before it is used to generate certificates.
Keep it running
In practice this control shapes how the PKI team runs certificate issuance every day. Root and issuing CA signing keys live inside an evaluated HSM, or the CA software itself is an evaluated product, and all certificate generation (including for internal-only services and test environments) goes through that platform rather than ad hoc tools such as OpenSSL on an administrator's workstation.
Day-to-day this means:
- Certificate requests are submitted to the evaluated CA or HSM-backed issuance service, not fulfilled locally.
- The evaluation status of the CA product or HSM is recorded and re-checked when products are upgraded or replaced, since a new version may not carry the same evaluation.
- Ceremonies for creating or renewing CA keys are performed on the HSM with witnesses and records.
- Any newly discovered self-signed or locally generated certificates on the network are treated as exceptions to be replaced.
- Procurement and change processes check evaluation status before a new CA or HSM is introduced.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the PKI design document or architecture diagram showing how X.509 certificates are generated.
Look at
Look at which product performs certificate generation and where the CA signing keys are stored.
Good evidence
Every certificate generation path terminates in a named certificate authority product or hardware security module, with no locally generated or self-signed alternatives shown.
- Check 2 of 5What an auditor asks for
Ask for
Ask for evidence of the security evaluation of the CA product or HSM in use.
Look at
Look at the evaluation certificate or listing, including the evaluated version and configuration, and compare it to what is actually deployed.
Good evidence
The deployed product, version and configuration match the evaluated one, and the evaluation is current rather than lapsed or superseded.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the key generation ceremony records for root and issuing CA keys.
Look at
Look at where the keys were generated, who attended, and whether the keys were created inside the HSM or evaluated CA rather than imported from software.
Good evidence
Records show keys were generated within the evaluated CA or HSM, with witnesses, dates and signatures.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a recent scan or inventory of certificates in use across servers, appliances and applications.
Look at
Look at the issuer field of each certificate to identify any not issued by the evaluated CA.
Good evidence
All certificates chain to the evaluated CA, and any exceptions have a documented plan for replacement.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the change or upgrade records for the CA platform or HSM over the last review period.
Look at
Look for a step confirming the evaluation status of the new version before it went live.
Good evidence
Each upgrade or replacement includes a recorded check that the new version remains evaluated.
Mappings
Closest match in ISO/IEC 27001: A.8.24, Effective use of cryptography and key management, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.24.
ISM-1324 requires that X.509 certificates are generated using an evaluated certificate authority (CA) product or a hardware security module (HSM). Annex A 8.24 requires the organisation to define and implement rules for effective cryptography use and cryptographic key management, which includes how keys and certificate issuance should be managed and protected. ISM-1324 is a specific, higher-assurance implementation constraint within the broader cryptography/key-management governance expected by Annex A 8.24.
This control supports A.5.17.
ISM-1324 requires certificates to be generated using an evaluated certificate authority or hardware security module to ensure authentication credentials are trustworthy and protected. This supports Annex A 5.17 by strengthening the secure allocation and management of authentication information when that information includes certificates and associated keys. Annex A 5.17 is broader and process-oriented (covering management and handling of authentication information generally), while ISM-1324 is a technical control focused on certificate issuance tooling and assurance.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.