Choose Cryptography by the Security Property You Need
Cryptography becomes confusing when it is learned as a list of algorithms. It becomes easier when the design starts with the property a system needs: confidentiality, integrity, authenticity, nonrepudiation, secure key establishment, or protection of stored credentials. The mechanism follows from the requirement.
The current CISSP outline reflects this design approach. Security Architecture and Engineering includes selecting cryptographic solutions, managing the cryptographic lifecycle, understanding symmetric and asymmetric methods, public key infrastructure, and attacks against cryptographic systems. The exam is broad because real cryptography failures often happen around key handling, protocol use, and trust decisions rather than in the mathematics itself.
For professionals studying CISSP, the most useful habit is to ask what must be protected from whom, for how long, and who is allowed to verify or decrypt it. Those questions eliminate many wrong choices before an algorithm is ever discussed.
Confidentiality means preventing unauthorized disclosure
Encryption is the primary tool for confidentiality. Symmetric encryption uses the same secret key for encryption and decryption and is efficient for protecting large amounts of data. Asymmetric cryptography uses a public/private key pair and is useful for key exchange, digital signatures, and situations where parties should not share one secret in advance.
Many real systems combine both. A protocol can use asymmetric mechanisms to authenticate parties or establish a shared secret and then use symmetric encryption for the data session. Understanding this pattern is more useful than treating symmetric and asymmetric cryptography as competing technologies.
Confidentiality requirements also have a time horizon. Some data loses sensitivity quickly, while legal records, trade secrets, medical information, or strategic data may need protection for many years. The expected lifetime of the secret can influence key size, algorithm choice, archive design, and how urgently an organization prepares for future cryptographic transitions.
Integrity means detecting unauthorized change
Encryption alone does not necessarily prove that data has not been altered. Integrity mechanisms allow a receiver to detect modification. Cryptographic hash functions produce a fixed-length digest from input data, while message authentication codes combine integrity with a shared secret so that only parties holding the secret can create a valid authenticator.
Digital signatures can also provide integrity because a change to the signed content causes verification to fail. The architecture should choose the mechanism according to who needs to verify the result. A shared-secret MAC works differently from a signature that can be verified with a public key.
Authenticity answers who created or presented something
Authentication in cryptographic systems can apply to people, services, devices, or software artifacts. Certificates can bind public keys to identities through a public key infrastructure. Signed software can allow a platform to verify the publisher and detect modification. Mutual TLS can authenticate both sides of a connection rather than only the server.
Authenticity is only as strong as the trust chain behind it. If certificate issuance, key storage, identity proofing, or signature verification is weak, a strong algorithm does not repair the process. Cryptography therefore depends on governance and operations around keys and identities.
Authentication systems should also distinguish the identity of the endpoint from authorization to perform a particular action. A valid certificate can prove that a service holds an expected private key without proving that every request from that service should be accepted. Cryptographic identity must still feed into an authorization policy.
Nonrepudiation requires stronger evidence than simple access control
Nonrepudiation is concerned with preventing a party from plausibly denying an action when reliable proof is required. Digital signatures can contribute because the signature is created with a private key associated with the signer, but the broader system must also protect that key and establish who controlled it at the time.
If many users share a private key or privileged account, the evidence becomes weak. Timestamps, protected audit records, identity proofing, and key-management procedures may all contribute to the evidentiary value. Security properties should be evaluated end to end, not inferred from one cryptographic function.
Key management is usually harder than choosing an algorithm
Keys must be generated with sufficient randomness, stored securely, distributed to the right entities, rotated when necessary, backed up where recovery requires it, revoked when compromised, and destroyed when no longer needed. A design that says “encrypt the database” but does not define who can access the key has not solved the confidentiality problem.
Key separation also matters. Using the same key for unrelated purposes can increase impact if it is compromised and can violate protocol assumptions. Environments should distinguish data-encryption keys, key-encryption keys, signing keys, certificate private keys, and other specialized secrets according to their role.
Password storage has a different requirement from data encryption. A service normally needs to verify that a submitted password matches the registered secret; it does not need to decrypt the original password. That makes one-way password hashing with a purpose-built, salted, computationally expensive password hashing function preferable to reversible encryption.
Salts prevent identical passwords from producing identical stored values and make precomputed attacks less useful. Work factors slow guessing. The exact implementation should follow current platform guidance, but the architectural lesson is stable: choose a primitive that matches the operation the system actually needs.
Key access should also be separated from data access where practical. If the same administrator can read sensitive data, change encryption policy, and export the protecting keys without independent oversight, encryption provides less organizational protection than the design may imply. Separation of duties, hardware-backed key protection, and detailed key-use logging can strengthen the control.
Public key infrastructure is a trust system, not just a certificate file
PKI includes certificate authorities, registration or validation processes, certificate issuance, renewal, revocation, trust stores, and policies for how identities are represented. A certificate can establish that a public key is bound to a named subject according to the issuer’s process; it does not prove every claim an application might want to make about that subject.
Architects should know which certificate authorities are trusted, how revocation or expiration is handled, how private keys are protected, and whether automated renewal can occur safely. Outages caused by expired certificates demonstrate that cryptography is an operational lifecycle as much as a design decision.
Secure protocols combine encryption, integrity, identity, replay protection, negotiation, and key management. Implementing one algorithm correctly does not guarantee the protocol is safe. This is why organizations should prefer mature, reviewed protocols and libraries rather than designing proprietary cryptographic schemes.
TLS is a common example: the security outcome depends on protocol versions, cipher negotiation, certificate validation, key exchange, endpoint configuration, and how applications respond to failures. A network may be “encrypted” and still be vulnerable if clients accept invalid certificates or terminate TLS at an unexpected trust boundary.
Certificate revocation and compromise response deserve operational practice. Teams should know how quickly they can replace a compromised signing or TLS key, where trust stores must be updated, and which clients may cache old state. A certificate lifecycle that works only during routine renewal may fail when emergency replacement is required.
Crypto agility matters because algorithms and requirements change
Cryptographic systems can remain in service for many years, while algorithm guidance, key sizes, regulatory requirements, and attack capabilities change. Crypto agility means being able to inventory cryptographic use, replace algorithms or certificates, rotate keys, and update protocols without redesigning the entire product.
The CISSP outline now explicitly references quantum considerations in cryptographic methods. That does not mean every organization should immediately replace all current cryptography. It does mean long-lived systems and long-lived confidential data need a migration strategy that can adapt as standards and practical capabilities evolve.
Cryptography belongs inside a larger security architecture
The PrepAway CISSP Domain 3: Security Architecture and Engineering places cryptography alongside secure design principles, system architecture, and resilience because encryption cannot compensate for unlimited privilege, weak endpoint security, or poor software design. Keys eventually need to be used somewhere, and that point of use must be protected.
Cloud security makes the same point. A deeper look at encryption and security operations on AWS shows how cryptographic controls interact with identity, automation, monitoring, and incident response. The correct question is therefore not “which cipher is strongest?” but “which security property is required, where is the trust boundary, and how will the key and protocol be operated throughout the system’s life?”
Inventory is the prerequisite for crypto agility. Organizations cannot migrate away from an algorithm or certificate authority if they do not know where it is used. Discovery should cover application code, network devices, embedded systems, signing pipelines, secrets platforms, third-party integrations, and long-lived archives whose confidentiality requirements may outlast today’s algorithms.
The requirement should select the mechanism
The CISSP certification expects candidates to connect cryptographic technologies to security objectives. Confidentiality points toward encryption. Integrity may require hashes, MACs, or signatures. Authenticity may rely on certificates or signed assertions. Password verification requires a one-way design. Nonrepudiation needs evidence that survives beyond ordinary access control.
Starting with the property prevents cryptography from becoming a vocabulary test. It turns the problem into architecture: define the threat, define the required assurance, choose a proven mechanism, manage its keys and trust anchors, and keep the implementation replaceable as the environment changes.
The same reasoning prevents overuse. Not every value needs encryption, and encryption can create recovery, search, performance, and key-management costs. The security property and threat model should justify the control so cryptography is applied where it changes risk rather than where it merely sounds secure.