Architect Infrastructure and System Cryptographic Solutions

A requirement arrives reading "customer records must be protected in line with the retention policy". It names no algorithm, no key length, no protocol, and no point in the data's life where the protection applies, and reaching for AES-256 out of habit answers none of those. What turns a sentence like that into a design is a fixed order of four decisions, and the order matters because each one narrows the next.

The sibling page before this one places infrastructure controls on the components that can enforce them, and the identity architecture that later consumes the certificates and keys produced here belongs to the next domain. This page covers the cryptographic design in between.

The four decisions

1. Service. Name the security property the requirement actually needs. Confidentiality keeps content unreadable, integrity detects modification, source authentication ties data to a party, and non-repudiation produces evidence a third party can weigh. Requirements rarely say which one they mean, so this step is translation work.
2. Mechanism. Choose the primitive that supplies that service. This is where encryption, message authentication codes, digital signatures, and hashes stop being interchangeable vocabulary and start being different answers.
3. State. Decide where the data is when the protection applies: at rest in storage, in transit across a path, or in use inside a running process. The state decides what an attacker who reaches the system can still see.
4. Key lifecycle. Plan how keying material is generated, established, distributed, stored, used, rotated, revoked, recovered, and destroyed. NIST SP 800-57 Part 1^[1] treats this as a full lifecycle rather than a storage question.

The constraints that bound all four

Four constraints sit outside the sequence and limit every decision in it: the computational capability of the platforms involved, the assurance a validated cryptographic module actually provides, the implementation attacks the deployment is exposed to, and the standards transition the design will eventually have to survive. They are constraints rather than steps because none of them can be satisfied by choosing differently at a single step; they narrow what any of the four choices may be. The figure below traces the four decisions in order, with that constraint band beneath them.

Working the sequence in order is what keeps a design honest. Starting at step 2 with a favorite algorithm produces the classic outcome where a system encrypts diligently and still cannot prove who sent anything.

Decision 2 has one rule: pick the primitive that supplies the service you named, and check what it leaves unsupplied. No primitive delivers every property, and most cryptographic design errors are a mechanism doing exactly what it promises while the requirement needed something else.

What each primitive supplies

Encryption supplies confidentiality. It transforms plaintext so that recovering it requires a key, and by itself it says nothing about whether the ciphertext arrived unmodified.

A message authentication code (MAC) supplies integrity and source authentication between parties that already share a secret key. FIPS 198-1^[2] specifies HMAC, the keyed-hash construction most commonly used for this. Because both parties hold the same key, either could have produced any given tag, which is exactly why a MAC cannot settle a dispute between them.

A digital signature supplies integrity, origin evidence, and verification by a party who holds only the public key. FIPS 186-5^[3] specifies the approved signature algorithms. The asymmetry is the point: only the private-key holder can produce the signature, so a third party can attribute it without ever holding a secret.

A cryptographic hash supplies neither confidentiality nor, on its own, authenticity. FIPS 180-4^[4] defines the approved hash functions, which produce a fixed-length digest with no decryption key involved. Hashing a value drawn from a small or predictable set conceals nothing, because an attacker computes the digests of the candidates and compares. Password storage is the standard illustration of the difference: a plain hash is inadequate there, and the OWASP password storage guidance^[5] calls for a deliberately slow, salted construction, and CWE-916 names the weak-computational-effort case directly.

Two combinations worth naming

Authenticated encryption with associated data (AEAD) combines confidentiality and modification detection in one construction, producing an authentication tag alongside the ciphertext. NIST SP 800-38D^[6] specifies GCM, the widely deployed example. Where both properties are required, an approved AEAD construction is the default answer, because encryption without an integrity mechanism leaves ciphertext an attacker can manipulate undetected even while unable to read it.

Signing does not encrypt. A signed document travels in the clear with a verifiable attribution attached, so content that must also stay secret is encrypted separately. The reverse mistake, assuming ciphertext is self-authenticating, is the one AEAD exists to prevent.

The comparison table in this page's overview lays these mechanisms against the same properties side by side, and its encryption column is the authenticated form: plain encryption is that column with the modification-detection row answered no. Read it as the answer key for decision 2, and treat every requirement that names two properties as a requirement for either a combined construction or two mechanisms applied deliberately.

Symmetric and asymmetric cryptography are not competing answers to one question; production designs can use both, each where its cost profile fits. Symmetric algorithms protect bulk data efficiently but require the communicating parties to securely establish and hold the same secret key. Asymmetric techniques carry signatures and key establishment without any pre-shared pairwise secret, at higher computational cost and with a trust model that has to be built, published, and maintained.

The hybrid pattern

The standard resolution is a hierarchy. Asymmetric key establishment sets up a symmetric key, the symmetric key does the bulk work, and the asymmetric layer is used sparingly. TLS is the everyday instance of this pattern, and so is nearly every storage encryption service.

Envelope encryption is the storage form of that hierarchy. Data is encrypted under a data-encryption key (DEK), and the DEK itself is encrypted under a separately managed key-encryption key (KEK), so the wrapped DEK can be stored next to the ciphertext it protects. Cloud key services implement this directly; AWS KMS^[7] documents envelope encryption as its core pattern, and Azure Key Vault offers the same separation between a protected key and the data keys it wraps.

Two architectural properties follow, and they are the reason to choose the pattern rather than encrypting everything under one long-lived key:

• Rotating the KEK means rewrapping the DEKs, not re-encrypting the data. A rotation that would otherwise mean rewriting petabytes becomes a metadata operation.
• Destroying the KEK renders every DEK it wrapped unusable, which is the mechanism behind cryptographic erasure discussed later on this page.

The figure below shows the hierarchy with those two KEK operations attached.

Constrained platforms

Computational capability is a real constraint here, not a footnote. Operational technology controllers, sensors, smart cards, and battery-powered devices may not sustain frequent asymmetric operations, and a design that assumes otherwise fails in the field rather than in review. The usual accommodations include longer-lived symmetric keys with tighter physical protection, key establishment performed at provisioning time rather than per session, and gateway devices that terminate the expensive protocol on behalf of a fleet. Each accommodation trades something, and the trade belongs in the design record rather than in an implementer's head.

An algorithm with no known mathematical weakness can still be defeated by the system around it, and an architect who evaluates only the algorithm has reviewed the smallest part of the attack surface. The threat model for a cryptographic design has to include the ways an implementation leaks its keys.

The implementation failure classes

The classes below recur often enough to be worth checking by name on every design, and the list is representative rather than exhaustive:

• Side channels. Timing, power draw, electromagnetic emission, and cache behavior can reveal key material to an observer who never breaks the mathematics. CWE-208^[8] covers the timing case, where a comparison that returns early on the first mismatched byte hands an attacker the secret one byte at a time.
• Weak randomness. Keys, initialization vectors, and nonces drawn from a predictable source are weak whatever their nominal length. CWE-330^[9] is the general weakness, and the generation section later on this page covers the approved-generator requirement.
• Key exposure. Keys embedded in source code, images, or configuration files (CWE-321^[10]) travel wherever those artifacts travel, including into version control and backups.
• Protocol misuse. A sound primitive used outside its contract, such as reusing a nonce with a counter-mode construction or omitting the integrity check on decryption, loses the property it was chosen for.
• Fault attacks. Deliberately induced errors, through voltage or clock manipulation on a device an attacker holds physically, can make a correct implementation emit results that reveal a key.
• Insecure error handling. Distinguishable error responses, including differences in message content or response time, can turn a decryption endpoint into an oracle that answers questions about the plaintext.

Algorithm selection as a constraint

Algorithm choice belongs to this constraint layer rather than to personal preference. CWE-327 captures the general case of a broken or risky algorithm, and NIST SP 800-131A^[11] states which algorithms and key lengths remain acceptable and which have been withdrawn. Two design habits follow. Prefer approved constructions used through vetted libraries rather than assembled primitives, since most of the failure classes above are introduced during assembly. And record which algorithms and parameters a system depends on, because that record is what makes the transition planning at the end of this page possible.

The conclusion an architect should carry out of this section is uncomfortable but useful: selecting an approved algorithm is necessary and it is not evidence that the deployed system protects anything. The evidence comes from the implementation, the key handling, and the operating environment.

Every assurance claim has an edge, and for cryptography that edge is drawn explicitly. FIPS 140-3^[12] is the standard for validating cryptographic modules, and the word that carries the most weight in it is boundary.

What validation covers

A cryptographic module is a specific implementation with a declared physical or logical boundary, and validation tests that implementation against the standard's requirements. What sits inside the boundary is covered: the approved algorithms as implemented, the keys held within the module, the self-tests the module runs, and the physical or logical protections around it. What sits outside is not covered by the validation, however carefully it was built: the application logic that calls the module, the organization's key-management process, the protocol design, and the operating procedures.

That distinction is the source of a persistent architectural error. A product's validation certificate is genuine evidence about the module, and it is not a statement that the system embedding the module is secure. The figure below separates the two sides.

Choosing a level

FIPS 140-3 defines four increasing qualitative security levels, and increasing is not the same as ranked by correctness for a given deployment. Higher levels add progressively stronger physical protections and stricter requirements around roles, services, and the operating environment, all of which carry cost, procurement constraints, and often performance and operational consequences.

The level therefore follows the deployment rather than the budget's ambition. The questions that decide it are what the data is worth, who can physically reach the module, what the operating environment looks like, and what an attacker with that access could accomplish. A module in a controlled data center with monitored access is in a different situation from one in an unattended roadside cabinet, and the second may justify protections the first does not need. Selecting a level because it is the highest available, without that analysis, buys physical protections against a threat that may not exist while leaving the actual exposure, which is usually in the key-management process outside the boundary, untouched.

One practical habit closes this section. When a design claims inherited assurance from a validated module, record which functions the module actually performs in that system. A module validated for key storage and used only for key storage inherits nothing for the encryption that the application performs itself.

At-rest encryption answers exactly one question: what an adversary gets when they obtain the stored representation rather than the running system. Media pulled from a rack, a disk that left the building during decommissioning, a copied backup tape, a snapshot exported to the wrong account, and a stolen laptop all fall inside that answer.

Choosing the layer

Encryption at rest can be applied at several layers, and the layer decides both the granularity of the keys and what an attacker who compromises a running host still sees. The layers commonly available, among others, are:

Layer	Typical unit of protection	What it does not separate
Full disk or volume	The whole device or volume	Anything once the volume is mounted and unlocked
File system or file	Individual files or directories	Data readable by any process with the file's key
Object or bucket	Individual stored objects	Access already granted through the storage service
Database, column, or field	Selected columns or fields	Values the application decrypts to serve a query

The pattern down the right-hand column is the important one. Each layer narrows what an unauthorized holder of the storage can read, and none of them protects plaintext after an authorized process has unlocked the data and is reading it. A compromised application server with valid credentials sees the same plaintext the application does, no matter how the storage was encrypted.

What that means for the design

Three consequences follow, and they are the ones exam scenarios turn on.

First, at-rest encryption is not a substitute for access control. If the risk is a legitimate account misusing its access, storage encryption changes nothing, and the answer lies in authorization, monitoring, and the identity architecture the next domain covers.

Second, granularity is a design choice with an operational cost. Field-level or column-level encryption can keep sensitive values unreadable to a database administrator who legitimately administers the database, which volume encryption cannot do, and it complicates indexing, searching, and query performance. The OWASP cryptographic storage guidance^[13] covers the practical form of these trade-offs.

Third, the key hierarchy matters more than the cipher. Storage encrypted under a single long-lived key inherits every rotation and recovery problem that key has, which is why the envelope pattern described earlier is the normal answer for anything at scale.

Related protections often appear beside encryption in a data-repository design and are not encryption: redaction removes data from a copy, masking substitutes values for a class of viewer, and tokenization replaces a value with a surrogate held in a separate mapping. They serve confidentiality goals and none of them is what a requirement for encryption at rest is asking for.

An encrypted channel to an unverified endpoint is a well-protected connection to an attacker. That single sentence is the reason transit protection is never only about encryption: the peer has to be authenticated, or confidentiality is being provided to whoever answered.

The protocol choice

Transport Layer Security (TLS) protects traffic between application endpoints and is the default for most application protocols. Internet Protocol Security (IPsec) protects traffic at the network layer, which suits site-to-site connectivity and cases where the protection must be transparent to the applications involved. Both supply confidentiality and integrity, and both authenticate peers, though what counts as the peer differs: a TLS peer is typically a named service presenting a certificate, while an IPsec peer is typically a gateway or host identity. NIST SP 800-52 Rev. 2^[14] gives the selection and configuration guidance for the TLS case.

Authentication is the part that gets skipped. A client that accepts any certificate, ignores name mismatches, or trusts a store an attacker can write to has an encrypted channel and no assurance about the far end. The OWASP transport layer guidance^[15] treats validation failures as the primary implementation risk, not cipher selection.

End-to-end versus link protection

These two are not variants of one control, and the difference decides who can read the content.

With link encryption, each hop decrypts the traffic and re-encrypts it for the next hop. Every intermediary therefore handles plaintext, which is acceptable when the intermediaries are inside the trust boundary and unacceptable when they are not. A TLS-terminating load balancer, an inspecting proxy, and a managed messaging service that decrypts payloads to route them are all link-encryption topologies regardless of the protocol names involved.

With end-to-end encryption, the content stays protected between the communicating endpoints and no intermediary holds a key for it. Intermediaries can still observe routing metadata, including addresses, sizes, and timing, so end-to-end protects content rather than the fact of communication. The figure below contrasts the two topologies.

The design question is therefore not "is it encrypted" but "which parties hold a key". Any requirement that a service provider or transit network must not be able to read content is a requirement for end-to-end protection, and terminating TLS at a provider-managed component does not meet it.

Forward secrecy and early data in TLS 1.3

Two TLS 1.3 properties are commonly confused and are worth separating. Ephemeral Diffie-Hellman key exchange, written (EC)DHE, gives forward secrecy: because the session keys derive from ephemeral values discarded after the handshake, an attacker who later obtains the long-term private key cannot decrypt recorded past sessions. Resuming purely from a pre-shared key (PSK), without an ephemeral exchange, forfeits that property.

Zero round-trip time (0-RTT) early data is a separate feature that lets a client send application data with its first message on a resumed connection, saving a round trip. It has no inherent replay protection, so an attacker who captures early data can send it again. The design rule is narrow: permit early data only for operations deemed safe to replay, and handle possible duplicates at the application layer. Forward secrecy does not fix this, because the two properties address different problems.

The third state is the one most designs leave unaddressed. Data at rest is encrypted and data in transit is encrypted, and in between the application decrypts everything into memory to work with it, where the operating system, the hypervisor, a privileged administrator, and anything that can read process memory all sit closer to the plaintext than the attacker the storage encryption was defending against.

What the mechanism provides

A trusted execution environment (TEE), also described as a secure enclave, is a hardware-isolated region in which code and data are protected while they are being processed. Memory belonging to the environment is isolated from other software on the platform, including more privileged layers, so a compromised operating system or hypervisor does not automatically yield the plaintext inside it. Both Azure confidential computing^[16] and Google Cloud confidential computing document the platform forms of this.

Attestation is the companion mechanism and the reason the isolation is useful to a remote party. Attestation is a signed statement about what is actually running inside the environment, produced by the hardware and verifiable by someone outside the platform. It lets a key holder decide whether to release a key to a particular workload rather than trusting the platform operator's word, and that decision is the point at which in-use protection becomes an architectural control instead of a platform feature.

What it does not provide

The boundaries here follow the same shape as the module boundary discussed earlier, and stating them prevents an inflated claim from reaching a design document. A TEE protects data from other software on the platform; it does not protect data from defective or malicious code running inside the environment, because that code is on the trusted side. It depends on a hardware root of trust and on the vendor's attestation infrastructure, which are trust dependencies the design acquires. It reduces but does not eliminate exposure through side channels, which is exactly the implementation-attack class covered earlier. And the key-release policy that decides which attested workloads receive which keys is the architect's design, not something the hardware supplies.

The practical selection rule is narrow. Reach for in-use protection when the threat model includes the platform operator or a compromise of the layers beneath the workload, when regulation requires that a processor cannot read the data it processes, or when several parties need to compute over combined data none of them may see whole. For a workload where the platform is already inside the trust boundary, the same effort spent on access control and key management usually removes more risk.

Decision 4 starts where the key does. A 256-bit key derived from predictable input carries nowhere near 256 bits of security, and its nominal length says nothing about it, so generation is a security decision rather than a formality.

Generation

Approved key generation uses a random bit generator with sufficient entropy for the strength the key is meant to provide, where entropy means genuine unpredictability from the attacker's point of view rather than apparent disorder. NIST SP 800-90A^[17] specifies the approved deterministic random bit generators and NIST SP 800-133^[18] covers how keys are generated from them. Two practical checks follow. Use the platform's cryptographic generator rather than a general-purpose one, since the general-purpose function in most standard libraries is not designed to resist prediction. And treat freshly provisioned systems, virtual machine clones, and embedded devices as entropy risks, because a pool that has not been seeded with genuine unpredictability produces repeatable output.

Establishment: two different mechanisms

Automated establishment of a shared symmetric key uses key transport, key agreement, or a combination of those two mechanisms, and the distinction between them is a favorite exam target because the outcomes look identical from outside.

In key agreement, both parties contribute input and each derives the same shared secret from the combination. Neither party chooses the resulting key alone, and the secret itself is never transmitted. Diffie-Hellman and its elliptic-curve form are the standard schemes, specified in NIST SP 800-56A^[19].

In key transport, one party selects or generates the keying material and protects it for delivery to the other, typically by encrypting it under the recipient's public key. The recipient contributes nothing to the value of the key. NIST SP 800-56B^[20] specifies the schemes based on integer factorization.

The figure below places the two side by side.

Why agreement needs authentication

Bare Diffie-Hellman authenticates nobody. An attacker positioned between the parties can complete a separate exchange with each, ending up with one shared secret per side and reading everything that flows between them, while both parties see a successful key establishment. The protection has to come from the surrounding protocol: signing the exchange with a key whose ownership is already established, binding it to certificates, or authenticating it with a previously shared secret. This is the specific reason the transit section insists on peer authentication, and it is worth carrying as one rule rather than two facts.

The design takeaway is that key establishment is chosen for its trust properties, not its speed. Agreement suits parties that both need assurance the key was not dictated to them and gives forward secrecy when the contributions are ephemeral; transport suits cases where one party legitimately owns the key and the other only needs to receive it safely.

A key in transit between the place it was generated and the place it will be used needs two different protections at once, and treating them as one is a common design gap. Secret and private keying material needs confidentiality so that nobody in the path learns it. Every key association, including public keys, needs integrity and an authentic binding to the intended party and purpose, so that nobody in the path substitutes a different key. A confidential channel to an unauthenticated recipient delivers the key perfectly securely to the wrong party, and an authenticated channel with no confidentiality delivers the right party's key to everyone watching.

Storage and the hardware boundary

Where keys live decides how much of the design has to be trusted. A hardware security module (HSM) is a dedicated cryptographic module that generates, stores, and uses keys inside a tamper-resistant boundary, exposing only a narrow interface: callers ask the module to perform an operation and the key itself never leaves. That property is what makes an HSM worth its cost for a certification authority's signing key, a root key-encryption key, or a payment key.

One limitation belongs at the first mention rather than in a later list. An HSM protects the key; key protection alone does not decide whether the caller should be allowed to use it. If any application that can reach the module can request any operation, the key is safe from extraction and freely usable by anything on the network. Authorization of callers, separation of the keys each caller may use, and logging of operations are all part of the surrounding design, and NIST SP 800-57 Part 2^[21] covers the organizational half of key management that sits around the device.

The same reasoning applies to a managed key service, which is an HSM-backed service with a policy layer in front of it. The policy layer is the part that answers the authorization question, and it is configured rather than inherited.

Separation by purpose

Keys are separated by cryptographic purpose: signing, encryption, authentication, and key establishment each get their own key or key pair unless an approved scheme explicitly allows a combination. Three reasons make this a rule rather than tidiness.

Using one key for two purposes can create cross-protocol attacks, where a message from one context is presented in the other and the mathematics does not distinguish them. It also forces a single lifecycle onto operations with different needs: an encryption key may need to be archived for years so old data stays recoverable, while a signing key should be destroyed at end of life so no new signatures can be created, and one key cannot satisfy both. And it widens the blast radius, since a compromise of the key compromises every purpose at once.

Certificates carry this separation explicitly through key-usage extensions, which state what the certified public key may be used for. Honoring those extensions during validation is part of the certificate handling covered next.

The OWASP key management guidance^[22] collects the implementation habits that follow from this section, and the design decisions above should be settled before any of them are chosen.

A certificate is a signed statement that binds a public key to a named subject, issued under a stated policy by a certification authority (CA). Everything a relying party gets from it depends on that binding still holding, and the relying party is whoever is deciding whether to trust the key: the browser, the service verifying a signature, or the device authenticating a peer.

What validation actually checks

A certificate is not usable because it parsed. Validation is a sequence of checks, and any one of them failing means the binding cannot be relied on:

1. The certification path builds to a trusted root. Each certificate in the chain is issued by the next one up, ending at a root the relying party already trusts. The trust store holding those roots is a control surface in its own right, because anything added to it can vouch for any name.
2. The signatures verify at each link. Each issuer's signature over the certificate below it checks out against the issuer's public key.
3. The validity dates cover the moment of use. Certificates carry a not-before and not-after time, and expiry is a hard stop.
4. The key usage matches the purpose. The key-usage and extended-key-usage extensions state what the key may do, and a certificate issued for one purpose does not authorize another. The name in the certificate must also match the identity being relied on.
5. Revocation status is checked. The issuer may have withdrawn the binding before its expiry, and a relying party that never checks will keep trusting it.

The figure below traces those checks in order.

One boundary belongs here: a certificate is a public document that says nothing about the state of the subject's private key. It cannot protect that key, and it cannot detect that the key was copied. The binding stays valid until someone with authority withdraws it.

What revocation does and does not do

Revocation stops future reliance on the binding. When a private key is compromised, or the subject is no longer entitled to the identity, the issuer publishes the revocation and relying parties that check will stop accepting the certificate.

What revocation does not do is the part worth writing down, because scenario questions are built on it. It does not recover or neutralize the compromised private key, which remains in the attacker's hands. It does not decrypt or protect ciphertext the attacker already captured, and where the key was used for key transport without forward secrecy, past sessions stay exposed. It does not automatically invalidate signatures produced before the revocation, since a signature made while the certificate was valid may still be honored depending on the trust policy and on whether trustworthy timestamps exist. And it has no effect on relying parties that do not check status, which makes revocation checking, its latency, and the behavior on a failed check into real design decisions rather than defaults to accept.

The takeaway is that revocation is a forward-looking control. Everything that happened while the compromised key was trusted is handled by the compromise response covered later on this page, not by publishing a revocation.

A cryptoperiod is the span of time during which a key is authorized for use, and it is set per key rather than per organization. NIST SP 800-57 Part 1^[1] sets out the inputs: the strength of the algorithm and key, the type of key and what it protects, the volume of data processed under it, how exposed it is, the operating environment, and the consequences if it were compromised.

Why one interval for everything is wrong

The inputs above pull in different directions for different keys, which is why a single organizational rotation interval satisfies none of them well. A session key used for minutes and a root key-encryption key held in an HSM for years are both correctly configured. A key encrypting high-volume data may need replacing on volume rather than on time, because the amount of material processed under one key is itself a limit. A key held on a device an attacker can physically reach needs a shorter period than one inside a monitored facility. And a key whose compromise would expose a decade of archived records justifies more caution than one protecting a cache rebuilt hourly.

Rotation, meaning the planned replacement of a key at the end of its cryptoperiod, is therefore a scheduled risk control. It limits how much material any single key protects and how long a quiet compromise could go on producing value for an attacker.

A known or suspected compromise is a different situation, handled by the response procedure in the next section rather than by waiting for the interval to elapse.

When a key is known or suspected to be compromised, waiting for its cryptoperiod to expire leaves a key the attacker holds in active service. The response is its own sequence, and the order matters because each step limits what the next has to clean up:

1. Stop using the key, so no new data is protected under material the attacker holds.
2. Revoke or distrust the affected credentials and certificates, and publish that status so relying parties act on it.
3. Generate replacement keys, following the generation requirements covered earlier rather than reusing anything derived from the compromised material.
4. Distribute the new keys and the new trust anchors to every party that needs them, which is where an incomplete key inventory turns an incident into an outage.
5. Assess what was exposed while the key was trusted, including data encrypted under it, signatures produced with it, and sessions that can be decrypted from recordings.
6. Re-protect the affected information where it still requires protection, which may mean re-encrypting stored data under new keys.

The figure below traces the sequence, with those last two steps marked.

Steps 5 and 6 address consequences of the compromise. Revocation stops future reliance, as the certificate section set out; the exposure that already happened is addressed here or not at all.

One planning consequence deserves stating: every step above depends on knowing where the key was used. The inventory discussed in the transition section is what makes this procedure executable rather than aspirational.

Availability of keys is a security requirement in its own right, because a key that cannot be produced when needed has made the data it protects permanently unreadable. Backup and archive mechanisms that provide that availability create additional copies of key material, so each one is a deliberate trade rather than a default.

Recovery differs by key purpose

Archiving or escrowing a decryption key is appropriate when the organization must be able to recover protected data without the original key holder: an employee leaves, a device fails, a legal hold requires production, or an operational key is lost. The data exists, the business needs it, and only the key stands between them.

A private signature key is the opposite case. Anyone holding it can produce signatures attributable to the subscriber, so a recovery copy hands a second party the ability to act as that subscriber and destroys the accountability the signature was supposed to provide. When a signing key is lost, the correct answer is to revoke the certificate and issue a new key pair, not to recover the old key. The general rule to carry: recovery mechanisms belong to keys that decrypt, not to keys that assert identity.

This is one of the clearest cases of why keys are separated by purpose. A single key pair used for both signing and encryption forces the organization to choose between recoverable data and accountable signatures, and neither answer is acceptable.

Backup copies are copies

Where key backups exist, three requirements travel with them. Protect the backup at least as strongly as the operational copy, because an attacker will take whichever is easier and the protection of the data is set by the weakest copy of its key. Control restoration, so returning a key to service is an authorized, logged operation rather than a file copy. And inventory the locations, since a copy nobody tracks cannot be protected, rotated, or destroyed.

That last point is where the trade becomes concrete: every additional copy improves the odds of recovering data and enlarges the set of targets whose compromise exposes it.

Cryptographic erasure

Cryptographic erasure, also called crypto erase, renders encrypted data inaccessible by destroying the keys rather than overwriting the storage. NIST SP 800-88^[23] treats it as a sanitization technique with explicit preconditions, and it is attractive at scale because destroying one key can retire an entire storage volume or an entire tenant's data in one operation.

The preconditions are what make or break the claim. Strong encryption must have covered the target data from the start, since data written before encryption was enabled is untouched by destroying the key. Every usable copy of the relevant key must be destroyed, including backups, escrow copies, and any copy held by a service provider, which is where the backup inventory above becomes load-bearing. And no plaintext copies may survive elsewhere, in caches, exports, logs, or downstream systems.

A surviving key backup does not weaken the sanitization claim, it voids it. That is the sentence to carry into a scenario question where crypto erase is offered as the answer and the environment holds an escrowed copy of the key.

Two controls constrain what people can do with high-value keys, they are routinely confused with each other, and the difference is worth stating in one line before anything else: split knowledge is about who possesses the secret, dual control is about who can perform the action.

Split knowledge

Split knowledge divides key material, or the activation data that unlocks it, so that no single participant holds the whole value. Each custodian holds a component that is useless alone, and the key exists in complete form only when the required components are brought together, ideally inside a protected module rather than in anyone's hands.

The test that catches the usual mistake: if one administrator knows the full key and a second person merely approves its use, that is not split knowledge. The first administrator can copy the value and use it elsewhere, entirely outside the approval process. Split knowledge fails whenever any single person could write the whole secret down.

Dual control

Dual control, also called dual authorization, requires two authorized people to complete a sensitive operation, so no individual can carry it out alone. The operations it typically covers are the ones with irreversible or high-impact outcomes, including key generation ceremonies, activating a key for production use, recovering an escrowed key, exporting key material, and destroying a key.

Dual control says nothing about who knows the secret. Two operators can jointly authorize an operation on a key that neither of them has ever seen, which is the normal arrangement with a hardware security module, and that is a perfectly sound design.

Using them together

The two combine because they address different failure modes. Split knowledge defeats the custodian who copies a secret and uses it privately later. Dual control defeats the operator who performs an unauthorized action right now, including with a secret they never see. A key ceremony that produces a root key-encryption key typically applies both: components held by separate custodians, and every step of the ceremony performed with two authorized participants and a witnessed record.

For exam scenarios, the discriminating question is which failure the stem describes. A scenario where one administrator could act alone with knowledge they already have points at split knowledge. A scenario where an operation should never be completed by a single person, regardless of what they know, points at dual control. A scenario that describes an approval workflow layered on top of one person's full knowledge of the key describes dual control being mistaken for split knowledge, which is the most common wrong answer of the three.

Every cryptographic choice on this page has a shelf life. Algorithms weaken as analysis advances and computation gets cheaper, standards bodies withdraw parameters, and protected data frequently outlives the protection chosen for it. Planning for that is the fourth constraint from the opening section, and it is executed through an inventory rather than a policy statement.

What the inventory has to contain

A transition is only possible if you can answer "where is this used" without a discovery project. The inventory covers, at minimum, the algorithms and parameters in use, the keys and their purposes and locations, the certificates and their issuers and expiry dates, the protocols and versions deployed, the dependencies that pin any of these choices, including hardware, libraries, third-party services, and partner interfaces, and the lifetime of the data each one protects. That last field is the one most often missing and the one that drives the schedule.

NIST SP 800-131A^[11] is the reference for which algorithms and key lengths are being withdrawn and on what terms, and it is the document a transition plan is usually written against.

Why data lifetime sets the deadline

A system protecting data that stops mattering in thirty days can transition when convenient. A system protecting records that must stay confidential for twenty years is in a different position, because an attacker can capture ciphertext today and store it until an attack becomes practical. The protection has to hold for the life of the data, not for the life of the system, and that reasoning is what drives transition planning ahead of any concrete break.

The current instance of this is the move to post-quantum cryptography. NIST has published standardized post-quantum algorithms, including FIPS 203^[24] for key encapsulation and FIPS 204^[25] for digital signatures, and maintains a broader post-quantum cryptography project covering migration. For an architect the practical implication is that long-lived confidential data is an early migration priority, because the capture-and-store exposure described above, commonly called harvest-now-decrypt-later, applies to it directly.

Designing for the next transition

Cryptographic agility is the design property that makes transitions routine: algorithms, parameters, and key sizes are configuration rather than assumptions scattered through the code, protocol negotiation allows new algorithms to be introduced, and key hierarchies allow a layer to be replaced without rewriting the data beneath it, which is the envelope pattern from earlier doing exactly that job. Agility is not free, since every negotiable option is also an option an attacker may try to force downwards, so the configuration surface needs its own floor on acceptable choices.

The closing point for the whole constraint layer: a design that cannot state which algorithms it depends on cannot be transitioned, and the effort of building that record is paid once, whereas the effort of discovering it during an emergency is paid under time pressure.

ISSAP cryptography questions rarely ask which algorithm is strongest. When a question describes a situation and asks what an architect should select, identify which of the four decisions the situation turns on. Working out that much before reading the options is the fastest route to the right answer.

Mapping the stem to the decision

When the stem emphasizes what must be proven, established, or kept secret, it is testing the service and mechanism decisions. Watch for the words that pick out a single property: "prove to a third party" and "cannot later deny" point at digital signatures, "detect any modification" between parties that already share a key points at a MAC, "unreadable" points at encryption, and a stem naming both confidentiality and modification detection points at authenticated encryption rather than encryption alone.

When the stem describes where the data is or who is in the path, it is testing the state decision. A cloud provider, a managed service, or an inspecting intermediary that must not read content is asking for end-to-end protection. Stolen media, disposed drives, or exported snapshots are asking for at-rest encryption. A platform operator or a hypervisor in the threat model is asking for in-use protection. A stem that says data is encrypted at rest and still reaches an attacker is usually pointing out that a compromised authorized process was the path.

When the stem describes people, timelines, or recovery, it is testing the key lifecycle. Custody by multiple staff, ceremony procedures, escrow, rotation intervals, and what to do after a compromise all live here.

Distractor patterns worth recognizing

The wrong options tend to come from a small set of moves, each corresponding to a boundary this page has drawn:

• Right family, wrong property. Offering a hash where the requirement needs confidentiality, or a MAC where the requirement needs verification by an outside party.
• Assurance treated as coverage. Offering a validated module, or a higher FIPS 140-3 level, as the answer to a key-management or protocol failure that sits outside the module boundary.
• A control that acts on the wrong tense. Offering revocation as the fix for ciphertext already captured, or scheduled rotation as the response to a known compromise.
• Storage encryption against a live adversary. Offering encryption at rest where the described attacker already holds valid credentials on a running system.
• The stronger-sounding option. Offering the longer key, the higher assurance level, or the newer algorithm where the stem's constraint was computational capability, data lifetime, or an unauthenticated peer.
• Dual control labeled as split knowledge. Offering an approval workflow over a secret one administrator fully knows.

The habit to build

Read the stem for the requirement, name the service, then check what the offered mechanism leaves unsupplied. Most incorrect options on this exam are technically accurate statements about a mechanism that answers a question the stem did not ask, which is the same failure mode this page opened with: an algorithm chosen before the requirement was translated.