Lesson A14.10
This capstone lesson combines every A14 concept into one enterprise architecture decision. You will review what needs protection, how cryptographic trust is implemented, whether key and certificate lifecycle is healthy, how recovery works, which evidence conflicts, and whether the overall design is ready for approval.
The entire lab uses fictional architecture records and metadata. There are no real keys, secrets, credentials, encrypted files, certificate stores, production systems, or offensive cryptographic tasks.
Lesson Progress
High School Advanced • A14: Cryptography and Key Management Concepts • Lesson 10 of 10
Readiness Check
0/5 ready
Capstone Mindset
A mature architecture review does not ask whether the system uses cryptography. It asks whether each cryptographic relationship is appropriate, owned, scoped, recoverable, lifecycle-managed, and supported by current evidence.
This lab also requires you to resist a common mistake: treating a mostly healthy architecture as automatically acceptable. A single high-impact trust path can justify a HOLD even when many other controls are strong.
Final decisions should be traceable from protection goal → cryptographic relationship → evidence → state → remediation → validation → governance decision.
Learning Objectives
Integrate protection goals, encryption models, hashing, signatures, PKI, key lifecycle, data-protection coverage, and governance into one coherent cryptography architecture review.
Resolve conflicting evidence by distinguishing Confirmed, Conditional, Unknown, Blocked, Accepted Risk, and Not Applicable states across technical and governance domains.
Prioritize remediation based on trust impact, data sensitivity, key or certificate scope, recoverability, lifecycle urgency, and evidence quality.
Make an architecture release recommendation that explains which cryptographic risks must block approval, which can be conditionally managed, and which are acceptable only through formal governance.
Produce the final Enterprise Cryptography and Key Management Review for the A14 portfolio.
Integrated Review
Review questions
Strong evidence
Asset inventory, data classification, trust-boundary map, protection requirement, owner.
Common evidence conflict
A control is technically strong but aimed at the wrong protection goal.
Review questions
Strong evidence
Encryption-model register, key scope, participants, performance need, lifecycle owner.
Common evidence conflict
A convenient key model creates excessive trust or difficult distribution.
Review questions
Strong evidence
Trusted manifest, object version, digest record, verifier event, mismatch action.
Common evidence conflict
A hash exists but the trusted reference is stale or unowned.
Review questions
Strong evidence
Signer inventory, protected signing boundary, verification logs, release authorization.
Common evidence conflict
A signature verifies mathematically but signer ownership or authorization is weak.
Review questions
Strong evidence
Certificate inventory, issuer path, trust-anchor list, owner, validity, renewal evidence.
Common evidence conflict
The leaf certificate is current but obsolete trust anchors remain accepted.
Review questions
Strong evidence
Key lifecycle register, version map, workload authorization, recovery test, retirement criteria.
Common evidence conflict
A new key exists but hidden workloads or retained data still depend on the old key.
Review questions
Strong evidence
Design finding register, severity, owner, environment, lifecycle, recovery, remediation.
Common evidence conflict
Strong algorithms are wrapped in weak ownership, scope, or recovery architecture.
Review questions
Strong evidence
Data Protection Coverage Matrix, path inventory, storage inventory, certificate/key owner, recovery evidence.
Common evidence conflict
One data state is protected while another is missing or stale.
Review questions
Strong evidence
Policy mapping, control owner, evidence owner, exception record, risk owner, review cadence.
Common evidence conflict
A technical control is healthy but the policy exception, owner, or evidence is expired.
Evidence States
Current technical and governance evidence supports the intended cryptographic control and lifecycle.
Release meaning: No material blocker remains in this domain.
The design is substantially acceptable, but a bounded lifecycle, evidence, or remediation condition remains.
Release meaning: May proceed only if the condition is explicitly owned, monitored, and time-bounded.
Evidence is missing, stale, contradictory, or insufficient.
Release meaning: Do not assume safety. Resolve evidence before relying on the control.
A material cryptographic trust, lifecycle, recovery, or governance problem prevents approval.
Release meaning: Must be remediated before release or continued operation where applicable.
A known residual risk is formally approved for a defined scope, owner, period, and review trigger.
Release meaning: May proceed only within the exact approved exception or risk boundary.
The control objective does not apply to this system or data scope.
Release meaning: Record rationale and approving owner.
Fictional Enterprise Context
Role: Public web application for student-support workflows
Data: Sensitive student support records
Crypto: Protected web transport, internal workload trust, database encryption, signed release artifacts
Dependencies: Portal certificate private key, database encryption key, release signing trust
Governance: Application owner + Platform Security + Data Platform
Role: Primary sensitive data store
Data: Sensitive support records
Crypto: Managed at-rest encryption with versioned key lifecycle
Dependencies: Database key v6 active; v5 retained for approved historical dependency
Governance: Data Platform + Student Services data owner
Role: External partner data exchange
Data: Scheduling messages
Crypto: Partner certificate, protected service transport, encrypted application storage
Dependencies: Partner certificate renewal due in 45 days
Governance: Integration Owner + external partner sponsor
Role: Signs production release artifacts
Data: Integrity-critical software packages
Crypto: Protected private signing key + verification trust in deployment pipeline
Dependencies: Signer generation 3; rotation planned next quarter
Governance: Release Engineering + deployment control owner
Role: Production backup and disaster-recovery repository
Data: Encrypted sensitive backup sets
Crypto: At-rest backup encryption + protected replication
Dependencies: Recovery key v4 active; retained versions map to older backup sets
Governance: Resilience Team
Role: Creates approved outbound data exports
Data: Sensitive report packages
Crypto: Encrypted temporary staging, protected recipient transfer, signed manifest
Dependencies: Per-export temporary data key + service certificate + signer trust
Governance: Analytics Product Owner + Data Governance
Role: Historical reporting application awaiting modernization
Data: Historical sensitive reports
Crypto: Legacy shared encryption key, old certificate trust, inconsistent transport protection
Dependencies: Owner Unknown for legacy key; retired CA trust remains on some hosts
Governance: Reporting Product Owner + Infrastructure Security + risk owner
Integrated Evidence
Claim
Sensitive student-support data needs confidentiality in transit and at rest plus integrity/authenticity for production releases.
Source
Current data classification + architecture map + release policy
Freshness
Current
Conflict
None
Decision
Protection goals are correctly separated and mapped to distinct controls.
Claim
Managed symmetric storage encryption is appropriate for high-volume database data.
Source
Current key inventory + database encryption state
Freshness
Current
Conflict
Logical authorization is a separate issue and must not be inferred from encryption.
Decision
Encryption model is appropriate; maintain separate access review.
Claim
Release artifact digest matches a trusted versioned manifest before deployment.
Source
Release manifest + verification event
Freshness
Current for version 8.4
Conflict
Digest match alone does not prove signer identity.
Decision
Integrity evidence is valid when combined with signature verification.
Claim
Production release package is signed by the approved release signer.
Source
Signer inventory + signature verification logs
Freshness
Current
Conflict
Next-quarter key rotation has not yet completed verifier-transition rehearsal.
Decision
Current signing is trusted; rotation readiness remains a release-readiness condition for the next lifecycle event.
Claim
Partner service certificate currently validates under the approved partner trust relationship.
Source
Current partner certificate + sponsor record
Freshness
Current
Conflict
Certificate expires in 45 days.
Decision
Current operation may continue under monitoring; renewal must close before expiry.
Claim
Database key v6 is active and v5 remains available only for approved retained-data dependency.
Source
Key Lifecycle Register + restore test
Freshness
Current
Conflict
Old-key retention could become excessive if the dependency closure date slips.
Decision
Maintain retention mapping and retire v5 when closure criteria are met.
Claim
Backup encryption keys are present and versioned.
Source
Current key inventory
Freshness
Current
Conflict
Last full restore test is fourteen months old.
Decision
Key inventory is current, but recoverability remains Conditional until a current restore test passes.
Claim
Export is protected in staging and during recipient transfer.
Source
Storage policy + recipient trust + export workflow
Freshness
Current
Conflict
Recipient authorization must remain separate from transport trust.
Decision
Coverage is acceptable when authorization and cleanup remain enforced.
Claim
Legacy key storage does not meet the approved managed-key standard.
Source
Legacy key inventory + architecture exception EXC-14-04
Freshness
Current
Conflict
Exception expires 2027-01-31 and modernization is incomplete.
Decision
Legacy key gap is acceptable only within the exact exception scope and until the approved expiry.
Claim
Retired internal CA is still trusted by three production hosts.
Source
Current trust-store inventory
Freshness
Current
Conflict
No approved exception covers obsolete CA trust.
Decision
Remove obsolete trust after dependency mapping and migration; this remains a blocker.
Claim
Legacy shared encryption key owner cannot be established.
Source
Partial key inventory + stale documentation
Freshness
Partial / stale
Conflict
Modernization exception does not make Unknown ownership safe.
Decision
Assign accountable ownership and map key copies/dependencies before approval.
Claim
Some internal legacy report transfers use an old unverified transport path.
Source
Current architecture review + partial flow evidence
Freshness
Partial
Conflict
Internal network location was historically treated as sufficient trust.
Decision
Modernize transport protection and endpoint trust; internal placement is not a compensating control.
Claim
Export manifest is signed by the approved analytics export signer.
Source
Signature verification + signer inventory
Freshness
Current
Conflict
Signature authenticity does not itself authorize release to the recipient.
Decision
Require both signed-manifest verification and export authorization.
Claim
Temporary workspace storage is encrypted.
Source
Workspace storage configuration + project policy
Freshness
Current
Conflict
Automatic destruction evidence is still under review.
Decision
Keep Conditional until retention and cleanup evidence proves the temporary lifecycle.
Fake Dashboard
Fictional integrated A14 architecture state
Architecture domains
9
Protection goals through governance reviewed across A14.1–A14.9
Evidence records
14
Current, Conditional, Accepted Risk, and Blocked evidence integrated
P0 blockers
3
Retired CA trust, unowned legacy shared key, and inconsistent legacy transport
Final recommendation
HOLD
Modern architecture is strong, but unresolved legacy trust paths block approval
Fake SOC Alert
Source: Fictional Enterprise Cryptography Review • Time: 11:23
Conflicting Evidence
Mature reviews often contain evidence that looks contradictory only because it measures different parts of the architecture. Your job is to identify what each source actually proves.
Evidence A
Backup key inventory is current and shows expected key versions.
Evidence B
Full restore validation is fourteen months old.
Correct interpretation
Current key metadata supports key governance, but it does not prove recoverability. Recovery remains Conditional.
Why: Different evidence sources prove different control objectives.
Evidence A
Current release signatures verify successfully.
Evidence B
Verifier transition for the next signing-key rotation has not yet been rehearsed.
Correct interpretation
Current signing trust is acceptable, but lifecycle readiness remains Conditional.
Why: Current effectiveness and future transition readiness are separate decisions.
Evidence A
EXC-14-04 allows a bounded legacy key-storage deviation through 2027-01-31.
Evidence B
A retired CA remains trusted in production and is not covered by the exception.
Correct interpretation
The key-storage gap may be Accepted Risk, while the obsolete trust-anchor gap remains Blocked.
Why: Exceptions apply only to their documented scope.
Evidence A
Workspace storage is encrypted and project access is scoped.
Evidence B
Automatic destruction evidence has not yet been confirmed.
Correct interpretation
Confidentiality is strong while the data exists, but lifecycle governance remains Conditional.
Why: Encryption does not solve retention.
Evidence A
The partner certificate validates today and sponsor evidence is current.
Evidence B
The certificate expires in 45 days.
Correct interpretation
Current trust can remain in service under monitoring, but renewal is a time-bounded condition.
Why: Validity today does not remove lifecycle responsibility.
Fake Log Panel
[08:11] CRYPTO-01 goals system=STUDENT_PORTAL state=CONFIRMED [08:35] CRYPTO-04 signing current=TRUSTED rotation_rehearsal=OPEN state=CONDITIONAL [08:59] CRYPTO-05 partner-cert valid=YES expiry=45d state=CONDITIONAL [09:23] CRYPTO-07 recovery key_inventory=CURRENT restore_test_age=14mo state=CONDITIONAL [09:47] CRYPTO-09 legacy-key exception=VALID state=ACCEPTED_RISK [10:11] CRYPTO-10 retired-ca trusted_hosts=3 exception=NONE state=BLOCKED [10:35] CRYPTO-11 legacy-key owner=UNKNOWN copies=MULTIPLE state=BLOCKED [10:59] CRYPTO-12 legacy-transit protection=INCONSISTENT state=BLOCKED [11:23] DECISION overall=HOLD p0_blockers=3 conditional_items=4 accepted_risk=1
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Release Criteria
Pass
All retired or unauthorized trust anchors are removed or covered by valid, explicit governance.
Fail
A retired CA remains trusted without an approved exception.
Pass
Key purpose, owner, scope, storage boundary, users, lifecycle, and dependencies are known.
Fail
A shared production key has Unknown owner or uncontrolled copies.
Pass
Protected backups and retained data can be restored under the current key lifecycle.
Fail
Only key inventory exists while restore validation is stale.
Pass
Renewals and rotations have owner, timeline, verifier transition, and evidence.
Fail
An expiring certificate or planned signer rotation has no accountable transition.
Pass
Transit, storage, backup, export, replication, and temporary copies are mapped and governed.
Fail
A sensitive legacy flow uses unverified transport or unmanaged storage.
Pass
Identity/access decisions remain separate for databases, exports, services, and signing workflows.
Fail
A valid certificate, signature, or encryption state is treated as blanket permission.
Pass
Every exception has exact scope, compensating controls, risk owner, expiry, and closure criteria.
Fail
A deviation exists with no valid exception or the exception has expired.
Pass
Material decisions use current, attributable, non-contradictory evidence.
Fail
High-impact claims depend on stale, missing, or Unknown evidence.
Remediation
Owner
Infrastructure Security
Action
Complete dependency mapping, migrate any legitimate remaining certificate relationships, remove obsolete trust anchors, and record closure evidence.
Validation
Current trust inventory shows retired CA absent from production relying systems.
Owner
Reporting Product Owner + Infrastructure Security
Action
Assign accountable owner, map key copies and retained-data dependencies, restrict further use, and execute the approved modernization path.
Validation
Key register has current owner, exact scope, dependency map, and migration state.
Owner
Reporting Platform Team
Action
Replace unverified internal transfer paths with approved protected service communication and current endpoint trust.
Validation
Data-flow evidence shows protected transport for all sensitive legacy transfer paths.
Owner
Resilience Team
Action
Perform an authorized full recovery validation using the current key-version and backup lifecycle, then refresh evidence.
Validation
Current restore evidence confirms required backup sets and key versions are usable.
Owner
Integration Owner
Action
Complete certificate renewal, relying-system validation, and old-trust retirement before expiry.
Validation
Replacement certificate is current and old relationship is retired after validation.
Owner
Release Engineering
Action
Validate new verifier trust, deployment policy, rollback, and historical-signature handling before rotation.
Validation
Controlled rehearsal proves signer and verifier transition without breaking release verification.
Owner
Data Science Platform
Action
Verify automated cleanup and retention closure for temporary encrypted workspaces.
Validation
Lifecycle evidence shows expired workspaces and data copies are removed according to policy.
Owner
Data Platform
Action
Track retained-data dependency and retire key v5 once closure criteria are met.
Validation
No required data depends on v5 and retirement is recorded.
Decision Board
| Area | State | Evidence | Blocker | Decision |
|---|---|---|---|---|
| Protection goals | Confirmed | Current classification + architecture map | No | Distinct confidentiality, integrity, authenticity, and authorization goals are mapped correctly. |
| Encryption model selection | Confirmed | Current model and key-scope register | No | Primary modern systems use defensible symmetric/asymmetric/hybrid patterns. |
| Integrity and signatures | Conditional | Current verification + future rotation condition | No | Current release trust is sound; rotation readiness must close before the lifecycle event. |
| PKI | Blocked | Retired CA still trusted in production | Yes | Obsolete trust anchor must be removed. |
| Key storage and lifecycle | Blocked | Legacy shared key owner Unknown | Yes | Modern key program is strong, but unmanaged legacy key trust prevents approval. |
| Transit / at-rest coverage | Blocked | Legacy transfer path inconsistent | Yes | Modern data flows are well protected; legacy sensitive transit remains unacceptable. |
| Recovery | Conditional | Restore evidence fourteen months old | No | Must refresh recovery proof before full confidence. |
| Governance / policy | Conditional | Legacy key exception valid; other legacy PKI gap not covered | No for exception, Yes for uncovered PKI gap | Governance works when scoped precisely; exception cannot be stretched to unrelated trust problems. |
| Overall release recommendation | HOLD | Three P0 cryptographic architecture blockers remain | Yes | Do not approve full enterprise cryptography posture until REM-01, REM-02, and REM-03 close. |
Final recommendation
HOLD
The modern cryptography architecture is strong across most domains, but three P0 legacy trust problems remain: obsolete CA trust, an unowned shared encryption key, and inconsistent protected transport. These are independent blockers and should be closed before full enterprise approval.
Analyze the Evidence
Review Anti-Patterns
Why it fails: Most domains are healthy, so reviewers average the results and ignore one critical Blocked trust path.
Better approach: Treat material blockers independently of the overall percentage of healthy controls.
Why it fails: A valid exception for one key-storage issue is used to justify unrelated certificate or transport gaps.
Better approach: Apply exceptions only to the exact documented requirement and scope.
Why it fails: A certificate or signing key works today, so renewal or rotation readiness is ignored.
Better approach: Separate current effectiveness from lifecycle readiness.
Why it fails: A valid key or certificate is treated as sufficient despite Unknown ownership or expired risk approval.
Better approach: Require both technical and governance evidence for material decisions.
Why it fails: A policy exception is treated as proof that the underlying control is healthy.
Better approach: Keep the technical state visible even when risk is formally accepted.
Why it fails: Teams assume backups are safe because encryption and key inventory are current.
Better approach: Require current restore evidence for recovery-related control objectives.
Why it fails: Modern systems score well because difficult legacy trust paths are omitted from the review.
Better approach: Keep legacy dependencies visible until migration or retirement is complete.
Why it fails: A ticket is closed because work was attempted, not because evidence proves the risk changed.
Better approach: Every remediation should have objective closure evidence.
Scenario Decision Lab
The enterprise review shows strong modern encryption, PKI, signing, and key management, but three high-impact legacy trust problems remain unresolved.
Scenario Decision Lab
The backup platform shows current encryption keys and healthy backup creation, but the last full restore validation is fourteen months old.
Safe Capstone Lab
Build the final A14 portfolio artifact using only fictional systems, key IDs, certificate metadata, evidence records, policy records, and risk decisions. The deliverable should read like a professional architecture review, not a collection of isolated lesson exercises.
Define the enterprise scope and business context.
List all important systems, data classes, services, partners, backups, exports, and legacy components.
Map confidentiality, integrity, authenticity, authorization, and recovery goals.
Map symmetric, asymmetric, and hybrid encryption relationships.
Map hashing/integrity controls and trusted references.
Map signer identities and digital-signature trust.
Map certificate subjects, issuers, trust anchors, and relying systems.
Map key classes, owners, storage boundaries, versions, and authorized workloads.
Map rotation, renewal, revocation, recovery, and retirement triggers.
Map encryption in transit.
Map encryption at rest.
Include backups, replication, exports, archives, and temporary storage.
Map policy and standard requirements.
Map technical evidence and governance evidence separately.
Classify every domain and material finding.
Create at least twenty-five integrated evidence records.
Create at least five explicit evidence conflicts.
Explain what each conflicting source actually proves.
Create release criteria.
Identify P0, P1, and P2 remediation.
Assign owners to every remediation.
Define objective validation evidence for closure.
List all active exceptions and Accepted Risks.
Verify exception scope, owner, expiry, compensating controls, and closure criteria.
Identify the three highest residual risks.
Write a final APPROVE, CONDITIONAL APPROVAL, or HOLD recommendation.
Explain exactly what evidence would change that recommendation.
Add change triggers for data classification, owner, environment, provider, algorithm policy, key version, certificate, signer, trust anchor, recovery, incident, and exception expiry.
Include a one-page executive summary.
Include a technical evidence appendix.
Include a governance and exception appendix.
Capstone safety boundary
Do not collect, expose, recover, extract, or manipulate real keys, secrets, certificates, trust stores, encrypted files, or private organizational data. Do not intercept traffic, crack encryption, forge signatures, or test live systems. The entire capstone is fictional and defensive.
Advanced Challenge
A strong senior security architect can communicate the same cryptography decision at two levels. Build both views.
The two views should never contradict each other. The executive summary should be a faithful compression of the technical evidence, not a softer version of the risk.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the final A14 portfolio artifact: an Enterprise Cryptography and Key Management Review integrating your A14.1–A14.9 work. Include scope, systems, protection goals, encryption models, integrity controls, signer trust, PKI, key lifecycle, design mistakes, transit/rest coverage, governance, evidence states, conflicts, release criteria, remediation priorities, exceptions, Accepted Risks, residual risk, validation evidence, and a final APPROVE, CONDITIONAL APPROVAL, or HOLD recommendation.
Confidence / Readiness Reflection
The module test will assess the entire A14 progression. You should be able to reason from a protection goal to a cryptographic control, then through trust, key lifecycle, evidence, recovery, policy, and a final architecture decision.
I can explain symmetric, asymmetric, and hybrid encryption by architecture purpose.
I can distinguish hashing, salting, signing, certificates, and encryption.
I can evaluate PKI and key lifecycle without exposing secrets.
I can follow sensitive data across transit, rest, backup, export, and recovery.
I can resolve conflicting evidence and make an explicit cryptography architecture recommendation.
Portfolio Build Guide
Tell the reader what environment is reviewed and whether your conclusion is APPROVE, CONDITIONAL APPROVAL, or HOLD.
Key, certificate, signer, recovery, transport, storage, and policy claims should point to current evidence records.
Explain why one source may be Confirmed while a related lifecycle or recovery source remains Conditional.
Do not bury P0 issues beneath a large number of healthy findings.
Show precisely which requirement each exception covers and what it does not cover.
A remediation is not complete until current evidence proves the trust state changed.
Executives need risk and decision clarity; technical reviewers need evidence and lifecycle depth.
Use this review as your primary study artifact for the 25-question A14 assessment.
Key Takeaways
Capstone Safety Boundary
Do not extract or recover real keys, inspect private key material, crack encryption, forge signatures, alter trust stores, bypass certificate validation, capture protected traffic, access encrypted data, or test real systems without authorization. All architecture, evidence, keys, certificates, logs, and findings in this lab are fictional.
Lesson Complete
You have now completed all ten A14 lessons and produced the final Enterprise Cryptography and Key Management Review. The next page is the A14 Module Test with 25 questions covering the full module.