A.8.24 Technological
Use of cryptography
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (18)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- SC-12fullcovers — A.8.24's mandate to ensure proper and effective use of cryptography according to all relevant requirements directly accounts for the entirety of SC-12's requirement to establish and manage keys when cryptography is used.
- SC-13fullcovers — SC-13's entire requirement (selecting and implementing the exact cryptography required per use case) is completely accounted for inside the broader mandate of A.8.24 to ensure proper and effective use of cryptography per business, security, legal and regulatory needs.
- SC-12mostlyaligns with — Both controls establish requirements for the full lifecycle management of cryptographic keys, including generation, distribution, storage, rotation, revocation, recovery, and destruction.
- SC-13mostlyaligns with — Both controls require organizations to select and apply approved cryptographic algorithms and mechanisms that match the sensitivity of the information being protected.
- SC-28mostlycovers — A.8.24's mandate to select and apply cryptography for confidentiality/integrity directly accounts for the bulk of SC-28's protection-at-rest requirement when cryptography is the chosen mechanism, but leaves a residual where non-cryptographic protections (e.g., OS-level access controls or physical media controls) could satisfy SC-28 without invoking cryptography.
- SC-8mostlycovers — A.8.24's mandate to select and apply cryptography per requirements (including confidentiality/integrity) accounts for the bulk of SC-8's protection objective, but leaves a residual on the specific transmission-focused mechanisms, parameters, and boundary enforcement that SC-8 requires beyond general crypto policy.
- CM-6partialaligns with — Both controls require the organization to define and enforce approved cryptographic standards, algorithms, and configuration settings.
- SC-28partialaligns with — Both controls require cryptographic protection for information at rest on endpoint devices and storage media.
- SC-8partialaligns with — Both controls address the use of cryptography to protect the confidentiality and integrity of information transmitted over networks.
Aligned NIST CSF 2.0 outcomes (18)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- PR.DS-01mostlyaligns with — The control establishes cryptographic mechanisms and key-management processes that directly protect the confidentiality and integrity of data at rest on endpoints and storage media.
- PR.DS-02mostlyaligns with — The control mandates the use of approved cryptographic algorithms and key handling to protect data transmitted over networks to mobile devices and storage media.
- GV.PO-01partialaligns with — The control explicitly calls for a topic-specific policy on cryptography that is derived from organizational context and risk priorities.
- GV.SC-05partialaligns with — The control requires that contracts and SLAs with external cryptographic-service providers address liability, reliability, and response times, thereby embedding cryptographic requirements into supplier agreements.
- ID.RA-09partialaligns with — The control’s emphasis on selecting approved cryptographic solutions and assessing their strength supports the authenticity and integrity evaluation of software and hardware prior to acquisition.
- PR.PS-01partialaligns with — The control requires an organization-wide policy and approved standards for cryptographic algorithms and usage, which are foundational elements of configuration management.
- GV.PO-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- ID.RA-09implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
- PR.DS-01implements — A.8.24 operationalizes data-at-rest protection (via mandated cryptography) within PR.DS-01's domain, but the outcome does not name cryptography specifically — access control and physical protection also serve it
- PR.DS-02implements — A.8.24 operationalizes protection of data-in-transit confidentiality and integrity (core parts of the PR.DS-02 outcome) via its mandated cryptographic controls, which sit inside that protection domain even though the CSF outcome does not name cryptography explicitly
- PR.PS-01implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
Related OWASP ASVS 5.0 requirements (12)
Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- V11.1.1mostlycovers — The ISO control's requirement for a documented cryptographic policy and lifecycle directly implements the ASVS mandate for a documented key-management policy and lifecycle.
- V11.1.2mostlycovers — Mandating an inventory of algorithms, keys and certificates satisfies the ASVS requirement to maintain and regularly update a cryptographic inventory.
- V11.2.1partialaligns with — Specifying approved algorithms, cipher strength and usage practices aligns with the ASVS requirement to use industry-validated cryptographic implementations.
- V11.2.2partialaligns with — The ISO control's emphasis on standards, approved algorithms and key-management procedures supports the ASVS goal of designing for crypto-agility.
- V13.3.1partialaligns with — Requiring secure generation, storage, distribution and destruction of keys aligns with the ASVS requirement to use a secrets-management solution for cryptographic material.
- V13.3.4partialaligns with — Defining key rotation, revocation and archival processes aligns with the ASVS requirement that secrets be configured to expire and be rotated according to documented policy.
Related weaknesses / CWE (267)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
CWE-1204←P →MCWE-1230←PCWE-1240←M →MCWE-1241←PCWE-1255←PCWE-1258←PCWE-1270←PCWE-1279←PCWE-1291←PCWE-1323←P →PCWE-1394←PCWE-202←PCWE-256←P →MCWE-257←PCWE-261→MCWE-290←PCWE-294←P →MCWE-295→PCWE-296←PCWE-297←PCWE-298←PCWE-299←PCWE-300←P →MCWE-303←PCWE-311→FCWE-312→FCWE-313←P →FCWE-314←P →FCWE-315←P →FCWE-316←P →PCWE-317←PCWE-318←P →MCWE-321→PCWE-322←P →MCWE-323←P →MCWE-324←P →MCWE-325←PCWE-326→PCWE-327→MCWE-328←P →MCWE-329←P →FCWE-330←P →MCWE-331←P →MCWE-332←P →PCWE-333←PCWE-334←P →MCWE-335←PCWE-336←PCWE-337←PCWE-338←P →MCWE-339←P →PCWE-340←P →MCWE-341←P →MCWE-342←P →PCWE-343←P →PCWE-345←P →PCWE-353←P →MCWE-354←P →MCWE-358←P →PCWE-360←P →PCWE-370←PCWE-419→PCWE-5←P →MCWE-515←PCWE-522→MCWE-523→MCWE-526←PCWE-539←PCWE-591←PCWE-599←PCWE-649←P →PCWE-656←P →MCWE-757←P →PCWE-759←P →MCWE-760←P →MCWE-780←P →MCWE-798→MCWE-836←PCWE-916→PCWE-923→PCWE-924←P →M
Why these map — AI rationale (under review)
- CWE-1204blocks — Mandates correct use of cryptography, directly requiring strong, unpredictable IV generation for primitives that need it.
- CWE-1240blocks — Mandates approved cryptographic controls, directly preventing use of risky or non-compliant implementations.
- CWE-1241blocks — A.8.24 requires selecting and correctly applying approved cryptographic algorithms for protection needs; it does not address or stop the use of a weak/predictable PRNG algorithm that produces the CWE-1241 defect
- CWE-1270blocks — A.8.24 governs the selection, strength, key management and deployment of cryptography to protect information per policy; it has no bearing on whether a security token generation mechanism produces correct (or incorrect) tokens that differentiate permitted actions.
- CWE-1279blocks — A.8.24 mandates proper use of cryptography (algorithms, key management, protection levels) but does not address or stop the timing/ordering defect of performing a cryptographic operation before its supporting inputs or units are ready.
- CWE-1291blocks — A.8.24 mandates proper cryptographic use, key management and algorithm selection but contains no requirement that signing keys be distinct between debug and production builds; the weakness of key re-use can still be present and exploitable even when the control is fully implemented.
- CWE-1323blocks — Cryptography can be applied to encrypt trace data at rest or in transit.
- CWE-1394blocks — A.8.24 requires determining and applying appropriate cryptography per policy and classification; it does not stop a default key from being present or from being exploitable when one is used
- CWE-256blocks — A.8.24's purpose, guidance (b,c), and key management rules mandate applying cryptography to protect stored sensitive information (including passwords) per classification, which stops plaintext-storage exploitation; the bounded remainder is non-cryptographic password stores (e.g. memory-only or non-classified) where the clause's rules on 'when using' do not force encryption.
- CWE-261blocks — Requires appropriate use of cryptography, indirectly discouraging weak encoding schemes.
- CWE-290blocks — A.8.24 mandates proper use of cryptography for confidentiality/integrity/authenticity of information per policy and classification; it has no bearing on incorrectly implemented authentication schemes or spoofing attacks that bypass them, so the weakness remains fully exploitable.
- CWE-294blocks — Cryptographic protections (e.g., nonces, timestamps, message authentication codes) make captured authentication messages unusable for replay.
- CWE-295blocks — Requiring issuance and validation of public-key certificates under an approved policy reduces the chance that certificates with improper validation will be trusted.
- CWE-296blocks — A.8.24 requires proper use of cryptography per policy, including key management and algorithm selection, but contains no requirement to validate or follow a certificate's chain of trust to a root; improper chain validation (CWE-296) can still be present and exploitable even when cryptography is used correctly elsewhere.
- CWE-296removes — A.8.24 mandates proper use of cryptography (including key management and certificate practices) but does not itself remove or correct an existing improper chain-of-trust validation flaw already present in product code; that requires a code change.
- CWE-297blocks — A.8.24 mandates proper use of cryptography (algorithms, key management, certificates for protection) but does not address or stop exploitation of a certificate-hostname validation flaw in the product's TLS handshake logic
- CWE-297removes — A.8.24 mandates proper use of cryptography (including key management and certificate practices) but does not remove existing improper certificate validation logic or host-mismatch flaws in first-party code; that requires code changes, not cryptographic policy or key procedures.
- CWE-298blocks — A.8.24 requires proper use of cryptography per policy, including key management and algorithm selection, but says nothing about validating certificate expiration dates; an expired but unvalidated certificate can still be accepted and exploited.
- CWE-298removes — A.8.24 mandates proper use of cryptography (including key management and certificate practices) to protect information but does not mandate or perform validation of certificate expiration dates; the code-level flaw in CWE-298 therefore remains present after the control is applied.
- CWE-299blocks — A.8.24 mandates proper use of cryptography, key management and certificate handling where cryptography is applied, but does not require or enforce any check of a certificate's revocation status; the weakness (and its exploitability) can remain fully present even in a system that faithfully follows the clause.
- CWE-299removes — A.8.24 mandates proper use of cryptography and key management (including revocation handling in key lifecycle) but does not remove the specific first-party code defect of failing to check certificate revocation status; that is a design/implementation flaw addressed by secure coding or testing, not by mandating cryptographic usage.
- CWE-300blocks — Cryptography provides channel integrity and can support endpoint authentication.
- CWE-301blocks — A.8.24 governs selection, implementation and key management of cryptography for confidentiality/integrity/authenticity; it has no bearing on protocol design that would stop a reflection attack from succeeding when the weakness is present
- CWE-311removes — created from the owner's anchor; an owner grade is a row and does not wait for an instrument (Mythos 2026-09-29T15:58Z).
- CWE-312removes — created from the owner's anchor; an owner grade is a row and does not wait for an instrument (Mythos 2026-09-29T15:58Z).
- CWE-313blocks — Cryptography control directly mandates encryption of sensitive data at rest.
- CWE-314blocks — Cryptographic controls directly prevent cleartext storage of sensitive registry data.
- CWE-315blocks — Mandates use of cryptography to protect sensitive data, directly preventing cleartext cookie storage.
- CWE-316blocks — Cryptographic controls can mandate encryption of sensitive data in memory, directly reducing cleartext exposure.
- CWE-317blocks — A.8.24 requires proper use of cryptography to protect information (including at rest on devices/storage), but does not itself stop the GUI from storing sensitive data in cleartext; that requires another control (e.g. access enforcement or DLP) to act on the protected data, making this a dependency rather than a prevention effect per the owner's rule
- CWE-318blocks — Cryptographic controls directly prevent cleartext storage of sensitive data in executables.
- CWE-321blocks — Key-management controls that govern generation, rotation and protection of keys make the use of embedded hard-coded cryptographic keys less likely and easier to detect.
- CWE-322blocks — Use of cryptography mandates authenticated key-exchange mechanisms, directly addressing the lack of entity authentication.
- CWE-323blocks — Mandates proper cryptographic key and nonce management, directly preventing nonce/key-pair reuse.
- CWE-324blocks — A.8.24's key management rules (including activation/deactivation dates, changing/updating keys per rules, and retiring/destroying expired ones) stop use of an expired key from being exploitable; the bounded remainder is keys whose expiration is unknown to the key management process or where the process is not followed for non-cryptographic 'passwords'.
- CWE-326blocks — Requiring the organization to define and enforce minimum cryptographic strength prevents deployment of insufficient key lengths or weak ciphers that can be brute-forced.
- CWE-327blocks — A.8.24's policy, algorithm selection, strength/quality rules, approved standards and key management directly stop use of broken/risky algorithms in most cases; the bounded remainder is non-compliant implementations or legacy systems grandfathered under the clause's own regulatory and transition guidance.
- CWE-328prevents — A.8.24's policy, algorithm selection (b,f), and key management directly require strong hashes meeting security expectations, preventing weak-hash use in most approved cryptographic contexts, but leaves a bounded remainder for non-crypto uses of hashing (e.g. data structures, non-security checksums) where the clause has no mandate.
- CWE-329blocks — Mandates proper cryptographic controls including IV generation, directly preventing predictable-IV CBC weaknesses.
- CWE-330blocks — Cryptographic controls require use of approved, sufficiently random values for keys and nonces.
- CWE-331blocks — Mandates use of cryptography that must rely on sufficient entropy sources.
- CWE-332blocks — Mandates use of cryptography that must rely on cryptographically strong RNGs, directly addressing insufficient entropy.
- CWE-333blocks — A.8.24 requires identifying protection needs then selecting/using appropriate cryptography and managing keys; it never addresses TRNG entropy sources, entropy collection, or handling of insufficient entropy, so the weakness can still arise and be exploited.
- CWE-334blocks — Cryptographic controls require adequate key/seed entropy, directly mitigating small random-value spaces.
- CWE-335blocks — A.8.24 requires proper cryptographic practices including approved PRNGs and key management but does not stop a product that already uses an incorrectly seeded PRNG from being exploitable; the weakness remains present and exploitable until the flawed implementation is fixed.
- CWE-336blocks — A.8.24 requires proper use of cryptography (including approved algorithms, key management, and protection of keys) but does not address or stop the use of a static/reused PRNG seed; the weakness can still be present and exploited.
- CWE-337blocks — A.8.24 requires proper use of cryptography (algorithms, key management, protection of information) but does not address or stop the use of a predictable PRNG seed; the weakness can still arise and be exploited in any cryptographic implementation that follows the clause.
- CWE-338blocks — Mandates use of approved cryptographic controls, directly requiring cryptographically strong RNGs.
- CWE-339blocks — Mandates use of cryptography that must rely on cryptographically strong PRNGs with adequate seed entropy.
- CWE-340blocks — Cryptographic controls require use of approved, sufficiently random algorithms and key-generation methods, directly mitigating predictable number/identifier weaknesses.
- CWE-341blocks — Cryptographic controls replace predictable values with high-entropy, non-guessable material.
- CWE-342blocks — Cryptographic controls require use of approved, unpredictable RNGs, directly mitigating predictable-value weaknesses.
- CWE-343blocks — Cryptographic controls require use of approved, unpredictable RNGs, directly mitigating predictable value sequences.
- CWE-345blocks — A.8.24's guidance on identifying protection levels, selecting algorithms/strength for authenticity/integrity (items b,f), using cryptography for transmitted/stored data (c), and key management directly stops many CWE-345 exploits by ensuring verifiable authenticity; however, it leaves a bounded remainder where verification logic itself is flawed or absent (e.g. accepting unverified signatures or weak schemes), as the control depends on correct implementation in other mechanisms.
- CWE-347blocks — A.8.24 mandates proper use and key management of cryptography (including for signatures) but does not itself verify any signature; improper verification (CWE-347) can still be present and exploitable in code that applies the approved algorithm.
- CWE-353blocks — Cryptographic controls can provide integrity verification for transmitted data.
- CWE-354blocks — Cryptographic controls mandate integrity mechanisms whose correct validation directly prevents CWE-354.
- CWE-358blocks — Use of cryptography control depends on correct implementation of standardized cryptographic checks.
- CWE-360blocks — Cryptography can protect event integrity and authenticity but is not explicitly required by the control for this purpose.
- CWE-419blocks — Cryptography can protect confidentiality and integrity of the primary channel.
- CWE-5blocks — A.8.24's purpose, guidance (c), and key management mandate proper cryptography (including for data in transit) per identified protection needs, which stops in-transit compromise of plaintext/weakly-encrypted J2EE data; remainder is bounded (e.g. misconfigurations that ignore the policy or use of unapproved weak algorithms).
- CWE-522blocks — A.8.24's purpose, guidance (b,c), and key management mandate proper cryptography (algorithms, strength, protection of credentials in storage/transmission) per classification, which stops exploitation of insufficiently-protected credentials; remainder is bounded (e.g. non-cryptographic protections like hashing-only or non-crypto obfuscation per CWE-522 details).
- CWE-523blocks — Requires use of cryptography, directly enabling encryption of credentials in transit.
- CWE-526blocks — A.8.24 requires determining and applying cryptography per policy and classification to protect confidentiality (including on storage media and endpoint devices), but does not itself stop an environment variable from being populated in cleartext; that remains an exploitable weakness until another control (e.g. key management or access enforcement) acts on the classification.
- CWE-555blocks — A.8.24 requires proper use of cryptography (including for stored information per its guidance) but does not stop a J2EE config file from containing a plaintext password; the weakness remains present and exploitable until the password is removed from the file or the credential is replaced with a non-password mechanism.
- CWE-599blocks — Mandates proper use of cryptography including certificate validation, directly addressing the missing SSL_get_verify_result() check.
- CWE-649blocks — Cryptographic controls must include integrity mechanisms (e.g., MACs, signatures) to detect tampering of protected data.
- CWE-656blocks — Mandates use of cryptography whose strength is independent of secrecy of design or keys.
- CWE-757blocks — A.8.24 requires selecting strong approved algorithms per policy and classification (b,f), which can stop downgrade by mandating only-strong options; but the weakness lives in the negotiation protocol/implementation itself, and the clause does not reach or alter that design, leaving a bounded remainder (e.g. protocol-level downgrade attacks even with approved ciphers).
- CWE-759blocks — Use of cryptography requires appropriate cryptographic controls including salting for password hashing.
- CWE-760blocks — Use of cryptography requires appropriate cryptographic controls including proper salting, largely mitigating predictable-salt weaknesses.
- CWE-780blocks — Mandates proper use of cryptography, directly requiring OAEP with RSA.
- CWE-916blocks — Requires appropriate use of cryptography, which encompasses selecting strong hashing algorithms for passwords.
- CWE-923blocks — Cryptography can protect channels but does not guarantee correct endpoint identity without additional controls.
- CWE-924blocks — A.8.24's rules on algorithm selection, key management, and protecting transmitted information (esp. guidance c) directly stop modification-in-transit by mandating integrity-providing cryptography; remainder is bounded to non-crypto integrity mechanisms (e.g. non-repudiation-only schemes or physical-layer protections)
- CWE-940blocks — A.8.24 mandates proper use of cryptography (algorithms, key management, protection of data in transit/storage) but has no bearing on whether a product correctly verifies the origin of an incoming communication channel; the weakness can still be present and exploited regardless of cryptographic controls.
Mitigated MITRE ATT&CK techniques (284)
Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
T1001←MT1001.001←MT1001.002←MT1001.003←MT1006←MT1011←MT1014←MT1021.004→PT1027→PT1027.001←MT1027.002←MT1027.003←MT1027.005←MT1027.006←MT1027.007←MT1027.008←MT1027.009←MT1027.010←MT1027.011←PT1027.012←MT1027.013←MT1027.014←MT1027.015←MT1027.016←MT1027.017←MT1027.018←MT1030←MT1036←MT1036.003←MT1036.005←MT1036.008←MT1036.009←PT1040→MT1041→PT1048→PT1048.001→PT1048.003←M →PT1052←MT1055←M →PT1055.001←MT1055.002←MT1055.003←M →PT1055.004←MT1055.005←MT1055.008←MT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←MT1055.015←MT1068←PT1070←MT1071.001←MT1071.004←MT1071.005←MT1078←P →PT1090←MT1090.002←MT1090.003←MT1090.004←MT1095←MT1098.001←MT1098.004←MT1098.005←MT1102←MT1102.001←MT1102.002←MT1102.003←MT1110→MT1110.001→MT1110.002→MT1110.003→MT1110.004→MT1111←M →PT1127←MT1127.001←MT1132←PT1132.001←MT1132.002←MT1133←MT1134←MT1185←MT1204.004←PT1205←PT1207←MT1211←PT1216←MT1218←MT1218.005←MT1218.007←MT1218.008←MT1218.009←MT1218.010←MT1218.011←PT1218.012←MT1218.013←MT1219.003←MT1220←PT1221←PT1222.002←MT1480.001←MT1484←PT1484.002←PT1485→PT1486→MT1490←MT1497←PT1499.002←PT1528→PT1530→PT1535←MT1537←MT1539←F →PT1542←MT1542.002←MT1542.003←MT1548←PT1550←FT1550.001←FT1550.002←FT1550.003←F →PT1550.004←FT1552←M →PT1552.001←P →PT1552.004→PT1553←P →PT1553.001←MT1553.002←PT1553.003←MT1553.004←MT1553.005←PT1553.006←MT1555→PT1555.001←M →PT1555.002←PT1555.003←MT1555.004→PT1555.005←P →PT1555.006←M →PT1556←MT1556.001←MT1556.003←PT1556.005←P →PT1556.006←MT1556.007←MT1556.008←MT1556.009←MT1557←M →MT1557.004←M →PT1558←M →PT1558.001←PT1558.002←MT1558.003→PT1558.004→PT1560←P →PT1561→PT1561.001→MT1561.002→MT1565→PT1565.001→PT1565.002←P →PT1567.004←PT1568.003←MT1571←MT1572←M →PT1573←MT1573.001→PT1573.002→PT1574←PT1574.001←MT1574.004←MT1574.013←MT1578←PT1578.002←MT1578.003←MT1578.004←MT1588.004←PT1589.001→PT1599←MT1599.001←PT1600←M →PT1600.001→MT1600.002←MT1601.001←MT1601.002←MT1606←MT1606.001←F →PT1606.002←M →PT1610←PT1612←PT1620←MT1621←M →MT1622←MT1647←PT1649→PT1665←PT1666←PT1678←PT1684.002→PT1685←MT1685.002←MT1685.003←PT1685.004←MT1685.005←MT1686←FT1686.001←MT1686.003←MT1687←PT1688←MT1689←M
Why these map — AI rationale (under review)
- T1021.004prevents — A.8.24 requires proper cryptography (algorithms, key management, strength, approved practices) for protecting authenticity/integrity of remote access including SSH keypairs, which directly stops the public-key authentication path of this technique when followed; the bounded remainder is password-based SSH auth that does not rely on cryptography.
- T1027prevents — A.8.24 mandates approved cryptographic algorithms, key management and usage rules that can prevent certain classes of encryption-based obfuscation (e.g. weak or prohibited ciphers for payloads in transit or at rest) but does not stop encoding, compression, splitting, command obfuscation or other non-cryptographic forms of T1027.
- T1040prevents — Requiring encryption of data in transit and proper key protection reduces the value an attacker gains from passively capturing network packets.
- T1041detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities, which can surface anomalous exfiltration patterns hidden in C2 traffic when those controls or logs are in scope; this is only a slice because the clause governs cryptography usage rather than mandating broad network or protocol anomaly detection.
- T1048detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection, content filtering) and mandates logging/auditing of key-management activities, which can surface anomalous use of encrypted alternate protocols; this is only a minority slice of the broad technique that also covers unencrypted channels, non-crypto utilities, and direct cloud-console downloads.
- T1048.001detects — A.8.24 requires monitoring/auditing of key management activities and consideration of cryptography's impact on content-inspection controls (e.g. malware detection), which can surface anomalous use of symmetric encryption for exfiltration as a side effect, but the clause's core focus is proper implementation and key handling rather than broad detection of adversary TTPs.
- T1048.003detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities, which can surface anomalous unencrypted exfiltration as a policy or configuration deviation; this is only a minority slice of the technique because the clause governs cryptography usage rather than mandating network or protocol anomaly detection.
- T1048.003prevents — A.8.24 requires identifying protection needs, mandating appropriate cryptography (including for data in transit over networks), and adopting approved algorithms/strengths; this directly stops unencrypted exfiltration by forcing encryption on sensitive data flows, but remains partial because the control is scoped to organization-defined requirements and classification (allowing unencrypted flows for data not deemed sensitive) and does not govern all possible non-C2 protocols or adversary-chosen alternate locations.
- T1055detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates cryptographic solutions that can be audited/logged, which surfaces some process-injection attempts that rely on or interact with encrypted payloads or keys, but the clause does not mandate or perform detection of the injection technique itself.
- T1055.003detects — A.8.24 requires monitoring the impact of encryption on content-inspection controls (e.g. malware detection) and mandates logging/auditing of key-management activities; this surfaces anomalies tied to encrypted payloads or key misuse that can accompany thread hijacking, but the clause does not mandate host/process behavioral monitoring that would catch the core SuspendThread/WriteProcessMemory/SetThreadContext sequence itself.
- T1078prevents — A.8.24 mandates strong cryptography (including for authentication, key management, and endpoint/storage protection) which can stop credential compromise or abuse in specific slices such as network transit, stored secrets, or weak auth protocols, but leaves the bulk of the technique (e.g. phishing, inactive accounts, local privilege overlap, non-crypto auth) untouched.
- T1110prevents — A.8.24 mandates appropriate cryptographic strength, key management, and MFA-capable authentication mechanisms (via policy and approved standards) that stop offline brute-force on hashes and most online guessing; the named remainder is legacy or exempted accounts that still rely on weak single-factor secrets.
- T1110.001prevents — A.8.24 requires appropriate cryptographic authentication (e.g. MFA, strong algorithms, key management) that stops password guessing from yielding access on covered services and endpoints; the named remainder is exempted identities, legacy protocols, and non-cryptographic paths the clause itself acknowledges.
- T1110.002prevents — A.8.24 mandates appropriate cryptographic algorithms, key management and strength calibrated to data classification; where password hashes use approved strong, salted, slow KDFs the cracking technique is prevented from recovering usable plaintext, with the bounded remainder being weak/legacy hashes or non-cryptographic storage that the clause's own guidance on classification and approved algorithms leaves nameable.
- T1110.003prevents — A.8.24 mandates appropriate cryptographic strength, key management, and usage rules (including for authentication protocols and endpoints); where this results in strong MFA, encrypted channels, or password-hashing that defeats cleartext spraying, the technique cannot succeed — matching the A.8.5→T1110.001 anchor — but exemptions, legacy protocols, and non-crypto vectors leave a bounded remainder.
- T1110.004prevents — A.8.24 mandates appropriate cryptographic protection (including strong auth mechanisms such as MFA or cryptographic tokens) proportionate to data classification and risk, which stops credential-stuffing attacks from succeeding on covered services and accounts; the named remainder is legacy protocols, exempted identities, or static secrets that bypass the mandated cryptography.
- T1111prevents — A.8.24 requires appropriate cryptography (including key management and strength) for protecting credentials and transmitted MFA factors such as one-time codes; this stops some interception vectors (e.g. plaintext SMS/email, weak token crypto) but leaves keyloggers, hardware-token proxying, seed compromise, and out-of-band device compromise untouched.
- T1485recovers — A.8.24's key management explicitly requires secure backup/archiving of keys plus recovery of encrypted information in case of lost, compromised or damaged keys, directly enabling restoration of availability for data destroyed via encryption-based destruction (a common real-world vector for T1485) while leaving non-crypto deletion cases as named remainder.
- T1486recovers — A.8.24's key management explicitly requires processes for recovering encrypted information in the case of lost, compromised or damaged keys, directly enabling restoration of availability after ransomware encryption (the named remainder is data for which no recoverable key was retained).
- T1528prevents — A.8.24 requires proper cryptography (including key management, strength, and protection of secrets) for confidentiality/integrity/authenticity per policy; this can prevent some token-theft vectors (e.g. weak transmission, poor key handling for OAuth/JWTs, or unencrypted storage) but leaves the dominant social-engineering, compromised-container, and post-auth token-abuse slices untouched.
- T1530prevents — A.8.24 mandates use of cryptography (algorithms, key management, strength per classification) to protect confidentiality of information including data at rest in cloud storage, which directly stops the technique when the data is encrypted and the adversary lacks the key; it is only partial because the control governs cryptography where used rather than mandating encryption for all cloud objects (misconfigurations and credential abuse can still yield plaintext access).
- T1539prevents — A.8.24 requires protecting confidentiality/integrity of information (including in transit and on endpoints) via appropriate cryptography and key management; this can prevent cookie theft from network traffic or at-rest storage via encryption (and related practices), but leaves the dominant vectors (in-memory theft, malicious JS injection, proxy/AitM frameworks, malware scraping) untouched.
- T1550.003prevents — A.8.24 mandates proper key management, algorithm strength, and protection of keys (including against compromise, loss, or unauthorized use) which can prevent generation or successful use of forged Golden/Silver tickets and overpass-the-hash variants that rely on stolen/weak keys, but leaves the core PtT technique (reusing already-stolen valid tickets obtained via credential dumping) untouched.
- T1552prevents — Enforcing encryption of sensitive information on endpoints and storage media limits an attacker’s ability to locate and read credentials stored in files or configuration stores.
- T1552.001prevents — A.8.24 requires identifying protection needs then mandating appropriate cryptography (including for data at rest on devices/storage and in transit), which directly stops many classes of insecure plaintext credential storage in files; it leaves the remainder of non-crypto cases (e.g. OS-protected stores, misconfigured access controls on already-encrypted files, or credentials embedded in code that never reach a protected store).
- T1552.004prevents — A.8.24 mandates proper key generation, protection, storage, access controls, and usage practices that stop many insecure-storage cases (and therefore the search), but leaves residual exposure from implementation gaps, legacy keys, or keys already present before the control applies.
- T1553prevents — A.8.24 requires approved cryptographic standards, key management, and proper use of signing/encryption to establish trust (e.g. valid code signing certificates), which directly stops some subversions that rely on weak, stolen, or improperly managed keys; it does not address non-crypto trust controls, attribute modification, or registry changes that enable the technique.
- T1555prevents — A.8.24 requires identifying protection levels, selecting appropriate cryptography/strength, and protecting keys/storage/transmission (including on endpoints and in vaults), which can prevent plaintext credential extraction from many common stores; however, it does not mandate encryption for all password stores or block all search-based extraction methods, leaving a genuine slice unreached.
- T1555.001prevents — A.8.24 mandates proper key management (generation, protection, storage, rotation, revocation) and approved cryptographic practices that, when applied to credentials stored in the Keychain, stop many common extraction paths (e.g., by enforcing strong protection of the master password, key wrapping, or hardware-backed keys); however, the control is silent on the specific macOS Keychain implementation details, default user-password equivalence, and non-cryptographic access vectors such as memory scraping or unlocked-session dumping, leaving a substantial slice of the technique reachable.
- T1555.004prevents — A.8.24 requires proper cryptography (including key management and strength) for protecting stored credentials; this can stop plaintext recovery or weak encryption of .vcrd/Policy.vpol files, but the technique also covers non-crypto vectors such as vaultcmd.exe enumeration, direct API abuse (CredEnumerateA), and GUI backup extraction that cryptography does not block.
- T1555.005prevents — A.8.24 mandates proper cryptography (including key management and strength) for protecting stored credentials; this directly stops the encrypted-database slice of the technique when the password manager follows the rules, but leaves memory extraction after unlock, brute-force of the master password, and non-compliant implementations untouched.
- T1555.006detects — A.8.24's key-management logging/auditing and consideration of controls that rely on content inspection (e.g. malware detection) can surface anomalous access or use of secrets managers, but this is scoped only to cryptographic-key activities rather than the broader technique of privileged API retrieval of any credential material.
- T1556.005detects — A.8.24's key-management logging/auditing and consideration of encrypted-information impacts on content-inspection controls (e.g. malware detection) can surface anomalous reversible-encryption settings or related credential-access activity, but this is incidental and not required by the clause's core purpose of proper cryptographic use.
- T1557prevents — Mandating approved cryptographic algorithms and key-management procedures for network traffic makes it harder for an adversary to intercept and manipulate traffic in order to steal credentials.
- T1557.004prevents — A.8.24 requires proper cryptography (including certificates, key management, and protection of transmitted data) that can stop evil twin MITM from succeeding on HTTPS traffic via custom certs or weak encryption, but the core technique of spoofing SSIDs, stronger signals, or probe responses to induce connection happens before any crypto is applied and is not addressed by the control.
- T1558detects — A.8.24's key-management logging/auditing and consideration of encrypted-information impacts on content inspection (e.g. malware detection) can surface anomalous Kerberos ticket activity or related artifacts, but this is limited to specific cryptographic-use cases rather than broadly detecting ticket theft or forgery across platforms.
- T1558prevents — A.8.24 requires proper key management, algorithm strength, and protection of keys (including against compromise, loss, or unauthorized use), which directly prevents many forgery and theft vectors for Kerberos tickets that rely on weak keys, poor key handling, or exposed long-term keys; however, it does not address all ticket-stealing methods such as memory scraping of valid TGTs or protocol abuses that do not involve key compromise.
- T1558.003prevents — A.8.24 requires approved strong cryptography, key management, and consideration of algorithm strength; mandating modern ciphers (e.g., AES over RC4) for Kerberos would stop etype 23 TGS tickets from being issued, preventing the vulnerable hash from existing and thus the offline brute-force technique, but this is only a slice because the control sets requirements rather than universally enforcing removal of RC4 support or weak SPN configurations across all environments.
- T1558.004prevents — A.8.24 requires approved strong algorithms, key management, and protection of authentication data in transit/storage; this directly stops the insecure (e.g. RC4) encryption of AS-REP messages that the technique relies on, but only for systems built under the control and leaves a remainder where pre-auth is disabled or legacy weak crypto is still permitted.
- T1560detects — A.8.24's key-management logging/auditing and impact considerations on content-inspection controls (e.g. malware detection) can surface anomalous cryptographic use or encrypted blobs that match T1560's pre-exfil artifact, but the clause is scoped to approved organizational cryptography rather than broadly detecting adversary compression/encryption of arbitrary collected data.
- T1561recovers — A.8.24's key management explicitly requires backing up/archiving keys and recovering encrypted information in case of lost, compromised or damaged keys, which directly enables recovery from a disk-wipe that has destroyed key material or rendered encrypted volumes inaccessible; this is only a slice of the full technique (arbitrary sector/MBR wipes, config erasure on network devices, worm-like propagation) so the extent is partial rather than mostly or full.
- T1561.001recovers — A.8.24's key-management guidance explicitly requires processes for recovering encrypted information in the case of lost, compromised or damaged keys, and for backing up/archiving keys; this directly restores availability of data rendered irrecoverable by disk-content wipe when that data had been protected by organization-approved cryptography.
- T1561.002recovers — A.8.24's key management explicitly requires secure backup/archiving of keys plus recovery of encrypted information when keys are lost, compromised or damaged; this directly restores availability after a disk-structure wipe that renders encrypted volumes or boot-critical encrypted structures unusable.
- T1565prevents — A.8.24 mandates cryptographic protection of integrity (and authenticity) for information at rest/transit per policy and classification, which directly stops many classes of unauthorized insertion/deletion/manipulation that would otherwise succeed; it leaves open non-cryptographic vectors, insider-authorized changes, and post-decryption manipulation.
- T1565.001prevents — A.8.24 mandates use of cryptography (with appropriate strength, key management, etc.) to protect integrity of information at rest; this directly prevents many forms of stored-data manipulation by rendering unauthorized modification detectable or infeasible, but leaves a genuine slice unaddressed (e.g., manipulation before encryption, insider-authorized changes, or non-cryptographically-protected data stores).
- T1565.002detects — A.8.24's key-management logging/auditing and consideration of encrypted-data impact on content-inspection controls (e.g. malware detection) can surface anomalous cryptographic or transmission behavior, but the clause's core focus is proper use and protection rather than mandating detection of in-transit manipulation.
- T1565.002prevents — A.8.24 mandates use of cryptography (algorithms, key management, strength) to protect integrity of information in transit per requirements, which directly stops alteration of transmitted data where encryption, MACs or signatures are applied; partial because the clause sets requirements rather than a universal mechanism (implementation scope, non-crypto channels, and cases where integrity protection is not selected leave a slice uncovered).
- T1572prevents — A.8.24 mandates approved cryptographic algorithms, key management and usage rules that can legitimately prevent classes of unauthorized tunneling (e.g. requiring only organization-approved SSH/DoH configurations with managed keys and no unauthorized outer-layer encryption), but leaves many tunneling variants (custom protocols, non-crypto encapsulation, approved-but-abused tunnels) untouched.
- T1573.001detects — A.8.24's key management, logging/auditing of crypto activities, and consideration of impact on content inspection (e.g. malware detection) can surface anomalous or non-compliant use of symmetric crypto in C2 traffic, but this is limited to cases where the implementation falls inside the organization's approved standards rather than the technique itself.
- T1573.002prevents — A.8.24 mandates approved cryptographic standards, algorithms, key management and usage rules that, when followed, stop adversaries from employing weak or non-standard asymmetric crypto for C2; however the control only governs what the organization itself deploys and does not block an adversary from choosing strong, standards-compliant asymmetric crypto (e.g. TLS) for their own C2 channel.
- T1589.001prevents — A.8.24 mandates proper cryptography (including key management, strength selection, and MFA-supporting auth) that stops many credential-gathering vectors such as weak storage, transit exposure, or insufficient MFA, but leaves open elicitation, leaks of already-encrypted data, dark-web purchases, and infostealer logs.
- T1600prevents — A.8.24 requires approved cryptographic standards, key management, and strength selection that would stop many weakening vectors (e.g. weak ciphers, poor key generation, disabled hardware) on devices built under it, but does not reach post-deployment compromise of already-deployed network devices or their images.
- T1600.001detects — A.8.24 requires logging/auditing of key management activities plus consideration of cryptography's impact on content inspection controls; this can surface anomalous key-size or cipher-strength changes on managed devices as part of key-management monitoring, but the clause does not mandate network or device telemetry that would catch the technique in general use.
- T1600.001prevents — A.8.24 requires selecting, mandating and enforcing approved cryptographic algorithms, cipher strength, key sizes and usage practices (including via topic-specific policy and standards), which directly stops the technique of deliberately weakening key space on managed devices; the bounded remainder is post-compromise modification of already-deployed images that bypass policy enforcement.
- T1606.001prevents — A.8.24 mandates proper cryptographic practices including key management, algorithm strength, and protection of secrets; this directly constrains the cryptographic seed values/private keys required to forge valid cookies, but leaves non-crypto forgery vectors, weak implementations, and legacy/legacy-exempt cookie schemes as an open slice.
- T1606.002prevents — A.8.24 requires proper key management, algorithm strength, and approved cryptographic practices that directly stop an adversary from obtaining or forging with a valid token-signing certificate when those rules are followed; the remainder is the case where the adversary can establish their own trusted certificate via sufficient permissions, which the clause does not address.
- T1621prevents — A.8.24 requires appropriate strength and MFA-appropriate authentication techniques (including push, SMS, app-based) proportionate to data classification, directly preventing the generation of weak or fatigue-vulnerable MFA requests from succeeding in granting access.
- T1649prevents — A.8.24's key-management rules (generation, protection, storage, revocation, destruction, and handling of compromised keys) directly constrain the theft of private keys from storage or the CA and the forging of golden certificates, but the control is silent on enrollment-rights hygiene, SAN/EKU misconfigurations, and certificate misuse after issuance, leaving a large remainder of the technique reachable.
- T1684.002prevents — A.8.24 requires use of cryptography (including DKIM digital signatures for email integrity/authenticity) per policy and standards, which when enforced prevents header-spoofing that would otherwise pass authentication; it does not govern non-crypto vectors such as Direct Send, weak/absent DMARC policy, or SPF-only failures.
Prevented OWASP Web Top 10 (2025) risks (1)
OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- A04blocks — A.8.24's purpose and guidance directly mandate identifying protection needs then selecting/using appropriate algorithms, key management, and approved practices, which closes the bulk of absent/weak/misused cryptography that the A04 class names; the bounded remainder is legacy data already at rest with no re-encryption trigger and cases where the approved algorithm is later broken.
Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.