CompTIA Security+ SY0-701: PKI, Certificates, and Cryptography

Cryptography on Security+ is not a contest to memorize the largest number of algorithms. The current SY0-701 objectives expect candidates to understand why organizations use encryption, hashing, digital signatures, certificates, public key infrastructure, key-management systems, secure hardware, tokenization, masking, and other data-protection techniques. The exam tends to reward functional understanding: which security property is required, where the data exists, and which cryptographic mechanism supplies that property.

A useful starting point is to separate confidentiality, integrity, authentication, and non-repudiation. Encryption primarily protects confidentiality. Hashing helps verify integrity. Digital signatures combine asymmetric cryptography and hashing to support integrity, origin authentication, and non-repudiation. Certificates bind identities to public keys through a trust model. Once those relationships are clear, many cryptography questions become less about terminology and more about matching a mechanism to a need.

Symmetric and asymmetric encryption solve different problems

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient and well suited to protecting large amounts of data, but the parties need a safe way to share and protect the key. Asymmetric encryption uses a mathematically related public and private key pair. The public key can be distributed widely, while the private key must remain protected.

The practical difference is explored in more depth in symmetric and asymmetric encryption. Real systems often combine both approaches: asymmetric methods help establish trust or exchange keying material, then symmetric encryption protects the bulk session because it is more efficient.

On exam questions, do not automatically choose asymmetric encryption because it sounds more advanced. If a storage system needs fast encryption of a large volume, symmetric encryption is usually more appropriate. If two parties need to establish secure communication without a previously shared secret, asymmetric techniques become more useful.

Encryption level should match where data is exposed

SY0-701 distinguishes several places where encryption can be applied: full disk, partition, file, volume, database, record, and transport. Each protects a different boundary. Full-disk encryption is valuable when a device is lost, but it may not protect data from a user or process that already has access after the disk is unlocked. Field- or record-level protection can restrict specific sensitive values inside a database.

Transport encryption protects data moving between systems. This matters because data can be secure at rest but exposed while crossing a network. Conversely, encrypting the network connection does not protect data after it reaches an unauthorized destination with legitimate credentials.

The strongest scenario answer is the control positioned at the actual exposure point. Ask whether the risk is stolen media, intercepted communication, unauthorized database access, or disclosure of a specific sensitive field.

Hashing provides integrity, not secrecy

A cryptographic hash produces a fixed-size digest from input data. If the input changes, the digest should change in a way that makes tampering detectable. Hashing is therefore useful for integrity checks, password storage constructions, file verification, and parts of digital-signature workflows.

Hashing does not encrypt data and cannot normally be reversed to recover the original message. That makes “hash the file so nobody can read it” a category error. If confidentiality is required, use encryption. If the requirement is to detect modification, hashing may be appropriate.

Salting adds unique random data before password hashing so that identical passwords do not produce identical stored values. Key stretching deliberately makes password derivation more computationally expensive, increasing the cost of large offline guessing attacks. These techniques strengthen password storage but do not eliminate the need for strong authentication and account controls.

Digital signatures prove more than a hash alone

A simple hash can show that two copies of data match, but it does not prove who created the original hash. A digital signature adds identity and trust by using the signer’s private key. A verifier can use the corresponding public key to validate that the signed data has not changed and that the signature was created with the expected private key.

This supports software signing, document signing, secure email, and certificate operations. It is also why private-key protection is so important. If an attacker obtains the private signing key, they may be able to create content that appears legitimate.

Non-repudiation depends on this control environment as well as the mathematics. If multiple people share a private key, the organization weakens its ability to attribute a signature to one individual.

PKI turns public keys into a scalable trust system

Public key infrastructure solves a central problem: how does a user know that a public key really belongs to the claimed organization or service? A certificate authority issues and signs certificates that bind identity information to a public key. Trust ultimately traces back to a trusted root.

A certificate signing request contains information needed to request a certificate and is associated with the requester’s key pair. After validation, the CA issues a certificate. Clients can then validate the certificate chain, name, validity period, signature, and revocation status.

PKI is not the encryption algorithm itself. It is the governance, technology, and trust structure that manages certificates and keys at scale. That includes issuance, renewal, revocation, storage, policy, and auditing.

Revocation prevents trust from lasting after compromise

Certificates can become unsafe before their scheduled expiration. A private key may be compromised, an employee may leave, a server name may change, or the certificate may have been issued incorrectly. Revocation mechanisms allow systems to determine that a certificate should no longer be trusted.

Certificate revocation lists contain revoked certificate identifiers, while the Online Certificate Status Protocol can provide status information more dynamically. Each approach has operational trade-offs involving freshness, availability, and privacy. The exam primarily expects you to recognize why revocation is necessary and how these mechanisms differ conceptually.

Expiration and revocation are not the same thing. Expiration is planned end-of-life. Revocation is an early withdrawal of trust.

Hardware can strengthen key protection

Trusted Platform Modules, hardware security modules, secure enclaves, and key-management systems all help protect cryptographic material, but they serve different roles. A TPM is commonly associated with device-based key protection and platform trust. An HSM is a dedicated cryptographic device designed to generate, store, and use keys securely. A key-management system coordinates key lifecycle and policy across services.

The exam may describe a requirement such as preventing private signing keys from being exported from secure hardware. That points toward an HSM-style control rather than ordinary file encryption. If the requirement is device-bound disk-unlock material, a TPM may be more relevant.

Key escrow is another lifecycle concept. An organization may need a controlled way to recover encrypted data when normal access is lost. Escrow creates recovery capability but also becomes a high-value security target, so access and auditing must be tightly controlled.

Obfuscation and tokenization are not interchangeable with encryption

Security+ includes tokenization, masking, obfuscation, and steganography because organizations sometimes need to reduce data exposure without traditional encryption. Tokenization replaces a sensitive value with a surrogate token while the mapping is protected elsewhere. Masking hides part or all of a value for display or testing. Obfuscation makes data or code harder to interpret but does not necessarily provide cryptographic confidentiality.

Steganography hides the existence of information by embedding it in another medium. It should not be confused with encryption, which makes the contents unreadable while leaving the presence of the ciphertext obvious.

These distinctions matter in scenario questions. If an application needs realistic test data without exposing real account numbers, masking or tokenization may fit better than simply encrypting the entire database.

Wireless cryptography shows why standards age

Cryptographic controls have operational lifecycles. Older algorithms and protocols eventually become unsuitable as weaknesses are discovered or computing power improves. The history of wireless encryption standards illustrates this clearly: organizations must migrate away from obsolete protections rather than assume that “encrypted” automatically means secure.

The same principle applies to certificates, key sizes, hashing algorithms, and protocol versions. Security architecture should support replacement and rotation. Hard-coding an obsolete cryptographic choice into a system can create long-term technical debt.

Questions that compare legacy and modern options usually reward the supported, secure standard that meets the stated compatibility requirement.

Use property-first reasoning for cryptography questions

When a cryptography scenario appears, identify the security property before selecting the technology. Confidentiality points toward encryption. Integrity points toward hashing or signatures. Proof of origin and non-repudiation point toward signatures and trustworthy private-key control. Identity-to-key binding points toward certificates and PKI. Secure storage of keys points toward a key-management or hardware-protection solution.

Then identify the data state: at rest, in transit, or in use. Finally consider lifecycle: generation, storage, rotation, revocation, escrow, and destruction. This approach is far more reliable than trying to remember isolated acronyms.

Security+ uses cryptography as a foundation for many other domains, from secure network tunnels to identity federation and signed software. Candidates who understand why the mechanism works can transfer that reasoning across scenarios instead of memorizing one answer per technology.

For broader CompTIA context, CompTIA certifications show how Security+ fits between foundational IT knowledge and more specialized security credentials. Cryptographic fundamentals remain relevant across that entire progression. Certificate renewal paths also require rehearsal, since an expired intermediate or missing trust-chain certificate can resemble a general service outage.