For most IT and software vendors, ISO 27001 certification has quietly stopped being a nice-to-have. It has become a condition of doing business. Customer security questionnaires, RFPs, and supplier risk assessments increasingly ask for current certification before a deal can move forward, which means a lapsed certificate is no longer just a compliance problem. It is a revenue risk.
Cryptography sits right at the center of that shift. The 2022 revision of the standard pulled cryptography and key management into a single, sharply defined control: Annex A 8.24, Use of Cryptography. This guide breaks down what changed in the 2022 revision, what control 8.24 actually requires, and how to prove it to an auditor before your next surveillance visit.
What changed in ISO/IEC 27001:2022
The 2022 revision restructured Annex A into 93 controls organized across four themes. For cryptography, the most important change is consolidation: the 2013 edition’s two separate controls (A.10.1.1, Policy on the use of cryptographic controls, and A.10.1.2, Key management) were merged into a single control: 8.24, Use of Cryptography.
That consolidation matters for how teams document and evidence their cryptographic program. Instead of treating policy and key management as two loosely connected requirements, 8.24 expects one coherent story: a defined approach to cryptography and a managed lifecycle for the keys behind it, tied together and backed by evidence.
What control 8.24 actually requires
Control 8.24 rests on two pillars.
The first is a documented, risk-based cryptography policy that defines approved algorithms and minimum key strengths. The second is a managed key lifecycle that covers the full life of a key: generation, distribution, revocation, handling of compromised keys, recovery of lost keys, storage, rotation, backup, and destruction.
The critical point for IT and software companies is how auditors test this. They verify 8.24 through operational evidence, not policy statements alone. In practice that means the certificate and key inventory, rotation records showing the policy’s stated interval was actually met, TLS and cipher configuration output, HSM or KMS access logs, and destruction records with sign-off. A well-written policy that no one can prove is being followed will not satisfy an assessor. And because 8.24 follows the product, its scope routinely includes cryptography embedded in the product itself, not only the internal IT environment.
Why ISO 27001 cryptography compliance matters for IT vendors
ISO 27001 certification is technically voluntary. In practice, for IT and software vendors, it has become a de facto commercial prerequisite. Security questionnaires, RFPs, and supplier risk assessments increasingly require current certification as a condition of doing business, so a gap in your cryptographic controls can stall procurement and cost deals; it reaches procurement by one of two routes: it surfaces directly in a security questionnaire answer you cannot support, or it becomes a nonconformity that puts the certificate itself at risk..
There is also a timing dimension. Because ISO 27001 is a management system standard, 8.24 is not tested once and forgotten. Surveillance audits sample the ISMS rather than test every control, so 8.24 may or may not come up in a given year. Recertification is different: it confirms the system meets every requirement of the standard, not only the areas sampled during surveillance. In practice you cannot predict which year cryptography gets examined. That cadence rewards organizations that maintain continuous, evidence-ready control over cryptography rather than scrambling to reconstruct it before each audit.
Worth knowing how a certificate is actually lost: a major nonconformity does not void it on the spot. Certification bodies set a defined window to close the finding, and suspension or withdrawal follows only if it is not closed. The commercial risk is less “we failed an audit” than “we spent a quarter with an open major nonconformity we had to disclose.”
How 8.24 maps to real cryptographic controls
Control 8.24 does not exist in isolation. It connects to a set of practical control areas that assessors expect to see working together across the certified scope.
A documented cryptography and key management policy (Annex A 8.24)
At its core, 8.24 calls for a topic-specific policy that defines approved algorithms, minimum key lengths, and lifecycle rules. That policy should be tied directly to the ISMS risk assessment, so every cryptographic decision traces back to a documented risk rather than a preference.
The cryptographic key lifecycle (Annex A 8.24)
The lifecycle is where strong cryptography most often breaks down. Auditors expect centralized generation, distribution, rotation, and destruction of keys and certificates, including those embedded in shipped software, all backed by a full audit trail. Revocation, handling of compromised keys, recovery of lost keys, secure storage, and backup round out the picture.
Data confidentiality and integrity (Annex A 5.14, 8.20, 8.21; PII under 5.34)
Cryptography exists to protect data. Under 8.24, cryptography is the mechanism; the controls that create the obligation sit elsewhere. Annex A 5.34 (information transfer) and 8.20–8.21 (networks security and security of network services) drive encryption in transit. PKI-issued certificates secure customer data at rest and in transit across the certified scope. For software vendors, that scope commonly extends into multi-tenant SaaS environments where many customers share the same infrastructure.
Product cryptography (Annex A 8.25, 8.26, 8.28)
If crypto is embedded in what you sell, the secure development lifecycle (8.25), application security requirements (8.26), and secure coding (8.28) are where auditors test whether algorithm and key-length decisions from your 8.24 policy actually reach the codebase. Supplier controls cover inherited libraries; these cover your own code.
Secure authentication (Annex A 8.5)
Annex A 8.5 brings authentication into the cryptographic conversation. Certificate-based authentication reduces reliance on shared secrets and static passwords across both customer-facing and administrative access, replacing credentials that are easy to leak with identities that are far harder to abuse.
Supplier and inherited cryptography (Annex A 5.21, 8.8)
Modern software inherits cryptography from libraries and third parties. Annex A 8.24 requires a key management system to handle key revocation, compromised keys. Every one of those duties is owed per key, and a per-key duty presupposes knowing which keys exist. For Annex A 8.8, an accurate asset inventory is a prerequisite for effective vulnerability management. Annex A 5.21 extends the question into the ICT supply chain, where the components are someone else’s code. Read together, the inventory is not a stated requirement; it is the only practical way to evidence four that are.
Statement of Applicability traceability (Clause 6.1.3)
Finally, Clause 6.1.3 ties it all back to governance. Centralized reporting that maps cryptographic controls to documented risk treatment decisions gives auditors a clear, traceable line from a control to the risk it addresses.
Getting audit ready: what assessors probe
When an assessor reaches 8.24, they are looking for evidence, not intentions. The following areas are what they consistently probe:
- A documented cryptography policy that covers both internal systems and shipped products, defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory.
- Key lifecycle evidence: records, not procedures: rotation logs showing the policy’s stated interval was met, destruction records with sign-off, per-key activity logs, and activation and deactivation dates.
- Statement of Applicability traceability that justifies including 8.24 and links it to the underlying risk assessment.
- Legal and jurisdictional compliance, including export controls and data residency considerations.
- A current certificate and key inventory with named owners and expiry dates, including keys embedded in software releases.
- Internal audit testing of the 8.24 controls, with findings reviewed by management within the ISMS cycle.
- Configuration matching policy. Assessors compare the algorithms and key lengths your policy approves against what is actually deployed. Policy-to-reality drift is a nonconformity even when both the policy and the configuration are individually defensible.
The common thread is ownership and traceability. Every claim you make about cryptography should be backed by an artifact an auditor can inspect.
How Keyfactor can help
Meeting 8.24 comes down to visibility, governed rules, and disciplined key management at scale. Keyfactor’s platform maps directly to the control areas above.
- AgileSec builds the cryptographic component inventory that supports supplier assurance and produces Statement of Applicability evidence for embedded or third-party components.
- EJBCA provides the PKI behind certificate-backed data confidentiality and integrity, along with centralized key lifecycle management, including keys embedded in shipped software.
- Keyfactor Command enforces policy, delivers key lifecycle visibility, maintains a certificate and key inventory, and produces Statement of Applicability traceability reporting.
Brought together, these capabilities create a single system of record for cryptography, one that produces the exact evidence an ISO 27001 auditor asks for instead of forcing teams to assemble it by hand.
Conclusion and next steps
The message running through 8.24 is consistent: the control rewards ownership, traceability, and evidence over policy statements. Certification depends less on having the right words in a document and more on being able to show, on demand, how your cryptography is governed and how your keys are managed.
The practical next step is straightforward. Assess your current cryptography policy and key inventory against 8.24 before your next audit, and centralize the evidence rather than tracking it across scattered spreadsheets.
Ready to see how automated cryptography and key lifecycle management maps to Annex A 8.24? Request a Demo.
Got ISO 27001 cryptography questions? We’ve got answers.
What is ISO/IEC 27001 Annex A 8.24?
Annex A 8.24, Use of Cryptography, is the ISO 27001:2022 control governing how an organization uses cryptography. It requires a documented, risk-based cryptography policy and a managed key lifecycle, verified through operational evidence rather than policy statements alone. Annex A itself states the control in a single sentence; the detailed expectations sit in ISO/IEC 27002:2022, which auditors use as the yardstick.
What changed for cryptography in the 2022 revision?
The 2022 revision restructured Annex A into 93 controls across four themes. It consolidated the 2013 edition’s separate cryptography and key management controls into a single control, 8.24.
Does 8.24 cover cryptography inside the products we ship?
Yes. For software and IT service companies, the scope of 8.24 routinely includes cryptography embedded in the product itself, not only the internal IT environment.
What does a compliant cryptography policy need to include?
It should be a topic-specific policy defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory. It must be tied to the ISMS risk assessment and cover both internal systems and shipped products.
What key lifecycle evidence do auditors expect?
Auditors expect demonstrated procedures for key generation, secure storage, rotation, and destruction, not just a written policy. A current certificate and key inventory with named owners and expiry dates supports this.
How often is 8.24 tested?
Because ISO 27001 is a management-system standard, 8.24 is tested at annual surveillance audits and in full at the three-year recertification.
Why does ISO 27001 certification matter commercially?
Certification has become a de facto commercial prerequisite for IT and software vendors. Security questionnaires, RFPs, and supplier risk assessments increasingly require current certification, so a lapsed certificate can directly threaten revenue.
How does 8.24 relate to the Statement of Applicability?
The Statement of Applicability must justify including 8.24 and link it to the underlying risk assessment. Centralized reporting that maps cryptographic controls to documented risk treatment decisions supports auditor review under Clause 6.1.3.
