SY0-801 — CompTIA Security+ V8 Exam Blueprint
A practical readiness checklist for CompTIA Security+ V8 (SY0-801) topic review, scenario decisions, weak areas, and final-week preparation.
How to Use This Exam Blueprint
Use this independent Exam Blueprint as a readiness map for CompTIA Security+ V8 (SY0-801) from CompTIA. It is not a claim about exact official weighting, scoring, or item counts. Treat each section as a practical audit of what you should be able to recognize, explain, compare, and apply in scenario-based questions.
For each row or checkbox, mark your status:
| Mark | Meaning | What to do next |
|---|---|---|
| ✅ | Ready | Keep it warm with mixed practice. |
| ⚠️ | Partial | Review the concept, then answer scenario questions. |
| ❌ | Weak | Relearn the topic and write your own examples. |
A strong SY0-801 candidate should be able to choose the best control for the situation, not just define terms.
Topic-area readiness map
| Readiness area | Be ready to explain | Be ready to do in a scenario |
|---|---|---|
| Security principles | CIA triad, AAA, least privilege, defense in depth, secure defaults, zero trust concepts, privacy, nonrepudiation | Choose controls that protect confidentiality, integrity, or availability based on the business impact described. |
| Threat actors and motivations | Nation-state, insider, hacktivist, organized crime, script kiddie, shadow IT, supply-chain risk | Infer likely actor, objective, and attack path from clues such as persistence, data theft, sabotage, or financial fraud. |
| Social engineering and human risk | Phishing, spear phishing, whaling, vishing, smishing, pretexting, tailgating, shoulder surfing, invoice fraud | Pick awareness, verification, reporting, MFA, and process controls that reduce human-targeted attacks. |
| Malware and endpoint threats | Ransomware, worms, Trojans, rootkits, spyware, keyloggers, fileless malware, living-off-the-land techniques | Identify containment priorities and decide whether EDR, isolation, restore, or forensic preservation is most appropriate. |
| Network attacks | Spoofing, poisoning, on-path attacks, DDoS, replay, session hijacking, rogue AP, evil twin, DNS attacks | Match symptoms to controls such as segmentation, secure protocols, DNS security, NAC, IDS/IPS, WAF, or rate limiting. |
| Application and API security | Injection, XSS, CSRF, SSRF, insecure deserialization, directory traversal, insecure direct object references, weak session management | Select parameterized queries, input validation, output encoding, secure cookies, API authentication, and secure SDLC practices. |
| Vulnerability management | Asset inventory, scanning, severity, prioritization, patching, compensating controls, exceptions, false positives | Prioritize remediation using exploitability, exposure, asset value, business impact, and change risk. |
| Identity and access management | Authentication, authorization, accounting, MFA, SSO, federation, RBAC, ABAC, DAC, MAC, PAM, account lifecycle | Choose access controls for users, admins, service accounts, third parties, devices, and applications. |
| Cryptography and PKI | Symmetric vs asymmetric encryption, hashing, salting, digital signatures, certificates, CAs, key management, TLS | Decide when to encrypt, hash, sign, rotate keys, revoke certificates, or fix trust-chain errors. |
| Network architecture | Firewalls, proxies, VPNs, ZTNA, DMZs, VLANs, subnetting concepts, microsegmentation, secure DNS, wireless security | Place controls correctly and determine which traffic should be allowed, denied, inspected, logged, or isolated. |
| Cloud and virtualization security | Shared responsibility, IAM, storage exposure, workload isolation, container basics, serverless concepts, image security, cloud logging | Identify whether the customer, provider, or configuration owner must fix the issue. |
| Mobile, IoT, embedded, and OT | MDM, device posture, BYOD, kiosk mode, firmware, default credentials, segmentation, safety constraints | Recommend controls when devices cannot be patched quickly or cannot tolerate downtime. |
| Security operations | SIEM, SOAR, EDR/XDR, log aggregation, alert triage, baselines, playbooks, escalation, threat intelligence | Interpret alerts and choose the next step: validate, contain, eradicate, recover, document, or tune. |
| Incident response and forensics | Preparation, detection, analysis, containment, eradication, recovery, lessons learned, chain of custody, evidence handling | Avoid destroying evidence when the scenario requires legal, regulatory, or forensic preservation. |
| Resilience and recovery | Backups, restore testing, RTO, RPO, redundancy, failover, disaster recovery, business continuity | Match recovery strategy to business tolerance for downtime and data loss. |
| Governance, risk, and compliance | Policies, standards, procedures, guidelines, risk treatment, audits, data classification, privacy, vendor risk | Choose appropriate administrative controls and risk responses based on business requirements. |
Can you do this?
Security concepts and control selection
- Distinguish confidentiality, integrity, and availability from scenario wording.
- Identify whether a control is administrative, technical, or physical.
- Identify whether a control is preventive, detective, corrective, deterrent, compensating, or recovery-focused.
- Explain least privilege, need to know, separation of duties, job rotation, and mandatory vacations.
- Recognize when defense in depth is needed instead of relying on one control.
- Apply secure by design, secure defaults, and fail secure reasoning.
- Explain how zero trust changes assumptions about network location, identity, device posture, and continuous verification.
- Choose between reducing risk, transferring risk, accepting risk, and avoiding risk.
- Recognize when the best answer is a process control, not a tool.
Threats, attacks, and vulnerabilities
| Attack or weakness | Common cue | Readiness check |
|---|---|---|
| Phishing | Urgent message, link, attachment, credential request | Can you choose awareness, reporting, email filtering, DMARC-style controls, and MFA? |
| Business email compromise | Payment redirection, executive impersonation, vendor invoice change | Can you choose out-of-band verification and payment workflow controls? |
| Ransomware | Files encrypted, ransom note, lateral spread, backup targeting | Can you prioritize isolation, scope, evidence, eradication, and clean restore? |
| Credential stuffing | Many login attempts using known passwords | Can you choose MFA, rate limiting, password screening, monitoring, and account protection? |
| Password spraying | Few common passwords across many accounts | Can you distinguish it from brute force against one account? |
| Privilege escalation | Standard user gains admin rights | Can you identify patching, least privilege, PAM, EDR, and hardening controls? |
| Lateral movement | New remote sessions, admin shares, unusual service creation | Can you pick segmentation, credential protection, monitoring, and containment? |
| SQL injection | User input changes database query behavior | Can you select parameterized queries and input validation over only filtering at the perimeter? |
| XSS | Script executes in a user’s browser | Can you distinguish reflected, stored, and DOM-based symptoms at a high level? |
| CSRF | Authenticated user is tricked into submitting an action | Can you choose anti-CSRF tokens and SameSite cookie protections? |
| SSRF | Server is tricked into making requests | Can you recognize access to metadata services or internal-only resources? |
| Directory traversal | ../-style path manipulation | Can you choose canonicalization, access checks, and input validation? |
| DNS poisoning | Users resolve a name to the wrong host | Can you choose secure DNS practices, monitoring, and cache protection? |
| ARP spoofing | Local network traffic redirected through attacker | Can you choose segmentation, inspection, and secure switching features? |
| Evil twin AP | User connects to attacker-controlled wireless network | Can you choose certificate-based wireless authentication and user awareness? |
| DDoS | Service unavailable from traffic flood | Can you choose upstream filtering, rate limiting, CDN/scrubbing, and resilience? |
| Supply-chain compromise | Trusted vendor/update/package is malicious | Can you choose vendor due diligence, code signing, SBOM-style review, and monitoring? |
| Data exfiltration | Large outbound transfer, unusual destination, compressed archives | Can you choose DLP, egress filtering, logging, classification, and investigation? |
Identity and access management
- Distinguish authentication, authorization, and accounting.
- Compare MFA factors: something you know, have, are, do, or somewhere you are.
- Recognize strong MFA patterns, including phishing-resistant approaches.
- Choose between RBAC, ABAC, DAC, and MAC based on the scenario.
- Explain just-in-time access, privileged access management, and break-glass accounts.
- Identify risks of shared accounts, dormant accounts, orphaned accounts, and overprivileged service accounts.
- Apply joiner-mover-leaver logic to provisioning, modification, and deprovisioning.
- Explain why access reviews and recertification reduce privilege creep.
- Know when to use federation or SSO instead of creating another local password database.
| Technology or protocol | Best-readiness explanation |
|---|---|
| SAML | Commonly used for browser-based enterprise federation and SSO assertions. |
| OAuth 2.0 | Delegated authorization, often allowing an app to access resources without sharing the user password. |
| OpenID Connect | Identity layer built on OAuth 2.0 concepts for authentication claims. |
| Kerberos | Ticket-based authentication commonly associated with enterprise domain environments. |
| LDAP / LDAPS | Directory access and queries; LDAPS protects LDAP traffic. |
| RADIUS | AAA commonly used for network access such as VPN and wireless authentication. |
| TACACS+ | AAA often associated with network device administration. |
| FIDO2 / WebAuthn | Strong, phishing-resistant authentication using public key methods. |
| PAM | Controls, monitors, and limits privileged access. |
Cryptography, PKI, and secrets
| Concept | Can you distinguish it from… | Scenario readiness |
|---|---|---|
| Hashing | Encryption and encoding | Use for integrity checks and password storage when combined with salt and appropriate password hashing. |
| Encryption | Hashing and signing | Use for confidentiality of data at rest or in transit. |
| Digital signatures | Encryption alone | Use for integrity, authenticity, and nonrepudiation. |
| Symmetric encryption | Asymmetric encryption | Understand speed and shared-key management tradeoffs. |
| Asymmetric encryption | Symmetric encryption | Understand public/private key roles, exchange, and signing use cases. |
| Certificates | Keys alone | Validate identity through issuer trust, subject/SAN, validity period, and chain. |
| PKI | A single certificate | Understand CA, RA, CSR, certificate chain, revocation, renewal, and trust stores. |
| Salting | Hashing alone | Prevent identical passwords from producing identical stored hashes. |
| Key rotation | Password reset | Limit long-term exposure from compromised or aging secrets. |
| HSM / TPM | General storage | Protect keys or device secrets using dedicated hardware-backed mechanisms. |
Can you handle these certificate scenarios?
- The certificate is expired.
- The certificate name does not match the service name.
- The client does not trust the issuing CA.
- An intermediate certificate is missing.
- A private key is exposed.
- A self-signed certificate is used where public trust is expected.
- A revoked certificate is still being accepted.
- A wildcard certificate creates broader exposure than intended.
Network security and architecture
| Design decision | Better answer pattern |
|---|---|
| Internet-facing application | Put public entry points in a controlled segment; avoid direct database exposure. |
| Database access | Allow only required application tiers or admin paths; deny broad inbound access. |
| Administrative access | Use MFA, PAM, bastion/jump hosts, logging, and least privilege. |
| Guest wireless | Segment from internal resources; apply captive portal or policy controls as needed. |
| Remote access | Use strong authentication, device posture, encryption, monitoring, and least privilege. |
| East-west traffic | Use segmentation or microsegmentation rather than assuming internal traffic is trusted. |
| OT or safety-critical network | Prioritize segmentation, monitoring, allowlisting, and planned maintenance windows. |
| High-risk outbound traffic | Use egress filtering, proxying, DNS filtering, DLP, and alerting. |
| Inline blocking | IPS or firewall-like control where prevention is required and latency/availability are acceptable. |
| Passive detection | IDS, network sensors, taps, or span ports when observation is required without inline blocking. |
Protocol recognition matters, but do not rely on port number alone. Be ready to combine port, protocol, service banner, encryption state, and business context.
| Common service cue | Readiness check |
|---|---|
| SSH | Secure remote administration; investigate exposure to the internet. |
| RDP | Remote desktop access; high-value target for brute force and lateral movement. |
| DNS | Name resolution; consider poisoning, tunneling, filtering, and logging. |
| HTTP / HTTPS | Web traffic; inspect TLS, headers, authentication, and WAF placement. |
| SMTP / mail submission | Email flow; consider phishing controls, relay abuse, and authentication records. |
| SMB | File sharing; consider lateral movement, access control, and patching. |
| LDAP / LDAPS | Directory queries; prefer protected transport where credentials or sensitive data are involved. |
| SNMP | Device monitoring; avoid weak community strings and unnecessary exposure. |
| NTP | Time sync; important for logs, certificates, Kerberos-style authentication, and investigations. |
Cloud, virtualization, and container security
- Explain shared responsibility without assuming the provider secures customer misconfigurations.
- Identify public storage exposure, excessive IAM permissions, and missing logging as cloud risks.
- Apply least privilege to users, roles, service principals, workloads, and automation.
- Recognize risks in images, registries, secrets, container runtime permissions, and host escape paths.
- Choose segmentation, security groups, network ACLs, private endpoints, and workload isolation based on the scenario.
- Explain why encryption, key management, monitoring, and backup configuration still require customer decisions.
- Recognize when infrastructure as code needs review, version control, scanning, and change approval.
- Distinguish vulnerability in a container image from a runtime attack or orchestrator misconfiguration.
- Recognize overexposed management consoles, APIs, metadata services, and automation credentials.
- Apply governance through tagging, policy, logging, asset inventory, and configuration monitoring.
Application, API, and secure SDLC readiness
| If the scenario says… | Think about… |
|---|---|
| User input changes application behavior | Input validation, output encoding, parameterized queries, secure parsing. |
| A session token is stolen | Secure cookies, TLS, token lifetime, session invalidation, device/session monitoring. |
| An API exposes another user’s record | Authorization checks, object-level access control, least privilege. |
| Secrets are found in source code | Secret scanning, vaulting, rotation, developer training, pre-commit controls. |
| A new release introduces vulnerabilities | Secure SDLC, code review, SAST, DAST, dependency scanning, change control. |
| A dependency has a known vulnerability | Inventory, version review, patching, compensating controls, supply-chain assessment. |
| Production data is used in testing | Data masking, anonymization, synthetic data, access control. |
| A WAF blocked one attack | Treat it as defense in depth, not a replacement for fixing vulnerable code. |
Can you explain these secure development terms?
- SAST versus DAST.
- Dependency scanning versus manual code review.
- Fuzzing versus vulnerability scanning.
- Threat modeling versus penetration testing.
- Secure coding standard versus runtime control.
- DevSecOps automation versus after-the-fact security review.
- API gateway versus WAF versus reverse proxy.
- Code signing versus encryption.
Security operations and monitoring
| Artifact | What you should infer |
|---|---|
| Firewall log | Source, destination, port/service, action, direction, rule hit, unusual deny/allow pattern. |
| IDS/IPS alert | Signature or behavior, severity, affected host, confidence, false-positive possibility. |
| EDR alert | Process tree, parent-child process relationship, command line, persistence, network connection. |
| Authentication log | Success/failure pattern, source location, impossible travel, lockouts, MFA prompts. |
| Web server log | Method, path, status code, user agent, referrer, suspicious parameters. |
| DNS log | Rare domains, algorithmic-looking names, tunneling patterns, suspicious TXT queries. |
| Proxy log | User, destination, category, upload/download size, blocked or allowed status. |
| Cloud audit log | Identity, API call, source, resource changed, permission used, region/location. |
| Vulnerability scan | Asset, detected weakness, severity, evidence, remediation, possible false positive. |
| SIEM correlation | Multiple low-level events combined into a higher-confidence alert. |
Useful command and artifact awareness:
nmap -sV 203.0.113.10
ss -tulpn
netstat -ano
dig TXT example.test
openssl s_client -connect app.example.test:443 -servername app.example.test
journalctl -u ssh
Be ready to explain what information a command can reveal, not just memorize syntax.
| Command or output type | Exam-relevant interpretation |
|---|---|
nmap service scan | Open services, banners, unexpected exposure, possible version risk. |
ss / netstat | Listening services, established connections, process association. |
dig / DNS lookup | DNS record type, mail/security records, suspicious resolution. |
openssl s_client | Certificate chain, presented name, issuer, TLS connection details. |
| Windows logs | Authentication, process, policy, service, and security-relevant event patterns. |
| Linux auth logs | SSH attempts, sudo usage, privilege changes, account activity. |
| Web logs | Injection attempts, scanning, brute force, unusual user agents, error patterns. |
Scenario decision-point checks
| Scenario | Strong decision path | Common wrong turn |
|---|---|---|
| A user reports a suspicious email after clicking a link | Preserve message, identify scope, check authentication logs, reset credentials if needed, block indicators, educate user | Only deleting the email from one mailbox |
| A single endpoint shows ransomware behavior | Isolate host, preserve evidence as required, identify scope, stop spread, eradicate, restore from clean backup | Immediately reimage without checking lateral movement or evidence needs |
| Cloud storage is publicly accessible | Remove public access, review IAM/policies, check logs for access, rotate exposed secrets, classify data, notify per process | Only enabling encryption after data was already exposed |
| A web app is vulnerable to SQL injection | Fix code with parameterized queries, validate input, test, monitor, use WAF as layered control | Treating WAF as the only remediation |
| Admin credentials are reused across systems | Implement unique privileged accounts, PAM, MFA, rotation, logging, least privilege | Only changing the password once |
| A critical OT device cannot be patched | Segment, restrict access, monitor, allowlist, plan maintenance, use compensating controls | Forcing an untested patch that risks safety or availability |
| A vendor handles sensitive data | Perform due diligence, define contractual controls, classify data, monitor access, review audit evidence | Assuming outsourcing transfers all accountability |
| A certificate warning appears for users | Check name, validity, chain, trust store, revocation, private key handling | Telling users to bypass the warning |
| Multiple failed logins across many accounts | Suspect password spraying, tune detection, enforce MFA, check source, consider lockout strategy | Treating it as one user forgetting a password |
| A developer commits a secret | Revoke/rotate secret, remove from history as appropriate, scan repositories, add prevention controls | Only deleting the visible line from the current file |
Risk, recovery, and calculation checks
Know these relationships when a question gives you the needed values.
\[ \mathrm{SLE} = \mathrm{Asset\ Value} \times \mathrm{Exposure\ Factor} \]\[ \mathrm{ALE} = \mathrm{SLE} \times \mathrm{Annualized\ Rate\ of\ Occurrence} \]\[ \mathrm{Availability} = \frac{\mathrm{MTBF}}{\mathrm{MTBF} + \mathrm{MTTR}} \]| Term | What it means for decision-making |
|---|---|
| Asset value | What the organization stands to lose if the asset is affected. |
| Exposure factor | Portion of asset value lost in one event. |
| SLE | Expected loss from one occurrence. |
| ARO | Expected frequency of occurrence in a year. |
| ALE | Expected annual loss estimate. |
| Inherent risk | Risk before controls. |
| Residual risk | Risk remaining after controls. |
| Risk appetite | Amount of risk the organization is willing to accept. |
| RTO | Maximum tolerable time to restore service. |
| RPO | Maximum tolerable data loss measured in time. |
| MTBF | Reliability indicator: average time between failures. |
| MTTR | Maintainability/recovery indicator: average time to repair or restore. |
Can you answer these without guessing?
- If the RPO is short, do backups or replication need to be more frequent?
- If the RTO is short, is a cold standby likely sufficient?
- If residual risk remains above appetite, should more treatment be considered?
- If a control costs more than the expected annualized loss, is it automatically justified?
- If a critical asset is internet-facing and exploitable, should severity be adjusted upward?
- If a vulnerability is severe but not reachable, how does exposure affect prioritization?
Governance, policy, and compliance readiness
| Artifact or concept | What to know | Scenario cue |
|---|---|---|
| Policy | High-level management intent | “Employees must protect confidential data.” |
| Standard | Mandatory specific requirement | “Passwords must meet defined complexity or length rules.” |
| Procedure | Step-by-step instructions | “Follow these steps to provision access.” |
| Guideline | Recommended practice | “Consider using this secure configuration.” |
| Baseline | Approved minimum configuration | “All laptops must use the standard hardening image.” |
| Data classification | Labeling based on sensitivity and handling needs | Public, internal, confidential, restricted-style categories. |
| Data retention | How long data is kept and when disposed | Legal, business, privacy, and storage considerations. |
| Acceptable use | Permitted and prohibited use of systems | Employee behavior and device/network use. |
| Change management | Controlled review and approval of changes | Patching, firewall rules, application releases. |
| Vendor risk management | Third-party due diligence and monitoring | Outsourced processing, SaaS, managed services. |
| Security awareness | Human-risk reduction | Phishing reporting, password hygiene, data handling. |
| Audit | Evidence-based review of control operation | Logs, access reviews, configuration evidence. |
Risk response readiness:
| Response | Choose it when… |
|---|---|
| Avoid | The organization stops the risky activity. |
| Transfer | Insurance, contract, or outsourcing shifts some financial or operational impact. |
| Mitigate | Controls reduce likelihood or impact. |
| Accept | Leadership knowingly accepts the residual risk. |
| Share | Risk responsibility is distributed with another party, often through partnership or contract. |
Common weak areas and traps
- Confusing authentication with authorization.
- Choosing encryption when the scenario needs hashing.
- Choosing hashing when the scenario needs confidentiality.
- Treating encoding as a security control equivalent to encryption.
- Assuming internal network traffic is automatically trusted.
- Forgetting that least privilege applies to service accounts and automation, not just humans.
- Choosing a technical tool when the scenario asks for governance, policy, or process.
- Misreading RTO as data loss and RPO as downtime.
- Assuming backups solve ransomware without restore testing, isolation, and clean recovery points.
- Choosing immediate eradication when the question emphasizes evidence preservation.
- Treating vulnerability scanning and penetration testing as the same activity.
- Treating a vulnerability score as the only prioritization factor.
- Assuming a cloud provider is responsible for customer IAM, data classification, and exposed storage settings.
- Confusing SAML, OAuth 2.0, and OpenID Connect.
- Confusing IDS visibility with IPS inline prevention.
- Treating SIEM as the tool that fixes incidents rather than correlates and alerts.
- Ignoring certificate name mismatch, chain trust, and revocation clues.
- Selecting “most secure” when the scenario asks for “most appropriate” or “best business fit.”
- Forgetting safety and availability constraints in OT, medical, industrial, or embedded environments.
- Choosing to patch immediately without considering testing, change windows, or compensating controls.
Final-week checklist
7 to 5 days out
- Revisit every ⚠️ and ❌ item in this checklist.
- Build a one-page map of your weakest acronyms and protocols.
- Practice mixed scenario questions instead of studying one topic at a time only.
- Review wrong answers by writing why the correct answer is better, not just why your answer was wrong.
- Drill IAM, cryptography, incident response, cloud misconfiguration, and risk scenarios.
- Practice interpreting small log snippets, command outputs, and alert summaries.
4 to 2 days out
- Redo missed questions from prior practice without looking at notes first.
- Review control categories: administrative, technical, physical; preventive, detective, corrective.
- Review authentication and federation differences.
- Review certificate lifecycle and TLS troubleshooting cues.
- Review secure application control selection: validation, encoding, parameterization, authentication, authorization.
- Review RTO, RPO, SLE, ALE, residual risk, and risk treatment.
- Review incident response order and when evidence preservation changes the next step.
Day before
- Stop deep-diving new topics unless they are high-confidence quick wins.
- Skim your acronym list and weak-topic notes.
- Review scenario words such as first, best, most likely, most secure, most cost-effective, and next.
- Prepare exam logistics and identification requirements separately from content study.
- Sleep enough to read carefully and avoid rushing.
Exam-day mindset
- Read the last sentence of the question carefully.
- Identify the asset, risk, constraint, and desired outcome.
- Eliminate answers that are true but do not solve the stated problem.
- Prefer the control that directly addresses the root cause.
- Watch for business constraints: cost, downtime, safety, compliance, and operational impact.
- If two answers seem right, choose the one that best matches the phase: prevention, detection, containment, eradication, recovery, or governance.
Practical next step
Turn this checklist into a two-column study log: weak topic and proof of readiness. For each weak topic, complete targeted review, then answer enough mixed practice questions to prove you can apply the concept in unfamiliar scenarios for CompTIA Security+ V8 (SY0-801).