Roadmap
Security Architect
The senior security professional who designs the organization's security architecture, translating business requirements and threat models into security standards, reference architectures, and technical patterns that engineering teams implement across infrastructure, applications, cloud, and identity.
OPTIMISTIC 8–10 years · REALISTIC 10–12 years
Stage 00
Complete Security Engineering Foundation (Prerequisite)
Security architects design systems that security engineers then build. Deep security engineering depth across all domains is the prerequisite.
Required: Senior Security Engineering Depth
- Complete IT fundamentals — networks, systems, identity, cloud
- Threat modeling depth — STRIDE, attack trees, trust boundary analysis
- Detection engineering — SIEM, SOAR, SIGMA rules at practitioner level
- Cloud security engineering — AWS, Azure, and/or GCP at implementation level
- Vulnerability management — scanning, prioritization, remediation program design
- Scripting and automation — Python and PowerShell for security automation
- Security operations — incident investigation, threat hunting, forensic basics
- Identity and access management — all protocols, PAM, IGA at design level
Additional Technical Breadth Required
- Software development awareness — understanding how developers build applications; SDLC phases; CI/CD pipelines; reviewing code for security issues
- Database security — encryption at rest and in transit; access control; audit logging; SQL injection prevention at the database layer
- Cryptography depth — symmetric/asymmetric at implementation level; PKI design; TLS configuration; key management (HSMs, KMS); certificate lifecycle management; common cryptographic failures and their consequences
- Hardware security — TPM, HSM, secure enclaves; BIOS/UEFI security; physical security intersection
- OT/ICS awareness — industrial control systems; SCADA; different security posture for operational technology
Architecture Skills Prerequisites
- Diagramming — Lucidchart, draw.io, Visio; architecture diagram conventions
- Technical writing — design documents, architecture decision records (ADRs), standards documents
- System design — distributed systems concepts; reliability, scalability, availability
- Requirements analysis — translating business needs into technical requirements
Stage 01
Architecture Frameworks and Methodology
Security architects work within enterprise architecture frameworks. Understanding how security fits into the broader EA context is foundational.
TOGAF (The Open Group Architecture Framework)
- What TOGAF is — the most widely adopted EA framework; 73% of Fortune 500 required
- Architecture Development Method (ADM) — the iterative cycle for creating EA: - Preliminary — establishing the architecture capability and governance - Phase A: Architecture Vision — business case; sponsor; high-level scope - Phase B: Business Architecture — business processes; organization; requirements - Phase C: Information Systems Architecture — data architecture; application architecture - Phase D: Technology Architecture — infrastructure; network; platforms - Phase E: Opportunities and Solutions — transition planning; work packages - Phase F: Migration Planning — detailed migration roadmap - Phase G: Implementation Governance — oversight of implementation - Phase H: Architecture Change Management — managing changes; triggering new cycle - Requirements Management — running through all phases
- Architecture artifacts — Architecture Building Blocks (ABBs), Solution Building Blocks (SBBs)
- Enterprise Continuum — organizing reusable architecture assets; Foundation → Common Systems → Industry → Organization
- TOGAF and security — security is woven through each ADM phase; security architect participates in Phases B through D
- TOGAF certification — Foundation (Part 1) + Practitioner (Part 2); The Open Group administered
SABSA (Sherwood Applied Business Security Architecture)
- What SABSA is — purpose-built security architecture methodology; business-risk-driven
- Six SABSA layers — derived from Zachman Framework; applied to security: - Business layer — Why? (business drivers, risk, policy) - Architect layer — What? (security services, information assets) - Designer layer — How? (security mechanisms and controls) - Builder layer — With what? (technology, products) - Tradesman layer — When and where? (deployment, configuration) - Facility Management — operational management
- SABSA matrix — six columns (What, How, Where, Who, When, Why) × six rows (Contextual through Component)
- Business Attributes profile — security requirements expressed in business terms (confidentiality → "protect competitive intelligence")
- Trust model — how trust is established, measured, and maintained
- SABSA certification levels — Foundation → Practitioner → Master
- SABSA vs TOGAF use cases: - TOGAF: broad EA needing security woven in; common in enterprises running formal EA - SABSA: security-first design; CISOs needing to justify security to business; financial/government contexts
Zachman Framework
- Two-dimensional classification matrix — Who, What, When, Where, Why, How × Contextual through Component
- Not a methodology but a taxonomy — organizes architecture artifacts
- Security application — mapping security controls across all cells
- Value for architects — ensuring completeness; no orphaned controls; every control has a business justification
Security Reference Architectures
- NIST SP 800-207 Zero Trust Architecture — the authoritative ZTA reference
- NIST SP 800-64 Security Considerations in SDLC — secure development lifecycle architecture
- NIST SP 800-125B Secure Virtual Network Configuration — virtualization security
- NIST Cybersecurity Framework 2.0 — governance-through-recovery reference
- DoD Zero Trust Strategy — federal implementation guidance; relevant for DoD contractors
- Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) — cloud security controls catalog
- OWASP Application Security Verification Standard (ASVS) — application security architecture requirements
- CIS Controls — 18 controls ordered by implementation priority; v8
Architecture Decision Records (ADRs)
- What ADRs are — lightweight documentation of architecture decisions with context and consequences
- ADR format: - Title — short name of decision - Status — proposed, accepted, deprecated, superseded - Context — the forces in play; why a decision is needed - Decision — what was decided - Consequences — what happens as a result; trade-offs accepted
- Why ADRs matter — future engineers understand why the architecture is the way it is; prevents revisiting settled decisions
- Security-specific ADRs — documenting security design choices; recording risk acceptance
Resources
- TOGAF Standard (The Open Group, documentation available)
- SABSA Foundation materials
- NIST SP 800-207 (free)
- "Security Architecture: How and Why" by Ross Anderson (book)
Stage 02
Security Patterns and Reference Architecture
Security architects produce reusable patterns and reference architectures. Learning established patterns prevents reinventing solutions to solved problems.
Fundamental Security Patterns
- Defense in depth — multiple independent layers of security; no single point of failure
- Security by design vs security by obscurity — design-time security vs hiding implementation
- Fail secure vs fail open — default to secure state on failure
- Least privilege — minimum access for the minimum necessary time
- Separation of duties — preventing single actor from controlling entire sensitive process
- Segregation of duties — operational division preventing conflicts of interest
- Audit logging — every security-relevant event recorded; tamper-evident; retained appropriately
- Non-repudiation — cryptographic proof of actions; digital signatures; audit trails
Network Architecture Patterns
- DMZ (Demilitarized Zone): - Classic three-tier: Internet → Firewall → DMZ (web servers) → Firewall → Internal - Modern multi-tier: separate DMZ per security zone; application, data, management zones - Jump servers / bastion hosts — secure administrative access point to internal systems - Proxy architecture — forward proxy for egress control; reverse proxy for ingress inspection
- Network segmentation patterns: - VLAN-based — Layer 2 isolation; common in campus and legacy environments - Firewall zone-based — perimeter, internal, DMZ, management zones - Microsegmentation — application-aware; east-west traffic control; Illumio, VMware NSX - Zero Trust Network Access (ZTNA) — identity-based access to applications; no network-level trust
- Zero Trust Architecture patterns (NIST SP 800-207): - Identity-centric ZTA — IdP is the policy decision point; every request authenticated and authorized - Device-centric ZTA — device posture checked before access - Micro-perimeters — protect individual resources rather than network segments - Software-defined perimeter (SDP) — dynamically provisioned per-application access - ZTNA vendors — Zscaler Private Access, Palo Alto Prisma Access, Cloudflare Access, Cisco Duo
Identity Architecture Patterns
- Identity provider (IdP) — central source of truth for identities; Okta, Entra ID, Ping
- Federated identity — SAML, OIDC enabling SSO across organizational boundaries
- Privileged access management architecture — just-in-time access; session recording; credential vaulting
- Non-human identity architecture — service accounts; managed identities; workload identity; secrets management
- Decentralized identity — FIDO2 passkeys; verifiable credentials; growing standard for passwordless
Application Security Architecture
- Input/output trust model — never trust input; always encode output
- Authentication architecture — choosing authentication schemes appropriate to risk; MFA requirements
- Authorization architecture — RBAC vs ABAC; decision architecture (centralized policy engine vs embedded checks)
- Secrets management architecture — no hardcoded secrets; vault integration; secret rotation
- API security architecture — authentication (OAuth 2.0), rate limiting, WAF, API gateway
- Microservices security — service mesh for mTLS; service identity; API gateway pattern
- Multi-tenant SaaS architecture — tenant isolation; data partitioning; per-tenant encryption; admin boundaries
Cloud Security Architecture Patterns
- Landing zone architecture — standardized, secure AWS/Azure/GCP account/subscription structure - AWS: Organizations structure; SCPs; CloudTrail; Config; GuardDuty; SecurityHub at org level - Azure: Management groups; Azure Policy; Microsoft Defender for Cloud at tenant level - GCP: Resource hierarchy; Organization policies; SCC at organization level
- Hub-and-spoke network — centralized network security (firewall, DNS, monitoring) in hub; workloads in spokes
- Security reference architectures by cloud provider: - AWS Security Reference Architecture (AWS SRA) — published by AWS; comprehensive multi-account design - Azure Landing Zones — Microsoft CAF (Cloud Adoption Framework) security baseline - Google Cloud Security Blueprint
- Data classification and protection architecture: - Data classification tiers — public, internal, confidential, restricted - Protection controls per tier — encryption, access control, monitoring, retention - Data Loss Prevention (DLP) architecture — endpoint, network, cloud DLP; policy design
DevSecOps Architecture
- Secure SDLC integration — security at each phase: requirements, design, implementation, testing, deployment, operations
- Pipeline security gates: - Pre-commit: secrets detection (GitLeaks, truffleHog) - PR stage: SAST (Semgrep, CodeQL), SCA (Snyk, Dependabot) - Build: container image scan (Trivy) - Pre-deploy: IaC scan (Checkov, tfsec), DAST - Runtime: RASP, WAF, cloud security monitoring
- Software supply chain security: - SLSA framework (Supply-chain Levels for Software Artifacts) — build provenance; tamper resistance - SBOM (Software Bill of Materials) — SPDX and CycloneDX formats - Artifact signing — Sigstore, Cosign — provenance for container images - Dependency management — private registries; version pinning; dependency confusion prevention
Resources
- NIST SP 800-207 (free)
- AWS Security Reference Architecture (free)
- Microsoft Azure Well-Architected Framework security pillar (free)
- CSA CCM (free)
- "Security Engineering" by Ross Anderson (book, seminal reference)
Stage 03
Threat Modeling at Architecture Scale
Security architects lead threat modeling for the entire organization, not just individual features.
Enterprise Threat Modeling
- Organization-wide threat model — what assets does the organization have? What adversaries target them? What are their capabilities?
- Threat landscape alignment — mapping internal architecture to external threat intelligence
- Crown jewels analysis — identifying the most critical assets; designing proportional protection
- Attack surface management — continuous visibility into exposed attack surface; discovering shadow IT, public-facing assets, third-party exposures
- Business continuity architecture — resilience by design; redundancy; graceful degradation
Architecture-Level STRIDE
- Applying STRIDE at the system and enterprise level rather than individual feature level
- Trust boundary mapping — every internal and external trust boundary documented
- Data flow analysis at enterprise scale — PII, financial data, operational data flows
- Adversary-centric architecture review — "how would a sophisticated attacker approach our architecture?"
Threat Intelligence for Architects
- Translating CTI into architecture decisions — if APTs target VPN concentrators, what does our VPN architecture look like?
- Threat modeling for AI systems: - MITRE ATLAS — AI-specific adversary tactics and techniques - OWASP LLM Top 10 — AI application security considerations - Prompt injection, model poisoning, training data extraction architecture responses
- Third-party risk architecture — designing vendor access that limits blast radius
Architecture Review Process
- Security architecture review (SAR) — formal review of major technical initiatives - When to require: new systems, major changes to existing systems, new third-party integrations, cloud migrations - Review process: submit design document → security review → findings → remediation → approval - Review checklist: authentication, authorization, data classification, encryption, logging, resilience, supply chain
- Reference architecture compliance — comparing proposed designs against approved patterns
- Architecture exceptions — formal process for deviating from standards; risk acceptance; compensating controls
Resources
- MITRE ATLAS (free)
- Adam Shostack "Threat Modeling" (book)
- SAFECode security guidance (free)
Stage 04
Zero Trust Architecture Design
Zero Trust is the primary architecture paradigm of 2026. Security architects must be able to design ZTA implementations from first principles.
Zero Trust Principles (NIST SP 800-207)
- Verify explicitly — authenticate and authorize based on all available data points
- Use least privilege access — limit user access with JIT and JEA; limit data access
- Assume breach — minimize blast radius; segment access; verify end-to-end encryption; use analytics to get visibility and drive threat detection and improve defenses
ZTA Components
- Policy Decision Point (PDP) — evaluates access requests against policy; issues access decisions
- Policy Enforcement Point (PEP) — enforces PDP decisions; blocks or allows traffic
- Policy Engine (PE) — core logic component that makes trust decisions
- Policy Administrator (PA) — establishes/tears down communication paths
ZTA Deployment Models
- Device-based ZTA — device posture as primary trust signal; MDM compliance; certificate authentication
- Identity-based ZTA — identity + MFA as primary trust signals; ZTNA for application access
- Micro-segmented ZTA — network microsegmentation; application-aware access control
- Service Mesh ZTA — mTLS between all services; Istio; Linkerd; every service authenticates
ZTA Implementation Roadmap
- Phase 1: Identity — enforce MFA everywhere; deploy SSO; implement PIM for privileged access
- Phase 2: Devices — MDM deployment; device compliance as access condition; certificate-based auth
- Phase 3: Applications — ZTNA replacing VPN; application-level access control; SSO for all apps
- Phase 4: Data — data classification; DLP; rights management; encryption of sensitive data
- Phase 5: Network — microsegmentation; removing implicit trust zones; east-west inspection
- Phase 6: Visibility — SIEM; UEBA; continuous monitoring; automated response
ZTA Vendor Landscape
- Identity providers with Conditional Access — Okta + Zscaler; Microsoft Entra ID + Defender; CrowdStrike Identity
- ZTNA solutions — Zscaler Private Access (ZPA), Palo Alto Prisma Access, Cloudflare Access, Netskope, Cisco Duo
- Microsegmentation — Illumio, VMware NSX, Akamai Guardicore
- CASB (Cloud Access Security Broker) — Zscaler, Netskope, Microsoft Defender for Cloud Apps; shadow IT discovery; data protection
Resources
- NIST SP 800-207 (free)
- CISA Zero Trust Maturity Model (free)
- John Kindervag's ZTA blog (free, the original ZTA architect)
Stage 05
Executive Communication and Architecture Leadership
Security architects must present designs to executive leadership, evaluate risk in business terms, and drive organizational alignment.
Architecture Communication
- Architecture artifacts for different audiences: - Executive summary (1 page) — what we're building, why it matters, what the risk is - Architecture overview (5–10 pages) — design rationale, components, dependencies, security controls - Technical design document (20+ pages) — full implementation detail for engineering teams - Architecture decision record — individual decision with full context and trade-offs
- Presenting to leadership — security in business risk language; financial framing; regulatory context
- Board-level security architecture briefing — risk landscape; investment priorities; program maturity
Architecture Governance
- Architecture Review Board (ARB) — ensuring architecture decisions align with standards
- Security standards maintenance — versioned policy documents; review cycles; waiver process
- Technology radar — tracking emerging technologies; adoption guidance; phasing out legacy
- Security roadmap — multi-year architecture evolution; prioritized by risk and business impact
- Metrics for architecture effectiveness: - Compliance rate with security standards - Time to security architecture review completion - Reduction in security findings from architecture reviews over time
Architecture Portfolio
- Building a body of work that demonstrates architecture capability: - Reference architectures produced - Architecture reviews completed - Standards authored and adopted - Major security programs designed - Vendor evaluations led
Resources
- Gartner security architecture research (free analyst blogs)
- ISC2 Security Architecture community
- "CISO Desk Reference Guide" (book)
Stage 06
Hands-On Practice & Portfolio
Building Architecture Capability
- Architecture review practice — volunteer to lead security reviews for projects at your organization
- Reference architecture development — creating reusable security patterns for specific use cases
- Standard development — proposing and drafting security standards for specific technologies
- Threat model facilitation — leading threat modeling sessions for major initiatives
- Vendor evaluation — leading security evaluations of security tools
What to Document on LabList
- Architecture artifacts portfolio — reference architectures, threat models, design reviews (sanitized)
- Standards and guidelines authored — security standards for specific technologies or use cases
- Zero trust design — documented ZTA design for a realistic organization scenario
- Architecture decision records — examples showing design choices, trade-offs, and risk acceptance
- Cert progression — CISSP → CCSP → SABSA Foundation → TOGAF documented with depth
FAQ
Common questions
How long does it take to become a Security Architect?
8–10 years optimistic, 10–12 years realistic. Security architecture is a senior role that compounds technical depth, design pattern fluency, and cross-organizational leadership. Most security architects come from senior security engineer or principal engineer backgrounds with documented architecture decision-making. The path doesn't shortcut — pattern languages and reference architectures are built through years of seeing what works and what fails.
Which certifications matter for security architecture?
CISSP is listed in 80% of security architect postings. SABSA Foundation is the purpose-built security architecture methodology. TOGAF for enterprise architecture overlap. CCSP for cloud-heavy roles. CISSP-ISSAP for senior architect specialization. Compensation reflects seniority — average $110K–$220K+, total comp reaching $161K–$505K for verified profiles.
Do I need a specific degree?
Most security architects hold a bachelor's, often in CS or engineering. Master's degrees help in some enterprise contexts. The role values demonstrated architecture decision-making over academic credentials at the senior level — what reference architectures have you authored, what major decisions have you owned, what tradeoffs have you negotiated.
What separates a hired Security Architect?
Reference architecture artifacts. Hiring panels probe specific architectures you've designed — what were the constraints, what tradeoffs did you make, what failed and how did you recover. Generic 'I designed security' responses don't compete. Other differentiators: SABSA depth, threat modeling at scale, multi-cloud architecture experience, and demonstrated cross-functional negotiation skills. Principal/Chief Security Architect roles pay $195K–$300K+.