Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust

Key Takeaways Explain This Topic AI

Least privilege grants only the access required for the task, for the required time, under the required conditions — scope, duration, accountability.

Defense in depth layers controls so the failure of one does not expose the whole environment.

Secure by design builds security into architecture and development from requirements, not as a bolt-on after deployment.

Zero trust removes implicit network trust and continuously verifies identity, device posture, context, and session risk.

SY0-701 frames zero trust as a Control Plane (policy engine, policy administrator) and Data Plane (policy enforcement point) — know the components.

Last updated: June 2026

Security Principles in Practice

Security principles guide control selection when every answer choice sounds plausible. They tell you which option reduces risk without creating excess access, single points of failure, or unverified trust — the three things SY0-701 distractors love to sneak in.

• Principle Practical meaning Scenario clue
• Least privilege Grant only required access "excess permissions", "temporary access", "admin rights"
• Defense in depth Use layered, independent controls "if one control fails", "multiple safeguards"
• Secure by design Build security in from the start "new application", "architecture review", "requirements"
• Zero trust Verify explicitly and continuously "no implicit trust", "device posture", "context-aware"
• Separation of duties Split sensitive tasks across roles "same person requests and approves"
• Fail secure Default to a protected state on failure "if the system fails, what should happen?"

Separation of duties is distinct from least privilege: least privilege limits one person's access, while separation of duties ensures no single person controls an entire sensitive transaction (for example, the requester of a payment cannot also approve it). A related control the exam may test alongside it is mandatory vacation or job rotation , both of which expose fraud that depends on one person continuously occupying a role. These principles are not interchangeable, and SY0-701 will offer them as competing answers to a fraud-prevention scenario specifically to check that you can tell them apart.

Least Privilege and Defense in Depth

A developer needs to troubleshoot a production app for one weekend. Least privilege is about scope, time, and accountability — not convenience.

• Weak answer Better answer
• Add developer to Domain Admins Grant scoped, just-in-time access for the approved window
• Share an administrator password Use a named account with MFA and logging
• Leave access in place "in case" Set an expiration and review after the work

Defense in depth assumes any single layer can fail. A public web app handling customer data layers independent controls so a single bypass does not equal compromise.

• Layer Example control
• Edge WAF, anti-DDoS, TLS
• Application Input validation, secure session management, code review
• Identity MFA for admins, RBAC, privileged access management
• Network Segmentation between web, app, and database tiers
• Data Encryption at rest, key management, database permissions
• Monitoring Centralized logs, alerts, file integrity monitoring
• Recovery Tested backups and documented restoration

If an attacker bypasses the WAF, segmentation and least-privilege database permissions still cap the damage. The exam rewards answers that add an independent layer over answers that strengthen one already-present layer.

A closely related principle is fail securely (also called fail-safe or fail-closed). When a control fails, the system should default to the protected state rather than the open one. A door lock that defaults to locked on a power outage protects assets but can endanger life safety, which is why physical egress often deliberately fails open — the exam expects you to recognize that fail-secure is the norm for data confidentiality but that human-safety controls may intentionally fail open.

Pairing defense in depth with fail-secure defaults is what keeps a single component failure from cascading into a full compromise, and questions often hinge on choosing the option that preserves protection when something breaks.

Secure by Design and Zero Trust

Secure by design means security requirements are written into a project before launch — threat modeling, RBAC, encryption, secure defaults, and logging are design decisions, not patches. Adding a WAF after go-live helps but never replaces secure input handling, authentication, authorization, and logging baked into the architecture.

Zero trust does not mean "block everything." It means no request is trusted merely because it originated inside the network. SY0-701 expects you to know its plane model:

• Component Plane Role
• Policy Engine (PE) Control plane Decides grant/deny using identity, device, and context
• Policy Administrator (PA) Control plane Establishes or tears down the session based on the PE decision
• Policy Enforcement Point (PEP) Data plane Actually allows or blocks the traffic to the resource

Supporting inputs include the Policy Decision Point concept, adaptive identity , threat scope reduction , and implicit trust zones that must be eliminated.

Common Traps

• Trap Better exam reasoning
• "Internal traffic is trusted" Zero trust requires explicit verification every time
• "One strong control is enough" Defense in depth expects layered failure resistance
• "Admin rights are faster" Least privilege favors scoped, time-bound access even under urgency
• "Security can be added later" Secure by design starts at requirements and architecture
• "Fail open is user friendly" For sensitive systems, fail secure (deny by default) is preferred

When a scenario pits usability against verification, the principle-driven answer almost always chooses verification with the least added friction — not the option that removes verification entirely.

To summarize the four flagship principles in one line each for rapid recall: least privilege limits how much access; defense in depth controls how many independent layers protect an asset; secure by design fixes when security enters the lifecycle (at the start); and zero trust changes whether location confers trust (it does not). When two principles seem to fit a scenario, ask which dimension the stem is really stressing — the amount of access, the number of layers, the timing of design, or the basis of trust — and the correct principle usually resolves immediately.