Encryption in Cybersecurity: Concepts and Purpose

This training explains encryption concepts, its cybersecurity purpose, and practical examples, helping professionals and learners understand how encryption protects data.

A digital instructor presents all 15 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

30 minFree to watchDownloads

What you’ll learn

01Encryption Cybersecurity: Concepts, Purpose, and ExamplesWelcome. I am glad you are here. This course introduces encryption as it is used in cybersecurity. The goal is simple. You will learn what encryption is, why it matters, and how it protects data in everyday work. We will look at real systems and daily workflows, such as protecting stored files, securing web traffic, and handling credentials. This course is for IT staff, security beginners, developers, managers, and educators. No math proofs are required. We focus on concepts and decisions. We will use three anchors. Core concepts, strategic purpose, and practical examples. One important note. Encryption is one data protection control. It is not all of cybersecurity. Our path is straightforward. First, vocabulary. Then hands-on examples. Finally, a crypto-agility roadmap. Let us begin with the background, and ask why encryption is a baseline control.niccs.cisa.gov university.owaspblt.org nist.gov+22 min
02Background: Why Encryption Is a Baseline ControlLet's step back and look at why encryption is treated as a baseline control. First, encryption is not the same as hashing, encoding, or tokenization. Each solves a different problem. Encryption protects confidentiality. Hashing gives you a fixed digest. Encoding just changes representation, with no secret. And tokenization replaces sensitive values with substitutes. Next, confidentiality comes first, but integrity matters too. Authenticated encryption tags, and digital signatures, let you detect tampering. Now, consider compliance. Frameworks require encryption appropriate to the risk. No single cipher is mandated. You will see GDPR Article Thirty-Two, ISO Twenty-Seven Thousand and One control A dot eight point twenty-four, SOC Two CC six point one and CC six point seven, HIPAA, and PCI DSS Requirements Three and Four. Here is the key takeaway. Encrypted is a system property, not a checkbox. Key management decides whether encryption actually protects your data. If keys sit next to the data, or are shared carelessly, the protection fails, and legal safe harbors can disappear. So ask where your keys live, who controls them, and how they rotate. That is the real baseline. Let's move on to the core concepts: keys, ciphers, and modes.legalclarity.org compliancedocshq.com legalclarity.org+22 min
03Core Concepts: Keys, Ciphers, and ModesLet us build the vocabulary we will use throughout this course. Plaintext is your original data. Ciphertext is that data after encryption. A key is the secret value that controls the transformation. An algorithm is the defined procedure, and a cipher suite is a named bundle of algorithms used together, common in protocols like TLS. Encryption comes in two broad forms. Symmetric encryption uses one shared key, and AES with 128, 192, or 256-bit keys is the accepted standard. Asymmetric encryption uses a public and private key pair. RSA keys should be at least 2048 bits, and ECDSA commonly uses curves P-256 or P-384. Hashing is different. SHA-2, SHA-3, and password hashing like Argon2id are one-way. They verify data. They do not encrypt it. Remember that distinction when you store credentials. Ciphers are also grouped as block or stream, and the mode of operation changes security. GCM, CCM, and XTS-AES are accepted. ECB is retired as a confidentiality mode, CBC is conditional, and FF3 is disallowed. One last point. Key strength depends on generation randomness, nonces, and initialization vectors, not the algorithm name alone. A strong algorithm with a weak key still fails. Next, we will look at why encryption matters in practice, in the slide Purpose: Confidentiality, Compliance, and Business Value.csrc.nist.gov csrc.nist.gov nvlpubs.nist.gov+22 min
04Purpose: Confidentiality, Compliance, and Business ValueLet's look at why encryption matters in practice. Its core purpose is confidentiality. It protects data at rest, like files on a laptop or database. It protects data in transit, like traffic between a browser and a server. And with authenticated encryption, it also adds integrity, so you can detect tampering. Regulators rarely name a specific cipher. They expect encryption that is appropriate to the risk, and that you can justify. This matters because safe harbors exist. Under HIPAA and GDPR, properly encrypted data with protected keys can reduce breach notification duties. But be realistic. Encryption does not stop endpoint compromise, misconfiguration, or exposed keys. The keys are part of the control. Finally, the business case is measurable. IBM's 2025 report put the global average breach cost at four point four four million dollars, and encryption was associated with roughly two hundred eight thousand dollars in mitigation. Next, we move to encryption in transit, and modern protocol hygiene.legalclarity.org compliancedocshq.com legalclarity.org+21 min
05Encryption in Transit: TLS 1.3 and Modern Protocol HygieneLet's look at encryption in transit, and how TLS protects data moving across a network. Transport Layer Security provides three things: confidentiality, integrity, and server authentication. Mutual TLS goes further and also authenticates the client. Configure your servers to default to TLS 1.3. Allow TLS 1.2 only when you need compatibility, and then only with AEAD cipher suites and ECDHE forward secrecy. Disable TLS 1.0 and 1.1, SSL version two and three, and weak options like RC4, 3DES, NULL, and anonymous suites. RFC 9852 states that new protocols must require TLS 1.3. TLS 1.2 is now in feature freeze. For certificates, use SHA-256 signatures and at least 2048-bit RSA keys. Enable HSTS and OCSP stapling. Finally, disable 0-RTT unless your application explicitly handles replay risk. Next, we'll move to encryption at rest, covering disks, databases, object storage, and backups.cheatsheetseries.owasp.org rfc-editor.org rfc-editor.org+21 min
06Encryption at Rest: Disk, Database, Object Storage, and BackupsNow let's focus on encryption at rest, meaning data stored on disks, in databases, in object storage, and in backups. Start with endpoints. Full-disk encryption tools like BitLocker, FileVault, and LUKS protect laptops, mobiles, and backup drives. If a device is lost, the data stays unreadable, but only when the device is powered off and locked. For databases, you often get transparent data encryption at the storage layer. That protects the files on disk, yet the database engine still sees plaintext. So for sensitive columns, such as national identifiers or card numbers, add field-level encryption. In cloud storage, server-side encryption is usually on by default. Customer-managed keys, sometimes called CMEK or BYOK, add control over rotation and access when you need it. Most of this relies on envelope encryption. Each object gets a unique data key, and that data key is wrapped by a key encryption key held in a key management service or hardware security module. One operational reality to respect: if that wrapping key is disabled or destroyed, the data and backups it protects may become permanently unreadable. So treat key lifecycle as carefully as the data itself. Next, we move on to encryption in use and key management systems.docs.aws.amazon.com legalclarity.org compliancedocshq.com+22 min
07Encryption in Use and Key Management SystemsLet's look at where encryption gets difficult. Protecting stored files and network traffic is well understood. Data in use is harder, because at that moment the data must be in memory in readable form. Confidential computing addresses this by isolating data inside protected enclaves. Homomorphic encryption goes further, allowing computation on data while it stays encrypted, though the performance cost today is significant. Then there is key management. Every key has a lifecycle. Generation, distribution, storage, rotation, revocation, archival, and destruction. If any stage is weak, the encryption is weakened too. A common pattern is envelope encryption. A data encryption key encrypts the data. A key encryption key wraps that data key, and the key encryption key stays inside a key management system or hardware security module. When you choose where keys live, start from your threat model. A hardware security module gives strong physical and logical protection. A trusted platform module is bound to one machine. A software keystore is convenient but easier to attack. Finally, protect the keys themselves. Separate duties so no single person controls everything. Use dual control for sensitive operations. Keep immutable audit logs of every key action. Next, we will walk through a practical example, securing a web application end to end.csrc.nist.gov csrc.nist.gov nvlpubs.nist.gov+22 min
08Practical Example: Securing a Web Application End to EndNow let's walk through one web application, end to end, to see how these pieces fit together. For login and checkout, use HTTPS with TLS 1.3, mark cookies Secure, and enable HSTS. Next, passwords. Hash them, never encrypt them. Encryption is reversible, and passwords should not be. OWASP recommends Argon2id at nineteen mebibytes of memory, two iterations, and one degree of parallelism. Give every user a unique salt. A pepper is optional, useful as defense in depth. Do not use SHA-256 for passwords. A single modern GPU can guess roughly twenty-two billion SHA-256 hashes per second. For stored data, encrypt personally identifiable information and payment data. Tokenize card numbers to reduce PCI DSS scope. Between services, use mutual TLS, and keep keys in a vault, never in code. The takeaway is layered protection, applied at every step. Next, we move to enterprise data at rest and cloud key management.cheatsheetseries.owasp.org rfc-editor.org rfc-editor.org+22 min
09Practical Example: Enterprise Data-at-Rest and Cloud KMSNow, let's put these concepts into a concrete example for data at rest in the enterprise. Suppose you manage a fleet of laptops. You enforce full-disk encryption through your mobile device management tool, and you verify that BitLocker is active by reviewing Intune logs. This is your first layer of protection. For cloud workloads, you use a cloud key management service, such as AWS KMS, Azure Key Vault, or Google Cloud KMS. A key design choice is to keep your keys in a separate project or account from the data they protect. This separation is important. It enforces separation of duties, so the team that uses encrypted data is not the same team that controls the keys. Next, plan your rotation. Rotate keys at least annually, and more often for sensitive workloads or after any suspected compromise. When a key must be retired, set a minimum destruction window, often thirty days, before the key material is permanently erased. Alert on any key deletion or policy change so you can investigate quickly. Finally, understand the compliance benefit. If a laptop is stolen, full-disk encryption may allow you to avoid breach notification under safe harbor rules. But that safe harbor depends on the key not being compromised. If the backup copy of your key was co-located with the stolen data, the safe harbor does not apply. The lesson is this. Encryption protects data only when keys are managed separately and tracked carefully. Next, we will look at securing communication and encrypted messaging.docs.aws.amazon.com legalclarity.org compliancedocshq.com+22 min
10Practical Example: Secure Communication and Encrypted MessagingLet's bring these concepts together with a practical example: secure communication. First, distinguish two boundaries. Transport Layer Security protects each hop in transit, between your client and a server, or between servers. End-to-end encryption protects the message itself, so only the sender and the intended recipients can read it. The middle systems cannot. RCS messaging uses the Messaging Layer Security protocol, or MLS. That gives forward secrecy, so past messages stay safe if a current key leaks, and post-compromise security, so the conversation recovers after a key is compromised. In email, S/MIME dominates enterprise deployments, while PGP and OpenPGP persist in technical communities. Here is a risk to watch. When a gateway decrypts and re-encrypts mail on your behalf, it reintroduces EFAIL-class attacks and exposes plaintext to intermediate infrastructure. Now, choosing a method. Ask what path your recipient can actually use: the same provider, a PGP key, an S/MIME certificate, or a password-protected portal. And remember, metadata still leaks who talked to whom, and when. Next, we look at implementation pitfalls and encryption misconfigurations.2 min
11Implementation Pitfalls and Encryption MisconfigurationsNext, let's look at implementation pitfalls and encryption misconfigurations. A strong algorithm does not guarantee strong protection. Three patterns undermine it. First, weak keys, reused nonces, and retired modes like ECB break algorithms that were otherwise approved. If your system reuses the same nonce with the same key, confidentiality can leak. Second, hardcoded secrets, or keys stored right beside the data they protect, defeat encryption entirely. Think of a database backup where the key sits in the same configuration file. Third, downgrade attacks, disabled certificate validation, missing HSTS, and zero round trip replay risk. Recall that 0-RTT data is not protected against replay, so restrict it to idempotent requests. To find these problems, build a cryptographic inventory, sometimes called a CBOM. You cannot migrate what you have not inventoried. Then validate: run TLS scanners like testssl.sh and sslyze, scan for secrets, and bake those checks into your CI/CD baseline. Now, let's move on to key management and operational practices.cheatsheetseries.owasp.org rfc-editor.org rfc-editor.org+22 min
12Key Management and Operational PracticesLet's move from algorithms to the practice that keeps them trustworthy: key management. The governing references here are NIST SP 800-57 Part 1, SP 800-133, and SP 800-131A. You don't need every detail, but you do need to know they define how keys are generated, protected, and retired. One core concept is the cryptoperiod. That is the defined lifetime of a key. You should document it. Under PCI DSS, keys must be rotated at the end of their cryptoperiod. Next, where do keys live? Use a vault, such as a hardware security module, and inject short-lived credentials. Do not put keys in environment variables or config files. For audit evidence, keep a key inventory, access control records, FIPS certificates, and lifecycle runbooks. Here is the practical point. Saying we use AES is not an answer. You must prove custody, rotation, and control. That means an auditor can trace every key from creation to destruction. With that foundation, let's look ahead to crypto agility and post-quantum migration planning.csrc.nist.gov csrc.nist.gov nvlpubs.nist.gov+22 min
13Crypto Agility and Post-Quantum Migration PlanningLet's turn to crypto agility and post-quantum migration planning. Start with the threat. Adversaries may collect your encrypted traffic today, hoping to decrypt it later once a quantum computer exists. That is the harvest now, decrypt later model. Mosca's theorem gives you a simple planning rule. If X is how long your data must stay secret, and Y is your migration time, then X plus Y must not exceed Z, the expected arrival of a cryptographically relevant quantum computer. So when do you migrate? Plan around FIPS 203 for key establishment, 204 and 205 for signatures. HQC is expected to join as a future key encapsulation mechanism. For United States federal systems, key establishment moves to post-quantum by December thirty-first, twenty thirty, and signatures by December thirty-first, twenty thirty-one. TLS version one point three is required by January second, twenty thirty, and it is foundational for hybrid key exchange. Finally, build crypto agility. Do not hardcode algorithms. Carry key identifiers. Run hybrid deployments during the transition. Now let's look at applying this by role.csrc.nist.gov csrc.nist.gov nvlpubs.nist.gov+22 min
14Assessing, Teaching, and Applying Encryption by RoleLet us now look at how encryption responsibilities differ by role. Start with a self-assessment. Inventory where cryptography is used. Classify your data. Verify that TLS is correctly configured. Confirm full disk encryption on endpoints. And test that you can actually recover encrypted data. A backup you cannot restore is not a backup. For developers, use Argon2id for password storage. Rely on maintained libraries. Never roll your own cryptography. And always verify before you use decrypted data. For managers, the numbers matter. The IBM Cost of a Data Breach report found encryption reduces breach costs by roughly two hundred and eight thousand dollars. It also enables safer cloud and AI adoption. For educators, teach with real artifacts, such as TLS scans, key management policies, and the OWASP Cheat Sheets. Finally, stay current using NIST CSRC, OWASP, vendor advisories, and CISA or NSA key management guidance. In short, match your encryption actions to your role. That makes the work practical and measurable. Next, we will close with key takeaways, resources, and next steps.niccs.cisa.gov university.owaspblt.org nist.gov+22 min
15Closing: Key Takeaways, Resources, and Next StepsAs we close, let's anchor on five takeaways. Name the property you need before choosing a primitive. Use current, approved algorithms. Protect your keys. Prove your controls work. And plan for cryptographic agility. You will also see traps in the field. Electronic Codebook mode, the MD5 and SHA-1 hashes, Transport Layer Security version 1.0 and 1.1, RSA keys under 2048 bits, and hardcoded secrets. Keep NIST SP 800-57 and 800-131A, SP 800-52 revision 2, the post-quantum FIPS 203, 204, and 205, and the OWASP Cheat Sheets close at hand. Practically, developers should ship Argon2id for password storage and TLS 1.3, while managers commission a crypto inventory and an agility roadmap. Thank you for your attention and your work protecting data. Stay curious, keep testing, and revalidate this material as standards and threats evolve.niccs.cisa.gov university.owaspblt.org nist.gov+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.16 pages · 3.8 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.16 pages · 17.8 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.16 pages · 3.7 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.