Level
Advanced
Architecture and governance reasoning
High SchoolAdvanced TrackProfessional Defensive Learning
Advanced Module 14
A14 — Cryptography and Key Management Concepts
Cryptography protects data and trust relationships only when the architecture uses the right protection for the right purpose. Encryption, hashing, digital signatures, certificates, and keys are related, but they are not interchangeable.
A14 focuses on design decisions, lifecycle, ownership, governance, evidence, resilience, and common mistakes. It does not teach cryptographic attacks, cracking, key theft, or bypass techniques.
Lessons
10
A14.1 through A14.10
Assessment
25 Questions
Module test after A14.10
Portfolio
Final Recommendation
Key-management design
Main Question
How do you design cryptographic protection that stays trustworthy throughout its lifecycle?
A secure architecture does more than check whether encryption is present. It asks what protection goal exists, who owns the keys, where trust begins and ends, how certificates and keys change over time, what happens during failure or recovery, and what evidence proves the design still matches policy.
Safety boundary
A14 is strictly defensive. All keys, certificates, logs, cryptographic states, services, data flows, and architecture records are fictional. No lesson requires attacking, cracking, extracting, bypassing, or manipulating real cryptographic systems.
Protection Goals
Start With the Security Goal, Not the Algorithm Name
Confidentiality
Protect information from unauthorized disclosure. Encryption may support this goal when keys and lifecycle are governed correctly.
Integrity
Provide evidence that information has not changed unexpectedly. Hashing and signatures may support integrity in different ways.
Authenticity
Support confidence about the identity of a signer, service, or trusted endpoint through signatures, certificates, or related trust systems.
Trust lifecycle
Ensure keys, certificates, and cryptographic relationships can be issued, changed, rotated, revoked, recovered, and retired safely.
Resilience
Protect critical data while still supporting legitimate recovery, backup restoration, certificate renewal, and operational continuity.
Evidence
Produce enough metadata to show that protection, ownership, rotation, renewal, and policy requirements remain current.
Professional Review Pattern
A Practical Module-Level Cryptography Review
This five-part pattern is useful for the module as a whole. Individual lessons will use the structure that best fits the topic instead of repeating one rigid framework every time.
01
Define the protection goal
Start with confidentiality, integrity, authenticity, trust, lifecycle control, or the combination the system actually needs.
02
Map data, identities, and trust
Identify data, systems, workloads, users, services, certificates, and keys that participate in the relationship.
03
Evaluate key and certificate lifecycle
Review ownership, storage class, distribution, use, rotation, expiration, revocation, recovery, and retirement.
04
Verify evidence and resilience
Confirm the architecture produces current evidence for state, source health, rotation, renewal, failure, and recovery.
05
Make a governance decision
Classify the design as Confirmed, Conditional, Unknown, Blocked, Accepted Risk, or Not Applicable and assign next actions.
Learning Outcomes
Six Capabilities You Will Build
1
Explain the different security goals served by encryption, hashing, digital signatures, certificates, and key management.
2
Compare symmetric, asymmetric, and hybrid encryption models at an architecture level without relying on implementation shortcuts.
3
Evaluate cryptographic trust relationships using purpose, ownership, key lifecycle, certificate lifecycle, storage boundaries, and evidence.
4
Identify common cryptographic design mistakes such as unclear ownership, stale keys, missing rotation, weak policy alignment, and protection gaps.
5
Connect encryption in transit and at rest to data flows, storage locations, application boundaries, backups, recovery, and operational resilience.
6
Produce a Key-Management Design Recommendation integrating architecture, governance, monitoring, lifecycle, exceptions, and evidence.
Lesson Sequence
Ten Advanced Lessons
A14.1
Cryptography in System Design
Focus
Understand where cryptography belongs in secure architecture and why encryption, hashing, signatures, certificates, and key management solve different problems.
Defensive Lab
Build a fictional cryptography placement map covering data, trust boundaries, protection goals, owners, evidence, and design assumptions.
Portfolio Piece
Cryptography Architecture Map
A14.2
Symmetric and Asymmetric Encryption Concepts
Focus
Compare symmetric and asymmetric encryption conceptually, including performance, key relationships, architecture roles, and hybrid use.
Defensive Lab
Review fictional system flows and choose an appropriate encryption model using defensive architecture reasoning.
Portfolio Piece
Encryption Model Comparison
A14.3
Hashing, Salting, and Integrity Concepts
Focus
Distinguish hashing from encryption and study salting, integrity checking, password-storage concepts, and evidence limitations.
Defensive Lab
Classify fictional integrity requirements and identify where hashing, salting, or another protection goal belongs.
Portfolio Piece
Integrity Protection Review
A14.4
Digital Signatures Conceptually
Focus
Explain how digital signatures support authenticity and integrity and how signing differs from encryption.
Defensive Lab
Evaluate fictional signed artifacts, signer ownership, verification evidence, lifecycle, and trust assumptions.
Portfolio Piece
Digital Signature Trust Review
A14.5
Certificates and PKI Concepts
Focus
Understand certificates, certificate authorities, trust chains, identity binding, validity, revocation concepts, and PKI governance.
Defensive Lab
Review a fictional certificate inventory and map trust, ownership, expiration, renewal, and dependency evidence.
Portfolio Piece
Certificate and PKI Trust Register
A14.6
Key Storage and Rotation
Focus
Study key ownership, storage boundaries, generation, distribution, rotation, recovery, retirement, and evidence at a safe conceptual level.
Defensive Lab
Build a fictional key lifecycle register covering purpose, owner, storage class, rotation triggers, recovery, and retirement evidence.
Portfolio Piece
Key Lifecycle Register
A14.7
Common Crypto Design Mistakes
Focus
Recognize architecture mistakes such as unclear ownership, stale keys, inconsistent protection goals, missing rotation, and weak lifecycle governance.
Defensive Lab
Review fictional crypto architecture decisions and document safer design corrections without exploitation techniques.
Portfolio Piece
Crypto Design Mistake Review
A14.8
Encryption in Transit and At Rest
Focus
Compare protection goals for data moving between systems and data stored in applications, databases, backups, devices, and cloud services.
Defensive Lab
Map fictional data flows and storage locations to transit/rest protection requirements, owners, and evidence.
Portfolio Piece
Data Protection Coverage Matrix
A14.9
Crypto Policy and Compliance Concepts
Focus
Connect cryptographic architecture to policy, standards, ownership, exceptions, evidence, review cadence, and compliance obligations.
Defensive Lab
Create a fictional crypto-governance decision register with policy requirements, evidence, exceptions, owners, and remediation.
Portfolio Piece
Cryptography Governance Register
A14.10
Key Management Design Lab
Focus
Integrate A14.1–A14.9 into one enterprise key-management and cryptography architecture review.
Defensive Lab
Produce a fictional Key-Management Design Recommendation with lifecycle, trust, monitoring, governance, resilience, findings, and decision criteria.
Portfolio Piece
Key-Management Design Recommendation
Fictional Evidence Preview
Northbridge Cryptography Architecture Snapshot
Throughout A14, you will work with evidence like this: architecture records showing protection goals, ownership, lifecycle, design, and current evidence state.
CRY-01Confirmed
Student Services Web Session
Protection goal
Confidentiality + service identity
Design
Protected transport with managed certificate lifecycle
Owner
Application Team
Evidence
Current certificate + endpoint policy + monitoring
CRY-02Confirmed
Student Support Database
Protection goal
Confidentiality at rest
Design
Managed storage encryption with governed key ownership
Owner
Data Platform
Evidence
Storage policy + key lifecycle record
CRY-03Conditional
Reporting Export Workflow
Protection goal
Integrity + controlled disclosure
Design
Protected export path with policy-controlled access
Owner
Analytics Product Owner
Evidence
Current policy; rotation evidence due for review
CRY-04Conditional
Partner Integration Certificate
Protection goal
Service identity + trust
Design
Partner certificate bound to integration service
Owner
Integration Owner
Evidence
Sponsor current; renewal approaching
CRY-05Blocked
Legacy Reporting Key
Protection goal
Historical application encryption
Design
Legacy key with unclear ownership
Owner
Unknown
Evidence
Partial inventory + stale lifecycle metadata
CRY-06Confirmed
Backup Protection Key
Protection goal
Recovery confidentiality
Design
Recovery-bound key with documented lifecycle
Owner
Resilience Team
Evidence
Current recovery test + key inventory
Defensive Boundaries
What A14 Will and Will Not Do
1
Use fictional architectures, synthetic evidence, and provider-neutral examples.
2
Do not attempt to break, weaken, bypass, or defeat real encryption.
3
Do not request, expose, recover, or manipulate real keys, credentials, tokens, certificates, or secrets.
4
Do not perform cryptographic cracking, password attacks, key extraction, downgrade attacks, or certificate abuse.
5
Keep implementation discussion defensive, conceptual, and appropriate for authorized system design.
Career Connection
Professionals Who Work With These Decisions
Security Architect
Defines cryptographic protection goals and decides where cryptographic trust belongs in the system.
Cloud Security Engineer
Designs managed encryption, storage protection, certificate, and key-management boundaries.
Application Security Engineer
Reviews how applications use cryptographic protections and identifies unsafe design assumptions.
Identity / PKI Engineer
Manages certificate trust, issuing relationships, renewal, revocation, and service identity.
Security Operations Analyst
Monitors certificate, key, policy, and cryptographic evidence for operational issues.
Governance / Risk Analyst
Connects cryptographic design to policy, compliance, exceptions, ownership, and residual risk.
Portfolio Outcome
Key-Management Design Recommendation
Each lesson contributes one piece to the final A14 artifact. By the end of A14.10, you will be able to present a fictional key-management recommendation explaining protection goals, encryption models, integrity, signatures, PKI, key lifecycle, data protection coverage, governance, findings, and architecture decisions.
A14.1 — Cryptography Architecture Map
A14.2 — Encryption Model Comparison
A14.3 — Integrity Protection Review
A14.4 — Digital Signature Trust Review
A14.5 — Certificate and PKI Trust Register
A14.6 — Key Lifecycle Register
A14.7 — Crypto Design Mistake Review
A14.8 — Data Protection Coverage Matrix
A14.9 — Cryptography Governance Register
A14.10 — Key-Management Design Recommendation
Module Test
A14 — 25-Question Assessment
After A14.10, the module test will contain exactly 25 questions covering encryption types, hashing and salting, digital signatures, certificates and PKI, key storage and rotation, encryption in transit and at rest, crypto policy, and common crypto design mistakes.
A14 Module TestBegin Module 14
Start With Cryptography in System Design
A14.1 begins by placing cryptography inside the architecture before asking which mechanism to use. That foundation makes later key, certificate, integrity, transit/rest, and policy decisions easier to reason about.