CISSP Domain 3, Security Architecture and Engineering, is the largest technical domain on the exam (13%) and the one that scares the most candidates. It is the domain of cryptography, secure design principles, security models, hardware platforms, and the architectural decisions that determine whether a system is defensible by design or vulnerable by default. The trap here is the opposite of Domain 1: candidates over-prepare on cryptography and under-prepare on the architectural reasoning the exam actually rewards.
This guide brings together the 14 in-depth Domain 3 articles on Threat on the Wire into one structured reference. Use it as a study path or a topic index. The goal is to give you the architectural intuition the exam wants - not just the formulas and acronyms.
What Domain 3 is really testing
CISSP lens: the right answer reflects defence in depth, fail-safe defaults, and design choices that are sustainable over time. Cryptographic detail is the means, not the end.
Domain 3 has a reputation for being a cryptography exam. It is not. Cryptography is one of seven topic clusters in the domain, and the exam expects you to recognise architectural patterns, apply secure design principles, and reason about security models - long before it expects you to compute key sizes.
You will be tested on:
- Secure design principles: least privilege, defence in depth, fail-safe defaults, separation of duties, complete mediation.
- Security models: Bell-LaPadula, Biba, Clark-Wilson, Brewer-Nash, and the rules each enforces.
- Cryptography fundamentals: symmetric vs asymmetric, hashing, modes of operation, key length and choice.
- Applied cryptography: TLS, IPsec, S/MIME, PGP, and where each fits.
- PKI: certificates, certificate authorities, revocation, trust chains.
- Hardware security: CPUs, memory, firmware, TPM, HSM, and the attacks that target each.
- Embedded systems and IoT: lifecycle, supply chain, update, decommission.
- Site and facility design: physical security as architecture.
- Virtualisation and cloud: how shared infrastructure changes the security model.
- Evaluation criteria: Common Criteria, Protection Profiles, and Evaluation Assurance Levels.
How Domain 3 fits into the rest of the CBK
Domain 3 is the engineering heart of the CBK. Its principles power the network design choices in Domain 4, the access models in Domain 5, the testing strategies in Domain 6, the hardening practices in Domain 7, and the secure coding patterns in Domain 8.
If a Domain 4 firewall question and a Domain 8 SDLC question both feel architecturally familiar, that is the Domain 3 reasoning bleeding through. Master the principles here and the rest of the exam gets noticeably easier.
Core concepts at a glance
| Concept | What it is | Why it matters on the exam |
|---|---|---|
| Defence in depth | Layered controls so failure of one is not failure of all | The default architectural answer when in doubt |
| Fail-safe defaults | If something fails, it fails into the secure state | Tested in scenario questions about config errors |
| Bell-LaPadula | Confidentiality model: no read up, no write down | Government-classification heritage; pure confidentiality |
| Biba | Integrity model: no read down, no write up | Inverse of Bell-LaPadula; integrity-focused |
| Clark-Wilson | Integrity model: well-formed transactions, separation of duties | Commercial integrity, accounting-system heritage |
| Brewer-Nash (Chinese Wall) | Conflict-of-interest model | Tested with consulting/competitor scenarios |
| Symmetric crypto | One shared key for encrypt and decrypt (AES, ChaCha20) | Fast, requires secure key exchange |
| Asymmetric crypto | Public/private key pair (RSA, ECC) | Slower, solves key exchange and identity |
| PKI | Certificate authorities, trust chains, revocation | The infrastructure for asymmetric crypto at scale |
| TPM / HSM | Hardware modules that store and use keys | TPM in endpoints, HSM in servers/data centres |
| Common Criteria | International standard for product security evaluation | Replaced TCSEC; uses Protection Profiles and EALs |
Security architecture fundamentals
Architecture is the layer above controls. A control is a thing you implement; an architecture is the structure of decisions about which controls go where, why, and how they fit together. Domain 3 expects you to think architecturally before you reach for a specific control.
Start with Security Architecture Fundamentals: Building Systems That Resist Attack by Design. Then read Secure System Design Principles: The Rules That Prevent Architecture Failures. The principles - least privilege, defence in depth, separation of duties, fail-safe defaults, complete mediation, economy of mechanism, open design, least common mechanism, psychological acceptability - are the reasoning frame for nearly every Domain 3 question.
Security models
Security models formalise what "security" means for a given concern. Each model defines a property and the rules that enforce it. The exam tests three things: which model corresponds to which concern (confidentiality vs integrity vs conflict of interest), what the rules say in plain language, and which scenario calls for which model.
Read Security Models and Frameworks You Actually Need to Know for the full breakdown of Bell-LaPadula, Biba, Clark-Wilson, and Brewer-Nash, plus the lesser-tested Lipner, Take-Grant, and HRU models.
Security model quick rules
- Bell-LaPadula = confidentiality. Government heritage. "No read up, no write down" - low-clearance subjects cannot read high-classification data, high-clearance subjects cannot leak by writing to lower levels.
- Biba = integrity. The inverse: "no read down, no write up" - high-integrity subjects cannot be polluted by low-integrity data, low-integrity subjects cannot tamper with high-integrity data.
- Clark-Wilson = commercial integrity. Well-formed transactions, separation of duties, certified processes. Accounting and ERP system heritage.
- Brewer-Nash = conflict of interest. Once a subject accesses data in one conflict-of-interest class, they cannot access another in the same class. Consulting-firm heritage.
Cryptography essentials
Cryptography is the most heavily-tested topic in Domain 3, but the exam tests architectural reasoning more than mathematical detail. You must know which algorithm fits which job, what each cryptographic property guarantees, and where crypto typically breaks. You do not need to compute AES rounds by hand.
Build the foundation with Cryptography Essentials for Security Architects. Then move to Applying Cryptography: TLS, IPsec, Email Security, and Crypto in the Wild for the protocol-level material. Finish with Key Management and Cryptographic Attacks: Where Crypto Actually Breaks, because key compromise is the dominant failure mode in real-world cryptography.
When to use which crypto
| Goal | Use | Why |
|---|---|---|
| Bulk data encryption | Symmetric (AES-GCM, ChaCha20-Poly1305) | Fast; symmetric is the only practical choice for large data |
| Key exchange over an untrusted channel | Asymmetric (Diffie-Hellman, ECDH) | Solves the symmetric-key distribution problem |
| Digital signature for authenticity | Asymmetric (RSA, ECDSA, Ed25519) | Private key signs, public key verifies |
| Integrity verification | Cryptographic hash (SHA-256, SHA-3) | One-way function; produces a fixed-size fingerprint |
| Message authentication | HMAC, AEAD modes | Combines integrity with secret-key authentication |
| Password storage | Argon2, scrypt, bcrypt | Adaptive cost; resistant to brute force on stolen hashes |
PKI and certificate management
PKI is the infrastructure that makes asymmetric cryptography work at scale. Browsers trust websites, employees trust email, and machines trust each other through a hierarchy of certificate authorities and the trust chains they sign. The exam tests the lifecycle (issue, validate, renew, revoke) and the failure modes (CA compromise, expired certs, weak signatures).
PKI and Certificate Management: The Trust Infrastructure Behind Everything covers it end to end.
Hardware and embedded systems
Software cannot be more secure than the hardware it runs on. The exam tests three hardware areas: the platform components themselves (CPU, memory, firmware), the dedicated security hardware (TPM, HSM), and the embedded/IoT systems that increasingly carry sensitive data without the operational maturity of traditional IT.
Read Securing the Hardware Platform: CPUs, Memory, Firmware, and the Attacks That Target Them for the platform layer. Then read Embedded Systems and IoT Security: Securing the Devices Nobody Thinks About for the IoT angle - which the exam increasingly tests as the industry's blind spot.
Site, facility, and virtualisation
Physical security is part of the architectural picture. Secure Site and Facility Design covers the layered-perimeter approach, environmental controls, and the design choices that determine whether a data centre can survive a fire, a flood, or a bad actor with social-engineering skills.
Virtualisation and Cloud Security Architecture handles the modern equivalent: when the "physical" boundary is a hypervisor or a tenant separation in a multi-tenant cloud, what is the architectural model that keeps tenants apart?
Application-side architecture is covered in Secure Software Architecture Concepts, which is the bridge to Domain 8's secure SDLC material.
Evaluation criteria and product certification
Common Criteria, Protection Profiles, and Evaluation Assurance Levels (EALs) are the international system for evaluating product security. The exam tests the vocabulary - what an EAL means, how a Protection Profile relates to a Security Target - more than the deep procurement details.
Evaluation Criteria and Security Certifications: Common Criteria, TCSEC, and How to Evaluate Product Security Claims covers the modern Common Criteria framework, the historical TCSEC (Orange Book) it replaced, and how to read a vendor's "we are EAL4 certified" claim.
Real-world architect scenarios
A security architect is asked to design the encryption strategy for a new SaaS platform. The technical instinct is to pick AES-256 and call it done. The architect instinct is layered. First, identify the data classifications in scope and what each requires. Second, decide what to encrypt at rest, in transit, and in use - they are three distinct problems. Third, pick algorithms appropriate to each (AES-GCM at rest, TLS 1.3 in transit, application-level encryption for the most sensitive fields). Fourth, plan key management: where keys live, who can access them, how they rotate. Fifth, plan crypto-agility: how the system will swap algorithms when AES-256 inevitably becomes weak in 15-25 years. Domain 3 questions reward this layered, lifecycle-aware thinking.
A second example: an architect is reviewing a startup's plan to embed customer data in a Lambda function for performance reasons. The technical instinct is to talk about IAM and KMS. The architect instinct adds Bell-LaPadula and Biba reasoning: which integrity and confidentiality properties does the data require, and does the proposed architecture preserve them? Most "performance" architectures fail because they violate one of those properties without naming it.
Common exam traps in Domain 3
- Picking the strongest algorithm without context. AES-256 is not always the right answer. Sometimes AES-128 is the right answer because of performance or interop. Sometimes the answer is "no encryption is needed" because the data is public.
- Confusing Bell-LaPadula and Biba directions. Bell-LaPadula = confidentiality = no read up, no write down. Biba = integrity = no read down, no write up. They mirror each other.
- Forgetting that hashes are not encryption. A hash is one-way and does not protect confidentiality. The exam loves "to ensure confidentiality, the system uses SHA-256" as a wrong answer.
- Calling certificates the same as keys. A certificate binds a public key to an identity and is signed by a CA. The key is the cryptographic material; the certificate is the trust artefact around it.
- Treating EAL as a security score. EAL is an assurance level - how well the product was evaluated, not how secure it is. EAL7 means rigorous evaluation, not unbreakable.
- Skipping the design principles. Saltzer and Schroeder's principles (least privilege, fail-safe defaults, etc.) are the most testable architectural content in the domain. They show up in scenario questions disguised as "best practices."
The full Domain 3 reading order
Architecture and design
- Security Architecture Fundamentals
- Secure System Design Principles
- Secure Software Architecture Concepts
Security models
Cryptography
- Cryptography Essentials
- Applying Cryptography: TLS, IPsec, Email Security
- Key Management and Cryptographic Attacks
- PKI and Certificate Management
Hardware and embedded systems
Site, facility, and virtualisation
Evaluation criteria
Exam scenario practice
Related CISSP domains
Threat on the Wire publishes a long-form pillar for every CISSP domain. The eight domains are interlocked - mastering any one of them is easier when you can see how it connects to the others. Here's how this domain relates to the other seven, with a one-line summary of the relationship and a link to the pillar.
| Pillar | How it relates to this domain |
|---|---|
| Domain 1: Security and Risk Management | Architectural decisions in Domain 3 flow from Domain 1 governance and risk. |
| Domain 2: Asset Security | Classification labels from Domain 2 drive the encryption choices made here. |
| Domain 4: Communication and Network Security | Cryptography from Domain 3 powers the secure protocols in Domain 4. |
| Domain 5: Identity and Access Management | Authentication factors and PKI from Domain 3 underpin Domain 5 IAM. |
| Domain 6: Security Assessment and Testing | Architectural validation is a Domain 6 testing exercise. |
| Domain 7: Security Operations | Hardened systems from Domain 3 get sustained in Domain 7 operations. |
| Domain 8: Software Development Security | Secure software architecture in Domain 3 frames the secure SDLC in Domain 8. |
For the full CISSP overview, exam structure, and 12-week study plan, see the CISSP Study Hub.
Frequently asked questions
How much of the CISSP exam covers Domain 3?
Domain 3 is weighted at 13% of the exam, the largest of the technical domains. Out of roughly 100-150 items on a CAT exam, expect 13-20 of them to come from Domain 3. The cryptography subset alone usually accounts for 4-6 questions; the architectural reasoning is woven into many more across other domains.
How deep do I need to go on cryptography?
Deep enough to recognise which algorithm fits which job, what each cryptographic property (confidentiality, integrity, authentication, non-repudiation) guarantees, and where typical implementations break. You do not need to compute key schedules, prove number-theoretic results, or implement primitives. The exam rewards architectural reasoning and protocol awareness over mathematical depth.
When does the exam expect Bell-LaPadula vs Biba?
Bell-LaPadula when the question is about confidentiality - keeping classified information from leaking down to lower-clearance subjects. Biba when the question is about integrity - keeping high-integrity data from being polluted by lower-integrity sources. The wording is the giveaway: "classified," "clearance," and "leak" usually point to Bell-LaPadula; "integrity," "trustworthiness," and "tamper" point to Biba.
What is the difference between TPM and HSM?
A Trusted Platform Module (TPM) is a small chip on a motherboard that stores keys, performs basic crypto operations, and supports platform attestation. It is per-device and inexpensive. A Hardware Security Module (HSM) is a server-grade or rack-mountable cryptographic appliance that stores high-value keys, performs operations at scale, and meets standards like FIPS 140-2 / 140-3. TPMs protect the endpoint; HSMs protect the centralised key infrastructure.
What does EAL4 actually mean?
An Evaluation Assurance Level under Common Criteria describes how rigorously a product was evaluated, not how secure the product is. EAL1 is functional testing of basic claims. EAL4 is "methodically designed, tested, and reviewed" - the typical commercial-grade target. EAL7 is formally verified design and testing, common for defence-grade products. A high-EAL product can still be insecure if the underlying design is weak; EAL measures evaluation rigor, not absolute security.
Key takeaways
- Domain 3 is the engineering heart of the CBK. Its principles power every other technical domain.
- Architecture comes before controls. The right answer is usually the one that reflects defence in depth, fail-safe defaults, or another Saltzer-Schroeder principle.
- Security models pair concerns to rules: Bell-LaPadula for confidentiality, Biba for integrity, Clark-Wilson for commercial integrity, Brewer-Nash for conflict of interest.
- Cryptography fits jobs by property: symmetric for bulk encryption, asymmetric for key exchange and signatures, hashes for integrity, AEAD for authenticated encryption.
- PKI is the infrastructure layer of asymmetric crypto. Certificates bind public keys to identities; revocation and trust chains are tested.
- Hardware security matters: TPM at the endpoint, HSM at the server, and the platform-level attacks (firmware, supply chain) you must recognise.
- Evaluation criteria (Common Criteria, EALs) measure evaluation rigor, not absolute security.
If you take one thing away from Domain 3, take this: architectural reasoning beats algorithmic depth on the exam. Master the design principles and the security models, and the cryptography questions become exercises in matching the right tool to the right job.