Security is an architectural property, not a feature you bolt on
later. These ten concepts shape how a system stays defensible as
threats evolve, dependencies change, and the team scales.
10 concepts·~12 min read·Updated 2026
How to read this guide
Each concept follows the same shape: the threat or weakness it
addresses, the architectural response, and the failure modes when
it's bolted on instead of designed in. The "When it fits"
line at the end is the scope where each one earns its keep.
Saltzer & Schroeder: The principle of least
privilege. Every program and every user should operate with the
minimum set of privileges necessary to complete the job. Fifty
years on, this is still the principle most often violated.
01
Zero Trust
Never trust, always verify — including inside the network.
Problem
Castle-and-moat security assumes the network perimeter is the security boundary. One compromised host inside, and the attacker has free movement.
Shape
Treat every request as untrusted regardless of origin. Authenticate and authorize each call. Use mTLS between services. Make device trust, user identity, and request context part of every authorization decision — and re-evaluate continuously, not just at session start. NIST SP 800-207 is the canonical reference: a Policy Decision Point evaluates each request, a Policy Enforcement Point gates the call.
Watch for
Zero trust is an architectural commitment, not a product. Bolt-on solutions (a "zero trust gateway") help at the edge but don't fix east-west traffic.
When it fits:
Modern distributed systems, especially with employees on personal
devices, partner integrations, or sensitive data. The model that
survives a breach.
02
Defense in Depth
Multiple overlapping controls — no single layer is the only line of defense.
Problem
Any single security control will eventually fail or be bypassed. If it's the only one, the failure becomes a breach.
Shape
Layer controls so that compromising one doesn't compromise the system. Network controls + identity controls + application controls + data controls. Each operates independently; each catches what the others miss.
Watch for
Layers that share a failure mode aren't really independent. WAF + network ACL + TLS all dependent on cert validity isn't depth, it's three locks with the same key.
When it fits:
Any system with sensitive data or non-trivial threat model. The
default architectural posture for security-conscious teams.
03
Threat Modeling
Systematically identify what could go wrong, before it does.
Problem
Security ad-hoc misses the threats specific to your system. Generic checklists catch generic issues but miss the architecture-specific ones.
Shape
Walk through the system. For each component and trust boundary, apply STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). Document threats and mitigations.
Watch for
Threat modeling becomes a one-time exercise that goes stale. Re-do it when the architecture changes — new dependencies, new data flows, new trust boundaries.
When it fits:
New systems, major refactors, integrations with external parties.
The output drives security work; without it, you're guessing.
04
Authentication Flows
OAuth 2.0, OIDC, and the difference between sessions and tokens.
Problem
Rolling your own auth almost always introduces flaws. Even using libraries, the wrong flow choice can leak credentials or bypass MFA.
Shape
OAuth 2.0 is for authorization, not authentication — OIDC layers identity (login) on top, returning an ID token. Use Authorization Code with PKCE for every public client: SPA, mobile, and (per OAuth 2.1 / the IETF browser-based-apps BCP) confidential server-side clients too. Sessions for first-party web apps; bearer tokens for APIs. Add MFA, and prefer phishing-resistant factors — WebAuthn / passkeys — over TOTP where you can.
Watch for
Implicit and Resource Owner Password Credentials grants are removed in OAuth 2.1 — don't use them. Rotate refresh tokens (single-use), and consider sender-constrained tokens (DPoP or mTLS) for high-value APIs. Tokens in localStorage are vulnerable to XSS; httpOnly cookies are safer for web but require CSRF protection.
When it fits:
Anything with users. The flow choice depends on the client type
(browser, mobile, server, machine), not just convenience.
05
Authorization Models
RBAC, ABAC, ReBAC — and when each fits the access pattern.
Problem
Authorization isn't authentication. Knowing who someone is doesn't tell you what they're allowed to do, and the right model depends on how access actually works.
Shape
RBAC (role-based) — users have roles, roles have permissions. Simple, scales to medium org. ABAC (attribute-based) — policies use attributes (department, time, location). Flexible. ReBAC (relationship-based) — Zanzibar-style; powerful for collaborative apps. A policy engine (OPA/Rego, AWS Cedar) often pairs with ABAC to express and audit rules outside application code.
Watch for
Role explosion in RBAC happens fast at scale. ABAC policies become hard to debug. ReBAC needs a specialized service (SpiceDB, OpenFGA, Ory Keto) — not necessarily a graph database; most production implementations run on a standard relational store.
When it fits:
RBAC for internal tools and basic SaaS. ABAC for compliance-heavy
environments. ReBAC for collaborative products (docs, files, chat).
06
Encryption
At rest, in transit, in use — and key management is the hard part.
Problem
Plaintext at any layer is plaintext available to attackers. But encryption without key management is just obfuscation with extra steps.
Shape
TLS 1.3 for in-transit (1.2 only as a floor for legacy). Use authenticated encryption (AEAD: AES-GCM, ChaCha20-Poly1305) — never raw block-cipher modes like CBC without a separate MAC. Disk/database encryption for at-rest. KMS service for key storage and rotation. Envelope encryption for performance with large data. Plan for post-quantum: hybrid KEMs (e.g., X25519 + ML-KEM) are emerging as the migration path.
Watch for
Self-managed keys often end up checked into a repo. Rotation needs to be tested before you need it. Key derivation functions (KDFs) matter as much as the cipher choice.
When it fits:
Always for data in transit. At-rest encryption is mandatory for
regulated data and almost always free with managed services — turn
it on by default.
Secrets in environment files, repos, or images leak. Manual rotation is rare and error-prone. Stolen credentials and phishing top the breach reports year after year, and long-lived static secrets are the most preventable contributor.
Shape
Store secrets in a vault (Secrets Manager, Vault, Key Vault). Inject at runtime, never bake into images. Scope access — services see only what they need. Rotate automatically; revoke immediately on suspicion. Where you can, replace static secrets with workload identity / OIDC federation (GitHub Actions OIDC → AWS, SPIFFE/SPIRE for service-to-service) so credentials are short-lived and bound to the workload.
Watch for
Build-time secrets in Docker images (the layer cache will leak them). Logging that prints secrets. Service accounts with overly broad scopes outliving the service.
When it fits:
Every service with database credentials, API keys, or signing
material. Especially critical for production systems with
regulatory requirements.
Vulnerabilities arrive in code (your bugs), in dependencies (their bugs), and in build pipelines (compromised tooling). Each needs a different control.
Shape
SAST (static analysis) catches code-level issues at commit. DAST (dynamic) finds runtime issues against deployed apps. Dependency scanning flags known CVEs; secret scanning blocks credentials before they land. For supply-chain integrity, generate an SBOM, sign artifacts (Sigstore / cosign) and verify provenance attestations against the SLSA framework before promoting a build.
Watch for
Tool noise erodes signal — too many false positives and developers stop reading reports. Tune aggressively. Dependency updates without testing introduce their own risk.
When it fits:
Every codebase. The level of investment scales with risk profile,
but every team should have at least dependency scanning and basic
SAST in CI.
09
Audit & Compliance
Logging for accountability; mapping controls to regulatory frameworks.
Problem
Without audit logs, breach investigation is guesswork. Without compliance mapping, regulators decide what your controls were.
Shape
Log security-relevant events (auth, authz, admin actions, data access) to a tamper-evident store. Map controls to relevant frameworks (SOC 2, ISO 27001, HIPAA, PCI). Test the controls; don't just document them.
Watch for
Audit logs that anyone can modify aren't audit logs. Compliance theatre — passing the audit but not actually being secure — is common and dangerous.
When it fits:
Regulated industries (finance, healthcare, government). Also anyone
selling to enterprise — SOC 2 is table stakes for B2B SaaS.
10
Least Privilege
Grant the minimum access needed; revoke when unused.
Problem
Excessive privileges turn small mistakes into big incidents. Static permissions accumulate over time as people change roles and the org evolves.
Shape
Grant access just-in-time and just-enough. Use temporary credentials wherever possible. Review access regularly and revoke what isn't used. Default deny; explicit grant.
Watch for
Just-in-time without good ergonomics drives engineers to keep credentials around. Stale permissions are technical debt with security consequences.
When it fits:
Universal principle. Especially load-bearing for admin access,
service-to-service auth, and any path that touches production data.
Security compounds when designed in
Bolted-on security is the most expensive kind. Each control added
late conflicts with assumptions baked into the design — and the
retrofits create their own gaps for the next attacker to find.
Security designed in is invisible to users and cheap to maintain.
It survives the breach, the audit, and the team turnover. Pick the
principles above and apply them at the architecture stage, not the
compliance review.