Overview
Security Engineering is 31% of the CAS-005 exam, the largest share, and covers eight objectives: troubleshooting identity and access management (IAM) components, enhancing endpoint and server security, troubleshooting complex network infrastructure issues, implementing hardware security, securing specialized and legacy systems, using automation, explaining advanced cryptographic concepts and applying cryptographic use cases and techniques. The verbs matter: many objectives say troubleshoot, implement or apply, so questions often show symptoms, logs or configurations and ask what is wrong or what to change.
This domain is where the designs from Security Architecture meet reality. A federation design fails because of a clock or certificate problem, a Zero Trust plan depends on TPM-backed device attestation, and a data protection requirement becomes a specific choice of tokenization, envelope encryption or crypto erase. Security Operations then relies on the hardened, automated and well-instrumented systems built here.
How it's tested
Expect troubleshooting scenarios with log excerpts, error messages, configuration snippets or symptoms, and implementation questions asking which technology or technique meets a requirement. Performance-based items may involve reading a script, a SCAP result or a certificate. The answer usually follows from one technical detail, so read the exhibit before the options.
-
Symptom to root cause
An authentication, VPN, TLS or email failure is described with an error or log line, and you identify the misconfiguration that explains it and the fix.
-
Requirement to technology
A requirement such as remote boot integrity, computing on encrypted data or quantum-resistant key exchange is stated, and you choose the hardware or cryptographic technique that delivers it.
-
Constrained system protection
A legacy, OT or embedded system cannot be patched or changed, and you choose compensating controls such as segmentation, monitoring or protocol-aware gateways.
Users can log in to a SaaS app through SSO from most offices, but one site gets 'assertion not yet valid' errors. Options include reissuing the IdP signing certificate, adding the site to conditional access, correcting time synchronization at that site and switching to OAuth. Assertions carry validity timestamps, and a single site failing points to local clock drift, so fixing NTP at that site is correct.
Objectives 8
Official objectives from the CompTIA outline, in outline order.
3.1 Given a scenario, troubleshoot common issues with identity and access management (IAM) components in an enterprise environment.Subject access control, biometrics, secrets, conditional access, attestation, cloud IAM policies, PAM and authentication protocols.
- What it means
- This objective covers subject access control for users, processes, devices and services; biometrics; secrets management for tokens, certificates, passwords and keys, including rotation and deletion; conditional access using user-to-device binding, geographic location, time and configuration; attestation; cloud IAM access and trust policies; logging and monitoring; privilege identity management; and SAML, OpenID, MFA, SSO, Kerberos, SAE, PAM, OAuth, EAP, identity proofing, IEEE 802.1X and federation.
- What to understand
- Many IAM failures are time or trust failures: Kerberos tickets and SAML assertions are rejected when clocks drift beyond tolerance (Kerberos defaults to five minutes), and federation breaks when a signing certificate expires or is rotated without updating the relying party. In 802.1X the supplicant talks to the authenticator (switch or access point), which relays EAP to a RADIUS authentication server, so EAP-TLS failures often trace to an untrusted or expired client or server certificate. Cloud trust policies define who may assume a role, while access policies define what the role can do.
- How it shows up
- A login, Wi-Fi or service-to-service access failure is described with an error or log, and you identify which IAM component is misconfigured.
- Common confusion
- Using OAuth as if it proves who the user is; OAuth delegates authorization, and OpenID Connect adds the identity token that authenticates the user.
3.2 Given a scenario, analyze requirements to enhance the security of endpoints and servers.Application control, EDR, privilege management, HIPS/HIDS, SELinux, browser isolation, MDM and attacker TTPs.
- What it means
- This objective covers application control, endpoint detection and response (EDR), event logging and monitoring, endpoint privilege management, attack surface monitoring and reduction, HIPS/HIDS, anti-malware, SELinux, host-based firewalls, browser isolation, configuration management and MDM technologies, analyzed against threat-actor TTPs such as injections, privilege escalation, credential dumping, unauthorized execution, lateral movement and defensive evasion.
- What to understand
- Match the control to the technique: application allow listing stops unauthorized execution, endpoint privilege management removes standing local admin rights that enable credential dumping, and EDR records process behavior so defensive evasion and lateral movement can be detected and contained. SELinux enforces mandatory access control on Linux, confining a compromised service to its policy even when it runs as root. Browser isolation executes web content remotely so exploits never reach the endpoint.
- How it shows up
- A scenario describes an attacker technique or a hardening requirement on a server or workstation and asks which endpoint control best addresses it.
- Common confusion
- Choosing anti-malware for fileless or living-off-the-land attacks that use legitimate binaries, where application control and EDR behavioral detection are the effective controls.
3.3 Given a scenario, troubleshoot complex network infrastructure security issues.Misconfigurations, IPS/IDS issues, observability, DNS and email security, TLS and PKI errors, DDoS and ACLs.
- What it means
- This objective covers network misconfigurations (configuration drift, routing and switching errors, insecure routing, VPN/tunnel errors); IPS/IDS rule misconfigurations, lack of rules, false positives and negatives, and placement; observability; DNS security including DNSSEC, DNS poisoning, sinkholing and zone transfers; email security with DKIM, SPF, DMARC and S/MIME; TLS errors, cipher mismatch, PKI issues and cryptographic implementation issues; DoS/DDoS and resource exhaustion; and network ACL issues.
- What to understand
- IPsec tunnels fail when the two peers' phase 1 or phase 2 proposals, pre-shared keys or traffic selectors do not match, and TLS handshakes fail when client and server share no protocol version or cipher suite. ACLs are processed top-down with first match winning and an implicit deny at the end, so a broad permit above a specific deny silently overrides it. DNSSEC lets resolvers verify that records are signed by the zone, which defeats cache poisoning, while unrestricted zone transfers (AXFR) hand an attacker the whole zone.
- How it shows up
- A connectivity or detection failure is described with logs, rule sets or packet details, and you choose the misconfiguration or the corrective change.
- Common confusion
- Blaming the IDS signature when the sensor is placed where it cannot see the traffic, such as outside the TLS termination point or on the wrong segment.
3.4 Given a scenario, implement hardware security technologies and techniques.Roots of trust, coprocessors, SEDs, Secure Boot, measured boot, tamper protection, hardware TTPs, OT, IoT and embedded.
- What it means
- This objective covers roots of trust (TPM, HSM, vTPM); security coprocessors such as CPU security extensions and secure enclaves; virtual hardware; host-based encryption; self-encrypting drives; Secure Boot; measured boot; self-healing hardware; tamper detection and countermeasures; hardware-targeted TTPs (firmware tampering, shimming, USB-based attacks, BIOS/UEFI, memory, EMI, EMP); and security considerations for OT, SCADA, ICS, HVAC, IoT, system-on-chip, embedded systems and wireless/RF.
- What to understand
- Secure Boot enforces: UEFI firmware checks signatures on the boot loader and refuses unsigned code. Measured boot records: each stage is hashed into TPM platform configuration registers so a remote verifier can attest the boot chain, without blocking anything locally. A TPM protects keys for one device, an HSM provides high-assurance key storage and cryptographic operations for many systems, and a vTPM gives virtual machines TPM functions backed by the hypervisor.
- How it shows up
- A scenario asks how to prove device integrity to a network access or Zero Trust system, protect keys, or defend firmware and embedded devices from physical and supply chain tampering.
- Common confusion
- Believing Secure Boot provides remote attestation; it blocks unsigned code locally, while measured boot with TPM quotes lets another system verify what booted.
3.5 Given a set of requirements, secure specialized and legacy systems against threats.Security and privacy considerations, sector-specific challenges and legacy or constrained characteristics.
- What it means
- This objective covers security and privacy considerations for specialized systems; industry-specific challenges in utilities, transportation, healthcare, manufacturing, financial and government/defense sectors; and the characteristics of specialized and legacy systems that are unable to be secured, obsolete, unsupported or highly constrained.
- What to understand
- When a system cannot be patched, upgraded or fitted with agents, the controls move around it: strict segmentation, allow-listed communication paths, protocol-aware monitoring, jump hosts for administration and compensating controls documented against risk. In OT and medical environments, safety and availability usually outrank confidentiality, so active scanning or forced reboots can be the wrong answer. Highly constrained devices may only support lightweight cryptography or none, which shifts protection to the network.
- How it shows up
- A requirements list describes an unsupported controller, a certified medical device or a constrained sensor, and you choose the protection that respects its limits.
- Common confusion
- Proposing to patch or install EDR on a device whose vendor certification or resources forbid it, instead of isolating and monitoring it.
3.6 Given a scenario, use automation to secure the enterprise.Scripting, triggers, IaC, configuration formats, APIs and webhooks, generative AI, patching, SOAR and SCAP.
- What it means
- This objective covers scripting with PowerShell, Bash and Python; cron and scheduled tasks; event-based triggers; infrastructure as code; configuration files in YAML, XML, JSON and TOML; cloud APIs and SDKs; webhooks; generative AI for code assist and documentation; containerization; automated patching; auto-containment; SOAR runbooks and playbooks; vulnerability scanning and reporting; SCAP components (OVAL, XCCDF, CPE, CVE, CVSS); and workflow automation.
- What to understand
- Scheduled tasks run on time, while event-based triggers and webhooks react the moment something happens, which is what auto-containment needs. In SCAP, XCCDF expresses the checklist or benchmark, OVAL expresses the machine-checkable tests, CPE names the platforms, CVE identifies vulnerabilities and CVSS scores them. A runbook is a set of procedural steps often automated for a specific task, and a playbook coordinates the broader response to a type of incident.
- How it shows up
- A scenario shows a script, configuration file or automation goal and asks which automation approach, trigger or SCAP component fits.
- Common confusion
- Mixing up OVAL and XCCDF; XCCDF is the benchmark document, and OVAL defines the specific checks it references.
3.7 Explain the importance of advanced cryptographic concepts.Post-quantum cryptography, key stretching and splitting, homomorphic encryption, forward secrecy, envelope encryption, SMPC, AEAD.
- What it means
- This objective covers post-quantum cryptography (PQC), including post-quantum versus Diffie-Hellman and elliptic curve cryptography, resistance to quantum decryption attacks and emerging implementations; key stretching; key splitting; homomorphic encryption; forward secrecy; hardware acceleration; envelope encryption; performance versus security; secure multiparty computation; authenticated encryption with associated data (AEAD); and mutual authentication.
- What to understand
- A large quantum computer running Shor's algorithm would break RSA, Diffie-Hellman and ECC, so data recorded today can be decrypted later; this harvest-now, decrypt-later risk is why NIST standardized ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures in 2024. Symmetric ciphers are weakened less, so AES-256 remains acceptable. Envelope encryption encrypts data with a data key and wraps that key with a master key held in a KMS or HSM, and AEAD modes such as AES-GCM provide confidentiality and integrity in one operation.
- How it shows up
- A scenario states a long-term confidentiality need, a need to process encrypted data, or a performance limit and asks which cryptographic concept addresses it.
- Common confusion
- Assuming forward secrecy protects against quantum attack; ephemeral Diffie-Hellman keys limit damage from a stolen long-term key but the exchange itself is still breakable by a quantum computer.
3.8 Given a scenario, apply the appropriate cryptographic use case and/or technique.Use cases across data states, email, non-repudiation, sanitization, authentication, provenance and key management, and the matching techniques.
- What it means
- This objective covers use cases including data at rest, in transit (encrypted tunnels) and in use, secure email, immutable databases and blockchain, non-repudiation, privacy applications, legal and resource considerations, data sanitization and anonymization, certificate-based and passwordless authentication, software provenance and integrity, and centralized versus decentralized key management; and techniques including tokenization, code signing, cryptographic erase, digital signatures, obfuscation, serialization, hashing, one-time pad, symmetric, asymmetric and lightweight cryptography.
- What to understand
- Pick the technique by the property needed: digital signatures give integrity, authentication and non-repudiation, while a hash alone gives integrity only if the hash itself is protected. Cryptographic erase sanitizes encrypted media instantly by destroying the key, which suits SEDs and cloud volumes. Tokenization replaces a value with a surrogate whose mapping lives in a vault, reducing compliance scope, and lightweight cryptography such as the NIST-selected Ascon family suits constrained devices.
- How it shows up
- A scenario names a business goal such as proving who approved a transaction, sanitizing leased cloud storage or reducing PCI scope, and you choose the technique that satisfies it.
- Common confusion
- Choosing symmetric encryption or a plain hash for non-repudiation, when only an asymmetric digital signature ties an action to one key holder.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Kerberos and SAML clock skew
Kerberos tickets and SAML assertions carry timestamps and validity windows, and receivers reject them when clocks disagree beyond the allowed skew, five minutes by default for Kerberos.
- Remember
- Intermittent authentication failures limited to one site or host often trace to NTP rather than credentials.
- Tested as
- IAM troubleshooting items frequently hide a time problem behind an authentication error message.
- Trap
- Resetting passwords or reissuing certificates when the logs point to expired or not-yet-valid tickets or assertions.
-
OAuth vs. OpenID Connect vs. SAML
OAuth 2.0 delegates authorization through access tokens, OpenID Connect adds an ID token to authenticate users on top of OAuth, and SAML exchanges XML assertions for browser-based federated SSO.
- Remember
- If the requirement is to know who the user is, OAuth alone is not enough; use OIDC or SAML.
- Tested as
- Federation and API access scenarios ask which protocol meets authentication versus delegated access needs.
- Trap
- Selecting OAuth for user authentication into a web app because it appears in a login flow.
-
802.1X components
In 802.1X the supplicant on the device requests access, the authenticator (switch or wireless access point) relays EAP messages, and the authentication server, usually RADIUS, makes the decision.
- Remember
- EAP-TLS requires certificates on both the client and the server, and both must chain to trusted CAs.
- Tested as
- Network access failures after a certificate change are classic troubleshooting items.
- Trap
- Troubleshooting the switch port when the RADIUS server rejected an expired client certificate.
-
Secure Boot vs. measured boot
Secure Boot verifies signatures and blocks untrusted boot components, while measured boot hashes each component into TPM registers for later attestation.
- Remember
- Enforcement is local with Secure Boot; proof to a remote party requires measured boot plus a TPM quote.
- Tested as
- Zero Trust and NAC posture scenarios that need to verify boot integrity from elsewhere expect measured boot with attestation.
- Trap
- Selecting Secure Boot alone when the requirement is for a server to verify the endpoint's boot state.
-
TPM vs. HSM vs. vTPM
A TPM is a per-device chip for key protection and attestation, an HSM is a dedicated high-assurance appliance or service for key management and cryptographic operations at scale, and a vTPM provides TPM functions to virtual machines.
- Remember
- Certificate authority keys and payment keys belong in an HSM, while device identity and disk keys sit in the TPM.
- Tested as
- Root-of-trust questions ask which component fits the scale and assurance requirement.
- Trap
- Using a server's TPM to protect an enterprise CA signing key that requires HSM-grade controls and redundancy.
-
SCAP components
SCAP combines XCCDF benchmarks, OVAL test definitions, CPE platform names, CVE identifiers and CVSS scores so tools can check and report configuration and vulnerability status consistently.
- Remember
- XCCDF is the checklist, OVAL is the test logic, CPE says which platform, CVE names the flaw and CVSS rates it.
- Tested as
- Automation questions ask which SCAP component defines the checks or identifies the platform.
- Trap
- Calling CVSS a vulnerability identifier rather than a severity scoring system.
-
Event-based triggers and auto-containment
Event-based triggers and webhooks start automation when a condition occurs, such as an EDR alert, rather than on a schedule.
- Remember
- Containment that must happen within seconds of detection needs event-driven automation, often a SOAR playbook isolating the host.
- Tested as
- Automation scenarios contrast hourly scheduled scripts with immediate response needs.
- Trap
- Choosing a cron job, which leaves a gap of up to the full interval before action is taken.
-
Harvest now, decrypt later
Adversaries record encrypted traffic today and store it until a cryptographically relevant quantum computer can break the public-key exchange that protected it.
- Remember
- Data that must stay confidential for many years needs post-quantum or hybrid key establishment now, because recorded sessions cannot be re-protected later.
- Tested as
- Long-term confidentiality scenarios expect migration to PQC key exchange such as ML-KEM.
- Trap
- Relying on larger RSA keys or ECDHE forward secrecy, which a quantum computer still defeats.
-
Envelope encryption
Data is encrypted with a unique data encryption key, and that key is encrypted by a key encryption key held in a KMS or HSM.
- Remember
- Rotating the master key only requires rewrapping small data keys, not re-encrypting all the data.
- Tested as
- Cloud and large-scale storage scenarios ask how to rotate keys efficiently or keep master keys out of applications.
- Trap
- Encrypting all data directly with the master key, which forces full re-encryption at rotation and exposes the key widely.
-
Homomorphic encryption vs. secure multiparty computation
Homomorphic encryption lets a party compute on ciphertext without decrypting it, while secure multiparty computation lets several parties jointly compute a result without revealing their individual inputs.
- Remember
- One untrusted processor handling your encrypted data suggests homomorphic encryption; several organizations pooling private data suggests SMPC.
- Tested as
- Data-in-use privacy scenarios ask which technique allows processing without exposure.
- Trap
- Assuming either is free; both carry heavy performance costs, which is the performance versus security trade-off the outline names.
-
AEAD
Authenticated encryption with associated data provides confidentiality and integrity together and also authenticates unencrypted associated data such as headers.
- Remember
- AES-GCM and ChaCha20-Poly1305 are AEAD modes, and reusing a nonce with the same key breaks their security.
- Tested as
- Questions about protecting both payload secrecy and header integrity point to AEAD.
- Trap
- Using AES-CBC without a separate MAC and assuming integrity is provided.
-
Cryptographic erase
Cryptographic erase sanitizes media by destroying the encryption key so the remaining ciphertext is unrecoverable.
- Remember
- It is fast and works where physical destruction or overwriting is impractical, such as SEDs and cloud volumes, provided all data was encrypted from the start.
- Tested as
- Sanitization scenarios for leased hardware or cloud exit expect crypto erase.
- Trap
- Choosing overwriting for SSDs or cloud storage, where wear leveling and abstraction leave remnants.
-
Digital signature for non-repudiation
A digital signature is created with the signer's private key over a hash of the data and verified with the public key.
- Remember
- Only asymmetric signatures bound to a single key holder give non-repudiation; shared symmetric keys and HMACs cannot.
- Tested as
- Transaction approval and code integrity questions test which technique proves origin.
- Trap
- Choosing an HMAC because it provides integrity and authentication, missing that both parties hold the same key.
-
Compensating controls for legacy systems
Compensating controls achieve a security objective by other means when the primary control cannot be applied to a system.
- Remember
- Isolate the system, restrict and monitor its communication paths, control administrative access and document the residual risk.
- Tested as
- Specialized and legacy system questions nearly always resolve to isolation plus monitoring.
- Trap
- Forcing an unsupported upgrade that breaks a certified or safety-critical function.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SAML vs. OAuth 2.0 vs. OpenID Connect vs. Kerberos
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SAML | XML-based assertions exchanged between an identity provider and a service provider | Browser-based federated SSO, common for enterprise SaaS | Ignoring assertion timestamps and signing certificate rollover when troubleshooting |
| OAuth 2.0 | Delegated authorization framework issuing access tokens to clients | Grants a client access to resources; does not define user identity | Using it alone as an authentication protocol |
| OpenID Connect | Identity layer on OAuth 2.0 that adds a signed ID token | Authenticates the user for web and mobile apps using JSON-based tokens | Thinking it replaces OAuth rather than extending it |
| Kerberos | Ticket-based authentication using a key distribution center inside a domain | On-premises SSO for domain resources, sensitive to time and service principal names | Overlooking clock skew or SPN misconfiguration as the cause of failures |
Secure Boot vs. measured boot vs. self-encrypting drive
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Secure Boot | UEFI checks signatures of boot components against trusted keys | Prevents unsigned code from loading | Expecting it to report boot state to a remote verifier |
| Measured boot | Each boot stage is hashed into TPM platform configuration registers | Produces evidence for remote attestation but does not block | Assuming it stops a tampered boot loader by itself |
| Self-encrypting drive | Drive hardware encrypts all data with a media key | Protects data at rest when the drive is lost or retired, and supports crypto erase | Treating it as protection for a running, unlocked system |
Homomorphic encryption vs. secure multiparty computation vs. tokenization
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Homomorphic encryption | Computation performed directly on encrypted data | A single untrusted party processes data it cannot read | Ignoring its significant performance overhead |
| Secure multiparty computation | Several parties compute a joint function without revealing inputs | Collaboration across organizations with private data | Confusing it with simply sharing encrypted files |
| Tokenization | Sensitive value replaced by a surrogate with mapping in a secure vault | Removes the real value from downstream systems, reducing compliance scope | Expecting analytics on token values to reflect the real data |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Credentials blamed for a time problem
- What candidates pick
- Resetting the user's password or reissuing the IdP certificate after 'ticket not yet valid' or assertion errors.
- Why it looks right
- Authentication failures look like credential failures.
- Why it's wrong
- Kerberos and SAML reject tickets and assertions whose timestamps fall outside the allowed skew, so the root cause is clock drift and the fix is NTP.
Clue to watch for Errors mention validity, expiry or 'not yet valid', or failures are limited to one host or site.
-
Secure Boot for remote verification
- What candidates pick
- Enabling Secure Boot so the NAC server can confirm laptops booted cleanly.
- Why it looks right
- Secure Boot is the best-known boot integrity control.
- Why it's wrong
- Secure Boot enforces locally and does not produce evidence for another system; remote verification requires measured boot with TPM-signed quotes and an attestation service.
Clue to watch for The requirement says another system must verify, attest or prove the boot state.
-
Forward secrecy against quantum
- What candidates pick
- Enforcing ECDHE cipher suites to protect recorded traffic from future quantum decryption.
- Why it looks right
- Forward secrecy is the standard answer for protecting past sessions.
- Why it's wrong
- Forward secrecy protects against later theft of a long-term key, but elliptic curve Diffie-Hellman itself is breakable by a quantum computer, so recorded exchanges remain exposed without PQC key establishment.
Clue to watch for The scenario mentions long-term confidentiality, nation-state collection or quantum computing.
-
Scheduled script for urgent containment
- What candidates pick
- A cron job that checks EDR alerts every hour and isolates infected hosts.
- Why it looks right
- It automates the task with simple, familiar tooling.
- Why it's wrong
- A schedule leaves up to an hour for spread; containment needs an event-based trigger or SOAR playbook that acts when the alert fires.
Clue to watch for Requirements such as 'immediately', 'within seconds' or 'before lateral movement'.
-
Patching the unpatchable
- What candidates pick
- Upgrading the operating system on a certified medical imaging workstation to fix a vulnerability.
- Why it looks right
- Patching is the standard remediation for known vulnerabilities.
- Why it's wrong
- Changing a certified or unsupported system can void certification or break safety functions; the expected answer isolates it, restricts its traffic and monitors it as a compensating control.
Clue to watch for Words such as 'vendor-certified', 'unsupported', 'cannot be modified' or 'safety-critical'.
-
HMAC for non-repudiation
- What candidates pick
- Adding an HMAC to approval messages so the approver cannot deny sending them.
- Why it looks right
- HMAC provides integrity and authenticates the sender to the receiver.
- Why it's wrong
- Both sides share the HMAC key, so either could have produced the value; only a digital signature with the approver's private key provides non-repudiation.
Clue to watch for The requirement is proof to a third party, such as an auditor or court, of who performed an action.
-
Wrong layer for a TLS failure
- What candidates pick
- Opening firewall ports after clients report handshake failures with a newly hardened server.
- Why it looks right
- Connection failures often come from blocked ports.
- Why it's wrong
- If the TCP connection completes and the handshake fails, the cause is TLS: no shared protocol version or cipher suite, or an untrusted or incomplete certificate chain.
Clue to watch for Logs show 'handshake failure', 'no shared cipher' or 'unknown CA' after a hardening change.
Answer framework
For Domain 3 troubleshooting and implementation questions, let the exhibit's technical detail drive the answer.
- Read the log, error or configuration first and note the exact failure point, such as time validity, certificate trust, cipher negotiation or rule order.
- Identify the layer and component involved, separating identity, network, host, hardware and cryptographic causes before considering fixes.
- Choose the fix that corrects the root cause with the smallest change, rather than replacing the technology or weakening security to restore service.
- When a system cannot be changed, shift controls around it with segmentation, monitoring and restricted administrative access, and document residual risk.
- For cryptographic choices, match the technique to the exact property required, such as non-repudiation, data in use, long-term confidentiality or constrained resources.
Practice question
Want more like this? The SecurityX practice test has questions for every domain.
Checklist
0 of 15
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Because this domain carries the largest weight, give it the most study time and split it into three blocks. Start with identity (3.1) and network troubleshooting (3.3), since they produce the most symptom-driven questions. Build small labs if you can: break a Kerberos login with clock skew, misconfigure an IPsec proposal, or disable a TLS cipher, and read the resulting errors until you recognize them on sight.
Next cover hardware and endpoints (3.4, 3.2) together with specialized and legacy systems (3.5). Draw the boot chain from firmware to operating system and mark where Secure Boot enforces and where measured boot records. Practice deciding what protects a device that cannot be patched.
Finish with automation and cryptography (3.6, 3.7, 3.8). Read short scripts and YAML files, map each SCAP component to its job, and make a table of cryptographic requirements against techniques. Post-quantum cryptography and data-in-use techniques are the most commonly underestimated topics. Afterwards, practice performance-based troubleshooting items and review each miss by finding the line in the exhibit that held the answer.
FAQ
Why is Security Engineering the largest SecurityX domain?
It is weighted at 31% because it covers the broadest technical ground, eight objectives spanning identity, endpoints, networks, hardware, legacy systems, automation and cryptography. CompTIA publishes the weight but not a per-domain question count.
Will I have to read logs or scripts?
Expect to. Several objectives use the verbs troubleshoot and use automation, so exhibits such as authentication errors, firewall rules, certificate details or short scripts and configuration files are a natural fit for scenario and performance-based items.
How much post-quantum cryptography do I need?
Know why quantum computing threatens RSA, Diffie-Hellman and ECC but only weakens symmetric ciphers, what harvest-now, decrypt-later means, and that NIST's 2024 standards are ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures.
What is the difference between Secure Boot and measured boot?
Secure Boot blocks boot components that are not signed by a trusted key. Measured boot records hashes of each component in the TPM so a remote service can verify the boot chain, which is what device attestation needs.
How do I approach OT and legacy questions?
Assume the device cannot be changed and that safety and availability come first. The strongest answers isolate the system, restrict its communications, monitor it with protocol-aware tools and document compensating controls.
Is this domain harder than Security Architecture?
It is broader and more detailed, while architecture is more about judgment. Many candidates find engineering harder to memorize but easier to answer once they know the technology, because the exhibit usually points to one correct cause.
How does Domain 3 connect to the other domains?
It implements and fixes what Security Architecture designs, and it builds the hardened, automated and instrumented systems that Security Operations monitors and investigates.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CISSP Same subject: Domain 3: Security Architecture and Engineering (13%)
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 3 knowledge
You have covered IAM troubleshooting, endpoint and network hardening, hardware roots of trust, legacy systems, automation and advanced cryptography. Practice reading exhibits and picking the root cause under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the SecurityX AI tutor Get any concept explained your way