Security Architecture Patterns and Models

Last updated: April 29, 2026

A Mumbai fintech CTO designed each new system from scratch. Authentication, authorisation, logging, secrets management — every project re-invented the patterns. Quality varied wildly, security gaps proliferated, audit findings repeated. The security architect she hired in 2024 introduced reference architectures: pre-approved patterns each new project starts from. Within a year, security debt stopped accumulating. This module covers security architecture patterns as a practitioner discipline.

What architecture patterns are

Reference architectures encode known-good designs. Instead of every team designing authentication from scratch, they pick the appropriate authentication pattern from the catalogue. Quality is consistent; security review is faster; the team can focus on business logic.

The pattern catalogue (sample)

Authentication patterns

• OIDC + PKCE for first-party web apps
• OIDC client credentials for service-to-service
• SAML federation for B2B SSO
• FIDO2 / passkey for high-value accounts

Authorisation patterns

• RBAC — role-based, simple, suits well-defined hierarchies
• ABAC — attribute-based, fine-grained, complex policies
• ReBAC — relationship-based, suits social / sharing systems
• OPA (Open Policy Agent) — externalised policy engine

Secrets management patterns

• HashiCorp Vault docs for dynamic secrets, leasing, rotation
• AWS Secrets Manager / Azure Key Vault for cloud-native
• Workload identity (IRSA, AKS workload identity) — no static secrets

Service-to-service patterns

• mTLS with workload identity — strong service authentication
• JWT bearer — when mTLS is impractical
• Service mesh (Istio, Linkerd) — declarative; offload auth to platform

Logging patterns

• Structured logs (JSON) shipped to centralised SIEM
• Audit log per security-sensitive action — separate from app logs
• Correlation IDs across distributed services

Encryption patterns

• TLS 1.2+ for all in-transit; 1.3 preferred
• AES-256-GCM for at-rest
• Customer-managed keys (CMK / BYOK) for regulated workloads
• Envelope encryption with KMS for large datasets

The reference architecture document

For each pattern, document:

• When to use it — situations where this pattern is appropriate
• When NOT to use it — anti-patterns or alternatives
• Reference implementation — code examples, IaC modules
• Common pitfalls — what teams typically get wrong
• Dependencies — what other patterns / services it requires
• Compliance mapping — which regulatory controls it satisfies

The Mumbai fintech’s catalogue

Started with 12 patterns covering 80% of common use cases. Each engineering team was required to either pick from the catalogue or document a deviation justification. Security review for catalogue-compliant designs took 1 day; deviations took 2 weeks. Strong incentive alignment.

Within a year:

• New projects shipped with security baseline already correct
• Security architect’s time freed from reactive review to proactive new-pattern development
• Audit findings on inconsistent implementations dropped 80%
• Security debt accumulation reversed

Beyond patterns — the architecture review board

For deviations or new patterns, an architecture review board meets weekly:

• Engineering lead, Security architect, Senior engineer rotating, Compliance representative
• Reviews proposed deviations, decides yes / no / suggest alternative
• Approves new patterns to add to catalogue
• Documented decisions provide governance trail

Indian compliance mapping

• RBI Cyber Framework — security architecture review expected
• SEBI CSCRF — security architecture documented for Q-RE / MII
• ISO 27001:2022 A.5.7-A.5.10, A.8.25-A.8.34 — secure design controls
• DPDP §10 — for SDF, DPIA references architecture decisions

Common mistakes

• Patterns documented but unenforced — teams free-style anyway
• Patterns too rigid — forces awkward fits for legitimate edge cases
• No reference implementations — teams interpret patterns differently
• No deviation process — teams either fake compliance or skip
• No update cadence — patterns from 2020 don’t reflect 2026 reality

Try this in your organisation

1. Pick three new projects from the last year. How does each authenticate users? Are they using the same pattern?
2. How do they handle secrets? Same?
3. If different, why? Each variation is a security-debt source.
4. The catalogue is your remedy.

Security architecture patterns convert “everyone designs from scratch” into “everyone starts from a known-good baseline.” The investment is documenting + enforcing; the payoff is consistent security across an engineering organisation that scales.