CSSLP · Secure Software Architecture and Design

Define the security architecture

Security architecture translates business objectives, security requirements, risk decisions, and operational constraints into an organized set of trust boundaries, components, interfaces, control responsibilities, and design rules.

Example: Establish system scope and context, identify assets, actors, data flows, and trust relationships, allocate control responsibilities, and document assumptions and residual risk.

Counterexample: Treat a product list or network diagram alone as a security architecture, which overstates what one safeguard can establish. | Assign all duties for security architecture to one component without checking gaps, duplication, or concentration risk, leaving control ownership unclear, while system-wide failure behavior remains unresolved. | Write implementation tasks for security architecture before agreeing on system context and trust boundaries, deferring architectural judgment.

Limitations: Do not treat a product list or network diagram alone as a security architecture.

Security architecture versus security design

Architecture defines the high-level structure, responsibilities, boundaries, and principles. Design refines those decisions into specific components, protocols, data structures, and interactions.

Example: Separate system-wide boundaries, responsibilities, and principles from the detailed components, protocols, data structures, and interactions that realize them.

Counterexample: Force a rigid boundary in which every decision is either architecture or design, despite their practical overlap, which overstates coverage. | Document the selected components but omit data flows, actors, assumptions, and failure propagation, leaving trust boundaries and control ownership unclear, while system-wide failure behavior remains unresolved. | Allow each component team to make independent security decisions without an allocated architecture, deferring an architecture decision to a later stage.

Limitations: Do not force an absolute boundary: architecture and design overlap, but architecture generally addresses system-wide structure and design addresses more detailed realization.

Architecture viewpoints and stakeholder concerns

A security architecture may use multiple viewpoints to address concerns of business owners, users, developers, operators, privacy personnel, assessors, and incident responders.

Example: Create complementary business, logical, application, deployment, operational, and assurance views that address each stakeholder’s security concerns.

Counterexample: Treat one preventive safeguard as complete coverage, leaving detection, containment, and recovery unaddressed, which overstates coverage. | Place the affected components on an internal network and treat location as sufficient trust, leaving ownership unclear. | Defer failure and recovery decisions until deployment, leaving degraded behavior undefined, deferring an architecture decision to a later stage, while system-wide failure behavior remains unresolved.

Secure architecture and design patterns

Patterns provide reusable approaches to recurring security problems. They capture context, forces, solution structure, consequences, and known trade-offs.

Example: Evaluate the pattern’s context, forces, assumptions, solution structure, consequences, and trade-offs before adopting it.

Counterexample: Assume a published pattern is secure in every context and adopt it without reviewing assumptions or trade-offs. | Reuse one identity and privilege model across distinct trust boundaries without reassessing context. | Rely on later penetration testing to compensate for missing architectural decisions, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Limitations: A pattern is not automatically secure in every context; assumptions and consequences must be evaluated.

SABSA

Sherwood Applied Business Security Architecture (SABSA) is a business-driven security architecture method that relates business requirements and risk to layered architectural views and traceable security services.

Example: Use SABSA to trace business requirements and risk through layered architecture views into accountable security services.

Counterexample: Describe SABSA as a single technical control or a product, which overstates coverage. | Optimize the initial deployment while omitting update, recovery, and support behavior, leaving ownership unclear, while system-wide failure behavior remains unresolved. | Select a product before identifying the requirements, assets, trust boundaries, and credible threats.

Limitations: Do not describe SABSA as a single technical control or a product.

Security chain of responsibility

A security chain of responsibility assigns related control duties across components or layers so each participant performs its part and accountability remains traceable.

Example: Assign each related control duty to a named component or team, document trust assumptions, and preserve end-to-end accountability across handoffs.

Counterexample: Allow shared control duties to remain ambiguous because several components participate in enforcement, which overstates what one safeguard can establish. | Select controls by familiarity rather than requirements, threats, dependencies, and risk reduction, leaving trust boundaries, control ownership, and failure behavior undefined. | Treat a deployment diagram as sufficient architecture without documenting responsibilities or assumptions, deferring a system-wide architecture decision to implementation or operations.

Limitations: Shared responsibility must not become ambiguous responsibility; each duty requires an owner and defined trust assumptions.

Federated identity architecture

Federated identity allows an application or security domain to rely on identity assertions from another trusted domain. Architecture must define trust establishment, assertion validation, audience restriction, key management, revocation, and failure behavior.

Example: Validate issuer, signature, audience, key status, and revocation, then apply local authorization rather than inheriting partner privileges.

Counterexample: Accept any correctly signed partner token without validating audience, issuer policy, or current keys, which overstates coverage. | Map partner groups directly to privileged local roles and skip application-specific authorization, leaving trust boundaries and control ownership unclear. | Keep long-lived federation sessions after partner revocation because authentication already occurred, deferring an architecture decision to a later stage.

Limitations: Federation does not mean universal trust or automatic authorization; authentication assertions still require local policy decisions.

Security controls identification and prioritization

Architects identify controls that address requirements and threats, then prioritize them according to risk reduction, mandatory obligations, dependencies, architectural leverage, implementation cost, and operational impact.

Example: Select controls that address requirements and threats, then prioritize mandatory duties, risk reduction, dependencies, architectural leverage, cost, and operational impact.

Counterexample: Select controls solely because they are familiar or easy to deploy, which overstates what one safeguard can establish. | Add a familiar appliance while leaving assets, identities, trust transitions, ownership, and residual risk unmodeled, leaving control ownership unclear, while system-wide failure behavior remains unresolved. | Move the decision into coding and wait for testing to reveal architectural failures, deferring an architecture decision to a later stage.

Limitations: Do not select controls solely because they are familiar or easy to deploy.

Control allocation

Control allocation assigns each security objective to one or more architectural elements, services, people, or external providers. Allocation should avoid gaps, duplication, and conflicting enforcement.

Example: Map every security objective to accountable architectural elements, people, or providers, checking for gaps, duplication, and conflicting enforcement.

Counterexample: Treat internal network placement as sufficient trust and omit explicit boundary controls, which overstates coverage. | Assign all security duties to one component without checking gaps, duplication, or concentration risk, leaving ownership unclear. | Write implementation tasks before agreeing on system context, trust boundaries, and control ownership, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Tradeoffs: Domain 3 defines required outcomes; Domain 4 allocates controls; Domain 5 implements them; Domain 6 verifies them.

Preventive, detective, corrective, and recovery controls in architecture

Architecture should combine control types so that prevention failure does not leave the system without detection, containment, correction, or recovery capability.

Example: Combine preventive, detective, corrective, and recovery controls with different failure modes so one prevention failure does not defeat the architecture.

Counterexample: Assume that defense in depth is achieved by duplicating identical controls with the same failure mode, which overstates coverage. | Document the selected components but omit data flows, actors, assumptions, and failure propagation, leaving trust boundaries, control ownership, and failure behavior undefined. | Permit each component team to make independent security decisions without an allocated architecture, deferring an architecture decision to a later stage.

Limitations: Defense in depth is not achieved by duplicating identical controls with the same failure mode.

Trust boundaries

A trust boundary is a location where data, control, identity, privilege, or administrative responsibility crosses between different trust assumptions. Boundary crossings require explicit validation, authentication, authorization, protection, and logging decisions.

Example: Require explicit validation, authentication, authorization, protection, and logging wherever data, identity, privilege, control, or administration crosses different trust assumptions.

Counterexample: Regard one preventive safeguard as complete coverage, leaving detection, containment, and recovery unaddressed, which overstates coverage. | Place the affected components on an internal network and treat location as sufficient trust, leaving boundary and control ownership unclear. | Defer failure and recovery decisions until deployment, leaving degraded behavior undefined, deferring a system-wide architecture decision to implementation or operations, while system-wide failure behavior remains unresolved.

Security domains and zones

Security domains group assets and components with common policy, trust, classification, or administration. Zones and conduits can constrain permitted communication and reduce lateral movement.

Example: Group assets by common policy, trust, classification, and administration, then use controlled zones and conduits to limit communication and lateral movement.

Counterexample: Treat internal network location as sufficient proof of trustworthiness, which overstates what one safeguard can establish. | Reuse one identity and privilege model across distinct trust boundaries without reassessing context, leaving trust boundaries and control ownership unclear. | Rely on later penetration testing to compensate for missing architectural decisions, deferring a system-wide architecture decision to implementation or operations.

Limitations: Network location alone does not establish trustworthiness.

Distributed computing

Distributed computing divides processing, storage, or control among communicating nodes. Security architecture must account for partial failure, network hostility, identity across nodes, consistency, replay, message ordering, and compromised participants.

Example: Account for partial failure, network hostility, identity across nodes, consistency, replay, message ordering, and compromised participants.

Counterexample: Assume every participating component shares the same trust level and accountable owner, which overstates coverage, while system-wide failure behavior remains unresolved. | Optimize the initial deployment while omitting update, recovery, and support behavior, leaving ownership unclear. | Choose a product before identifying the requirements, assets, trust boundaries, and credible threats.

Client-server architecture

Client-server systems centralize some services while clients request functionality. The server must not rely on client-side enforcement for authoritative security decisions.

Example: Enforce authorization and validation on the server for every privileged operation, treating client checks only as usability controls.

Counterexample: Hide privileged controls in the client and trust the interface not to submit unauthorized requests, which overstates coverage. | Validate administrator operations only in client code while the server checks authentication alone, leaving trust boundaries and control ownership unclear. | Accept client-supplied ownership and role fields because the request came through the approved application, deferring architectural judgment.

Limitations: Client-side validation improves usability but cannot replace server-side authorization and validation.

Peer-to-peer architecture

Peer-to-peer systems allow nodes to act as both clients and servers. Architecture must address peer identity, reputation, discovery, content authenticity, malicious peers, availability, and decentralized trust.

Example: Address peer identity, reputation, discovery, content authenticity, malicious peers, availability, and decentralized trust.

Counterexample: Declare the architecture complete once components are named, despite missing data flows and responsibilities. | Use a single stakeholder view and ignore privacy, operations, assurance, and incident-response concerns, leaving ownership unclear. | Leave residual risk undocumented because controls are planned but not yet validated, deferring architectural judgment.

Message queuing architecture

Message queues decouple producers and consumers. Security design must cover producer and consumer authentication, topic or queue authorization, message integrity and confidentiality, replay handling, poison messages, dead-letter queues, retention, and broker trust.

Example: Authenticate producers and consumers, authorize queues, protect messages, and design idempotency, replay handling, poison-message isolation, retention, and broker trust.

Counterexample: Assume broker delivery makes each command authentic and exactly-once without consumer idempotency, which overstates coverage. | Give every producer and consumer access to all queues so retries and routing remain simple, leaving ownership unclear. | Retry poison messages indefinitely and retain payloads without tenant, privacy, or dead-letter controls, deferring an architecture decision to a later stage, while system-wide failure behavior remains unresolved.

Limitations: A queue does not automatically guarantee exactly-once processing or message authenticity.

N-tier architecture

N-tier architecture separates presentation, business logic, data, and other services. Separation can reduce exposure and support distinct controls, but each tier boundary and inter-tier identity must be secured.

Example: Separate presentation, business logic, data, and supporting services, then secure every tier boundary and inter-tier identity.

Counterexample: Treat internal network placement as sufficient trust and omit explicit boundary controls, which overstates coverage, while system-wide failure behavior remains unresolved. | Assign all security duties to one component without checking gaps, duplication, or concentration risk. | Write implementation tasks before agreeing on system context, trust boundaries, and control ownership.

Service-oriented architecture

SOA organizes capabilities as reusable services with defined contracts. Architecture must govern service identity, discovery, policy, message protection, composition, and trust across service boundaries.

Example: Govern service identity, discovery, policy, message protection, composition, and trust across service boundaries.

Counterexample: Use a product inventory and network diagram as complete architecture evidence, which overstates coverage. | Document the selected components but omit data flows, actors, assumptions, and failure propagation, leaving ownership unclear. | Allow each component team to make independent security decisions without an allocated architecture, deferring architectural judgment.

Enterprise service bus

An enterprise service bus mediates communication, routing, transformation, and policy enforcement. It can centralize controls but may create a high-value target and systemic dependency.

Example: Harden and isolate the bus, define policy ownership, and add resilient capacity and failover because centralized control creates concentration risk.

Counterexample: Assume one preventive safeguard as complete coverage, leaving detection, containment, and recovery unaddressed, which overstates coverage. | Place the affected components on an internal network and treat location as sufficient trust, leaving trust boundaries and control ownership unclear. | Defer failure and recovery decisions until deployment, leaving degraded behavior undefined, deferring a system-wide architecture decision to implementation or operations.

Limitations: Central enforcement improves consistency but can create concentration risk and a single point of failure if not made resilient.

Web services

Web-service security depends on transport and/or message protection, service identity, schema validation, authorization, replay resistance, secure discovery, and safe error handling.

Example: Combine endpoint identity, authorization, schema validation, transport or message protection, replay resistance, secure discovery, and safe fault handling.

Counterexample: Adopt the documented pattern without checking its assumptions, context, trade-offs, or failure consequences, which overstates coverage. | Reuse one identity and privilege model across distinct trust boundaries without reassessing context, leaving control ownership unclear. | Rely on later penetration testing to compensate for missing architectural decisions, deferring an architecture decision to a later stage, while system-wide failure behavior remains unresolved.

Microservices architecture

Microservices increase the number of services, identities, APIs, deployment units, and network calls. Architecture should use service identity, least privilege, bounded contexts, secure discovery, policy enforcement, observability, and resilient communication.

Example: Use workload identity, least privilege, bounded contexts, secure discovery, policy enforcement, observability, and resilient service communication.

Counterexample: Use network location as service identity and allow broad east-west communication between workloads, which overstates coverage, while system-wide failure behavior remains unresolved. | Share one credential across all services so discovery and rotation remain centralized, leaving ownership unclear. | Split the monolith into services without adding policy enforcement, observability, or resilient dependency handling.

Limitations: Microservices are not inherently more secure than a monolith; they change the attack surface and operational complexity.

Monolith versus microservices security trade-offs

A monolith may reduce distributed-system complexity but concentrates privilege and failure impact. Microservices can improve isolation but increase interfaces, identities, configuration, and supply-chain exposure.

Example: Compare concentrated privilege and failure impact in the monolith with the additional interfaces, identities, configuration, and supply-chain exposure of microservices.

Counterexample: Use a successful initial deployment as proof that failure and recovery behavior are secure, which overstates what one safeguard can establish. | Choose controls by familiarity rather than requirements, threats, dependencies, and risk reduction, leaving trust boundaries, control ownership, and failure behavior undefined. | Regard a deployment diagram as sufficient architecture without documenting responsibilities or assumptions, deferring a system-wide architecture decision to implementation or operations.

Rich internet applications

Rich internet applications execute substantial logic in the client and maintain frequent server communication. The architecture must assume the client can be inspected, modified, automated, and controlled by an attacker.

Example: Assume the client can be inspected, modified, automated, and controlled by an attacker.

Counterexample: Call the architecture complete once components are named, despite missing data flows and responsibilities. | Rely on a single stakeholder view and ignore privacy, operations, assurance, and incident-response concerns, leaving ownership unclear. | Keep residual risk undocumented because controls are planned but not yet validated, deferring architectural judgment.

Client-side exploits and threats

Client-side risks include script injection, insecure local storage, DOM manipulation, malicious extensions, compromised dependencies, clickjacking, and abuse of browser capabilities.

Example: Assume the client can be modified and constrain script execution, local storage, browser capabilities, dependencies, framing, and server trust accordingly.

Counterexample: Assume the named approach is secure and skip validation of its trust assumptions and failure behavior, which overstates coverage. | Introduce a familiar appliance while leaving assets, identities, trust transitions, ownership, and residual risk unmodeled, leaving control ownership unclear, while system-wide failure behavior remains unresolved. | Push the decision into coding and wait for testing to reveal architectural failures, deferring an architecture decision to a later stage.

Remote code execution risk

Architectural measures against remote code execution include reducing interpreter exposure, isolating execution, constraining privileges, validating inputs and artifacts, and limiting reachable capabilities.

Example: Reduce interpreter exposure, validate inputs and artifacts, isolate execution, restrict privileges, and limit capabilities reachable after compromise.

Counterexample: Regard internal network placement as sufficient trust and omit explicit boundary controls, which overstates coverage. | Concentrate all security duties to one component without checking gaps, duplication, or concentration risk, leaving ownership unclear. | Create implementation tasks before agreeing on system context, trust boundaries, and control ownership, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Tradeoffs: Detailed coding and sandbox implementation belong primarily to Domain 5.

Constant connectivity risk

Always-connected clients and services enlarge exposure, permit continuous probing, and create dependence on network and identity services. Architecture should support rate limits, resilience, offline-safe behavior where required, and secure session lifecycle.

Example: Support rate limits, resilience, offline-safe behavior where required, and secure session lifecycle.

Counterexample: Rely on a product inventory and network diagram as complete architecture evidence, which overstates coverage. | Record the selected components but omit data flows, actors, assumptions, and failure propagation, leaving ownership unclear. | Allow each component team to make independent security decisions without an allocated architecture.

Pervasive and ubiquitous computing

Pervasive computing embeds networked processing into everyday environments. Security architecture must consider constrained devices, physical access, privacy, intermittent connectivity, scale, heterogeneous protocols, and long support lifetimes.

Example: Consider constrained devices, physical access, privacy, intermittent connectivity, scale, heterogeneous protocols, and long support lifetimes.

Counterexample: Treat one preventive safeguard as complete coverage, leaving detection, containment, and recovery unaddressed. | Put the affected components on an internal network and treat location as sufficient trust, leaving ownership unclear. | Defer failure and recovery decisions until deployment, leaving degraded behavior undefined, deferring an architecture decision to a later stage.

Internet of Things

IoT architecture should address unique device identity, secure onboarding, least functionality, protected communication, updateability, telemetry, physical exposure, lifecycle support, and safe failure.

Example: Address unique device identity, secure onboarding, least functionality, protected communication, updateability, telemetry, physical exposure, lifecycle support, and safe failure.

Counterexample: Apply the documented pattern without checking its assumptions, context, trade-offs, or failure consequences, which overstates coverage. | Apply one identity and privilege model across distinct trust boundaries without reassessing context, leaving control ownership unclear. | Rely on later penetration testing to compensate for missing architectural decisions, deferring a system-wide architecture decision to implementation or operations, while system-wide failure behavior remains unresolved.

Wireless architecture

Wireless systems require protection against eavesdropping, rogue access, spoofing, jamming, weak pairing, and mobility-related trust changes. Physical proximity is not equivalent to authorization.

Example: Protect against eavesdropping, rogue access, spoofing, jamming, weak pairing, and mobility-related trust changes without equating proximity with authorization.

Counterexample: Assume every participating component shares the same trust level and accountable owner, which overstates coverage. | Optimize the initial deployment while omitting update, recovery, and support behavior, leaving control ownership unclear. | Select a product before identifying the requirements, assets, trust boundaries, and credible threats, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Location-based services

Location data can be sensitive and infer behavior. Architecture should minimize collection, control precision and retention, prevent spoofing where material, and separate location permission from unrelated access.

Example: Minimize collection, control precision and retention, prevent spoofing where material, and separate location permission from unrelated access.

Counterexample: Use a successful initial deployment as proof that failure and recovery behavior are secure, which overstates coverage. | Select controls by familiarity rather than requirements, threats, dependencies, and risk reduction, leaving trust boundaries and control ownership unclear. | Treat a deployment diagram as sufficient architecture without documenting responsibilities or assumptions, deferring an architecture decision to a later stage.

RFID and NFC

RFID and NFC designs must address unauthorized reading, cloning, relay attacks, weak identifiers, tracking, proximity assumptions, and secure backend validation.

Example: Address unauthorized reading, cloning, relay attacks, weak identifiers, tracking, proximity assumptions, and secure backend validation.

Counterexample: Consider the architecture complete once components are named, despite missing data flows and responsibilities. | Use a single stakeholder view and ignore privacy, operations, assurance, and incident-response concerns, leaving ownership unclear, while system-wide failure behavior remains unresolved. | Omit residual-risk documentation because controls are planned but not yet validated, deferring architectural judgment.

Sensor and mesh networks

Sensor and mesh networks require node authentication, routing integrity, key distribution, resistance to captured nodes, constrained-resource controls, redundancy, and trustworthy aggregation.

Example: Require node authentication, routing integrity, key distribution, captured-node resistance, constrained-resource controls, redundancy, and trustworthy aggregation.

Counterexample: Assume the named approach is secure and skip validation of its trust assumptions and failure behavior. | Add a familiar appliance while leaving assets, identities, trust transitions, ownership, and residual risk unmodeled. | Move the decision into coding and wait for testing to reveal architectural failures, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Embedded software

Embedded software interacts closely with hardware and may have constrained resources, long service life, physical exposure, and safety impact. Security must be designed across boot, memory, update, debug, and recovery mechanisms.

Example: Design security across boot, memory, update, debug, recovery, hardware interaction, physical exposure, and the expected service lifetime.

Counterexample: Assume internal network placement as sufficient trust and omit explicit boundary controls, which overstates coverage. | Allocate all security duties to one component without checking gaps, duplication, or concentration risk, leaving ownership unclear. | Draft implementation tasks before agreeing on system context, trust boundaries, and control ownership, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Secure boot

Secure boot establishes a chain of trust that verifies authorized firmware or software before execution. Architecture must define trust anchors, signature verification, rollback policy, recovery, and key lifecycle.

Example: Define trust anchors, signature validation, rollback protection, recovery, and key lifecycle, while treating code vulnerability assessment as a separate assurance need.

Counterexample: Treat a valid startup signature as proof that the authorized firmware contains no exploitable defect, which overstates what one safeguard can establish. | Permit rollback to any previously signed image because every signed version is equally trusted, leaving trust boundaries, control ownership, and failure behavior undefined. | Use one permanent signing key without compromise recovery or trust-anchor replacement, deferring a system-wide architecture decision to implementation or operations.

Limitations: Secure boot validates authorized code at startup; it does not by itself guarantee that authorized code is vulnerability-free.

Secure memory

Secure-memory design may use isolation, access permissions, memory encryption, protected regions, non-executable memory, and safe handling of secrets. The applicable control depends on the threat model and platform.

Example: Select threat-appropriate memory isolation, permissions, encryption, protected regions, non-executable memory, and secret-handling controls.

Counterexample: Assume one preventive safeguard provides complete coverage while detection, containment, and recovery remain unaddressed. | Put the affected components on an internal network and assume location establishes trust. | Leave failure and recovery decisions for deployment, with degraded behavior still undefined, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Secure update architecture

Secure updates require authenticated packages, integrity verification, authorization, rollback protection, staged deployment, recovery from interruption, version policy, and support for key compromise.

Example: Authenticate and authorize packages, verify integrity, prevent unauthorized rollback, stage deployment, recover from interruption, and plan for signing-key compromise.

Counterexample: Use the documented pattern without checking its assumptions, context, trade-offs, or failure consequences, which overstates coverage. | Apply one identity and privilege model to distinct trust boundaries without reassessing their context, leaving control ownership unclear. | Expect later penetration testing to compensate for architecture decisions that were never made, deferring a system-wide architecture decision to implementation or operations.

Cloud architectures

Cloud architecture requires explicit shared-responsibility boundaries, tenant isolation, identity-centric control, secure management planes, data-location decisions, elasticity controls, logging, and provider dependency analysis.

Example: Define shared responsibility, tenant isolation, identity-centric controls, management-plane security, data location, elasticity, logging, and provider dependency handling.

Counterexample: Treat every participating component shares the same trust level and accountable owner, which overstates coverage. | Focus on the initial deployment while omitting update, recovery, and support behavior, leaving control ownership unclear. | Choose a product before identifying the requirements, assets, trust boundaries, and credible threats, deferring architectural judgment, while system-wide failure behavior remains unresolved.

Software as a Service

In SaaS, the provider controls most application and platform layers while the customer retains responsibilities such as identity, data governance, configuration, and use. Responsibilities must be documented rather than assumed.

Example: Document provider and customer responsibilities, retaining customer ownership for identity, data governance, configuration, user administration, and acceptable use.

Counterexample: Assign user roles, retention, and data-sharing configuration entirely to the SaaS provider, which overstates what one safeguard can establish. | Assume the provider’s application controls remove the customer’s responsibility for identity and data governance, leaving trust boundaries and control ownership unclear. | Treat the SaaS contract as proof that customer configuration and acceptable-use risks are controlled, deferring architectural judgment.

Platform as a Service

In PaaS, the provider manages more infrastructure and runtime functions while the customer remains responsible for application design, code, identities, data, and configuration within the platform model.

Example: Assign the provider platform duties while keeping application design, code, identities, data, and platform configuration under customer control.

Counterexample: Assign application code, service identities, data, and platform configuration entirely to the PaaS provider, which overstates coverage. | Assume the managed runtime makes insecure application design and customer secrets the provider’s responsibility, leaving control ownership unclear. | Use provider infrastructure assurance as evidence that the deployed application is securely configured, deferring an architecture decision to a later stage.

Infrastructure as a Service

In IaaS, the customer has greater responsibility for operating systems, network configuration, workloads, identities, keys, and monitoring, while the provider secures the underlying physical and virtualization infrastructure.

Example: Assign the provider physical and virtualization layers while the customer owns guest systems, network policy, workloads, identities, keys, and monitoring.

Counterexample: Assign guest operating systems, network rules, workload identities, keys, and monitoring to the IaaS provider, which overstates coverage. | Treat physical and hypervisor protection as proof that customer workloads require no hardening, leaving trust boundaries and control ownership unclear. | Leave customer management-plane permissions undefined because the provider owns the data center, deferring a system-wide architecture decision to implementation or operations.

Multi-tenant isolation

Multi-tenant architecture must isolate data, identity, compute, keys, caches, logs, and management functions. Tenant context should be explicit and enforced at every relevant layer.

Example: Derive tenant context from trusted identity and enforce isolation across data, compute, keys, caches, logs, and management functions.

Counterexample: Authorize records from a tenant identifier supplied in the request without binding it to trusted identity, which overstates coverage. | Reuse caches, encryption keys, logs, and administrative functions across tenants without explicit context, leaving ownership unclear. | Rely on separate database rows while leaving compute, metadata, backups, and management planes shared, deferring architectural judgment.

Limitations: A tenant identifier supplied by the client is not sufficient authorization.

Mobile applications

Mobile architecture must assume device loss, hostile local environments, untrusted networks, platform fragmentation, application repackaging, and permission abuse. Sensitive decisions should remain server-authoritative where practical.

Example: Assume device loss, hostile local environments, untrusted networks, platform fragmentation, application repackaging, and permission abuse.

Counterexample: Accept a product inventory and network diagram as complete architecture evidence, which overstates coverage. | List the selected components while omitting data flows, actors, assumptions, and failure propagation, leaving control ownership unclear, while system-wide failure behavior remains unresolved. | Permit component teams to make independent security decisions without common architectural allocation, deferring architectural judgment.

Implicit data collection privacy

Mobile and pervasive systems may collect telemetry, identifiers, contacts, sensors, and location without users recognizing the scope. Architecture must support transparency, minimization, permission control, retention, and safe defaults.

Example: Support transparency, minimization, permission control, retention, and safe defaults.

Counterexample: Use a single preventive safeguard as the entire security strategy and omit detection, containment, and recovery. | Move the affected components behind an internal boundary and rely on network placement as proof of trust. | Postpone failure and recovery design until deployment and leave degraded behavior unspecified.

Hardware platform concerns

Software architecture must account for hardware-rooted trust, microarchitectural leakage, firmware, device drivers, physical attacks, and the security properties supplied or undermined by the platform.

Example: Account for hardware-rooted trust, microarchitectural leakage, firmware, device drivers, physical attacks, and the security properties supplied or undermined by the platform.

Counterexample: Adopt the documented pattern without checking its assumptions, context, trade-offs, or failure consequences, which overstates what one safeguard can establish. | Carry the same identity and privilege model across different trust boundaries without reevaluating assumptions, leaving trust boundaries and control ownership unclear, while system-wide failure behavior remains unresolved. | Use future penetration tests as a substitute for unresolved architecture decisions, deferring a system-wide architecture decision to implementation or operations.

Side-channel mitigation

Side channels leak information through timing, power, electromagnetic emissions, cache behavior, or other indirect signals. Mitigations may include constant-time operations, isolation, blinding, noise, and platform-specific controls.

Example: Reduce sharing around secret processing and apply threat-appropriate constant-time, isolation, blinding, noise, or platform controls.

Counterexample: Presume every participating component shares the same trust level and accountable owner, which overstates coverage. | Optimize for initial deployment and omit update, recovery, and support behavior, leaving ownership unclear. | Pick a product before identifying requirements, assets, trust boundaries, and credible threats.

Speculative-execution mitigation

Speculative execution can expose data through microarchitectural state. Architecture may require patched platforms, isolation, reduced sharing, compiler or OS mitigations, and risk-based placement of sensitive workloads.

Example: Use patched platforms, reduced sharing, isolation, compiler or operating-system mitigations, and risk-based placement of sensitive workloads.

Counterexample: Use a successful initial deployment as proof that failure and recovery behavior are secure, which overstates coverage. | Choose controls by familiarity rather than requirements, threats, dependencies, and risk reduction, leaving trust boundaries and control ownership unclear. | Treat a deployment diagram as sufficient architecture without documenting responsibilities or assumptions, deferring architectural judgment.

Secure element

A secure element provides protected storage and cryptographic operations. Architecture must still define provisioning, attestation, access policy, lifecycle, revocation, and trust in the surrounding software.

Example: Use the protected hardware boundary for keys and cryptographic operations, while separately defining provisioning, attestation, caller policy, revocation, and lifecycle.

Counterexample: Declare the architecture complete once components are named, despite missing data flows and responsibilities, which overstates coverage. | Use a single stakeholder view and ignore privacy, operations, assurance, and incident-response concerns, leaving trust boundaries and control ownership unclear. | Leave residual risk undocumented because controls are planned but not yet validated, deferring a system-wide architecture decision to implementation or operations.

Firmware and drivers

Firmware and drivers execute with high privilege and can undermine higher-level controls. Architecture should minimize attack surface, verify provenance and updates, restrict interfaces, and monitor support lifecycle.

Example: Minimize attack surface, verify provenance and updates, restrict interfaces, and monitor support lifecycle.

Counterexample: Assume the named approach is secure and skip validation of its trust assumptions and failure behavior. | Introduce a familiar appliance while leaving assets, identities, trust transitions, ownership, and residual risk unmodeled. | Move the decision into coding and wait for testing to reveal architectural failures, deferring architectural judgment.

Cognitive computing

Cognitive computing includes AI and immersive technologies whose behavior may be probabilistic, data-dependent, adaptive, and difficult to explain. Architecture must isolate uncertain components and constrain their authority.

Example: Isolate uncertain components and constrain their authority.

Counterexample: Assume internal network placement establishes trust and omit explicit boundary controls. | Concentrate all security duties in one component without checking gaps, duplication, or concentration risk. | Create implementation tasks before agreeing on system context, trust boundaries, and control ownership.

Artificial intelligence architecture

AI architecture should treat models, prompts, training and retrieval data, vector stores, inference services, tools, and agents as distinct assets and trust boundaries.

Example: Treat models, prompts, training and retrieval data, vector stores, inference services, tools, and agents as distinct assets and trust boundaries.

Counterexample: Model an AI component as a deterministic function with unrestricted authority, which overstates what one safeguard can establish. | Record component names but leave out data flows, actors, assumptions, and failure propagation, leaving trust boundaries, control ownership, and failure behavior undefined. | Let component teams define security independently without shared architecture or allocated responsibilities, deferring an architecture decision to a later stage.

Limitations: Do not model an AI component as a deterministic function with unrestricted authority.

Virtual and augmented reality

VR and AR systems may process spatial maps, biometrics, gestures, audio, video, and environmental context. Architecture must address safety, privacy, sensor spoofing, content integrity, and immersive social-engineering risks.

Example: Address safety, privacy, sensor spoofing, content integrity, and immersive social-engineering risks.

Counterexample: Assume one preventive safeguard provides complete coverage while detection, containment, and recovery remain unaddressed. | Put the affected components on an internal network and assume location establishes trust. | Leave failure and recovery decisions for deployment, with degraded behavior still undefined, deferring architectural judgment.

Industrial Internet of Things

Industrial IoT connects cyber and physical processes. Architecture must prioritize safety, availability, deterministic operation, segmentation, asset longevity, secure update, and controlled remote access.

Example: Prioritize safety, availability, deterministic operation, segmentation, asset longevity, secure update, and controlled remote access.

Counterexample: Apply the documented pattern without checking its assumptions, context, trade-offs, or failure consequences. | Apply one identity and privilege model to distinct trust boundaries without reassessing their context. | Expect later penetration testing to compensate for architecture decisions that were never made, deferring architectural judgment.

Facility, automotive, robotics, and medical-device systems

These IIoT examples combine software compromise with physical consequence. Security decisions should account for hazard analysis, fail-safe or fail-operational requirements, human override, and regulatory constraints.

Example: Account for hazard analysis, fail-safe or fail-operational requirements, human override, and regulatory constraints.

Counterexample: Treat all participating components as having the same trust level and accountable owner. | Focus on initial deployment while leaving update, recovery, and support behavior undefined. | Commit to a product before the requirements, assets, trust boundaries, and credible threats are understood.

Software-defined production processes

Software-defined production increases flexibility but can allow malicious or erroneous software changes to affect physical output. Architecture should protect recipes, commands, identities, change authorization, integrity, and rollback.

Example: Protect recipes, commands, identities, change authorization, integrity, and rollback.

Counterexample: Use a successful initial deployment as proof that failure and recovery behavior are secure. | Choose familiar controls instead of evaluating requirements, threats, dependencies, and risk reduction. | Accept a deployment diagram as complete architecture without documenting responsibilities or assumptions.

Classic security design principles

Classic security design principles provide reusable reasoning rules for architecture and design. They are not product prescriptions; they help evaluate simplicity, defaults, authorization, shared mechanisms, and usability.

Example: Use the Domain 1.2 principles as review criteria for simplicity, defaults, mediation, privilege, shared mechanisms, resilience, and usability without redefining them in Domain 4.

Counterexample: Call the architecture complete after naming components, despite missing data flows and responsibilities, which overstates what one safeguard can establish. | Rely on one stakeholder view while ignoring privacy, operations, assurance, and incident-response concerns, leaving trust boundaries, control ownership, and failure behavior undefined. | Omit residual-risk documentation because controls are planned but not yet validated, deferring a system-wide architecture decision to implementation or operations.

Tradeoffs: The definitions of these classic security design principles are owned by Domain 1.2. Domain 4 reuses them only as architecture and design-review criteria. Domain 1.2 also explicitly includes Segregation of Duties, Defense in Depth, Resiliency, and Component Reuse; this Domain 4 block focuses on the principles most directly applied in the following architecture scenarios. See D4.5-003 for design-review use.

Economy of mechanism

Security mechanisms should be as simple and small as practical so that behavior can be understood, reviewed, tested, and maintained. Unnecessary complexity increases defect probability and weakens assurance.

Example: Keep security mechanisms as small and simple as practical so they can be understood, reviewed, tested, and maintained.

Counterexample: Assume the named approach is secure and skip validation of its trust assumptions and failure behavior. | Add a familiar appliance while leaving assets, identities, trust transitions, ownership, and residual risk unmodeled, leaving ownership unclear. | Shift the decision into coding and wait for testing to reveal architectural failures, deferring an architecture decision to a later stage.

Fail-safe defaults

Access should be denied unless it is explicitly permitted. Failure behavior must preserve the system’s safety, security, and continuity objectives rather than silently granting access.

Example: Define failure behavior that denies unapproved access while preserving any explicitly required safety and continuity outcome.

Counterexample: Assume internal network placement establishes trust and omit explicit boundary controls, which overstates coverage. | Concentrate authorization and timeout handling in one component without checking gaps, duplication, or failure impact. | Leave timeout behavior to implementation teams before the required deny-by-default and continuity rules are agreed.

Complete mediation

Every security-relevant access should be checked against current authorization policy. Cached decisions, long-lived capabilities, and indirect access paths require explicit invalidation and revalidation design.

Example: Revalidate every security-relevant access against current policy and design invalidation for cached decisions and long-lived capabilities.

Counterexample: Use a product inventory and network diagram as complete architecture evidence, which overstates what one safeguard can establish. | List the selected components while omitting data flows, actors, assumptions, and failure propagation, leaving control ownership unclear. | Permit component teams to make independent security decisions without common architectural allocation, leaving authorization-cache invalidation and role-revocation behavior undefined.

Open design

Security should not depend on keeping the architecture or algorithm secret. Protection should depend on controlled secrets such as keys and credentials, plus sound, reviewable mechanisms.

Example: Base security on sound reviewable mechanisms and controlled secrets rather than secrecy of the architecture or algorithm.

Counterexample: Use a single preventive safeguard as the entire security strategy and omit detection, containment, and recovery, which overstates coverage. | Move the affected components behind an internal boundary and rely on network placement as proof of trust, leaving control ownership unclear. | Postpone failure and recovery design until deployment and leave degraded behavior unspecified, deferring an architecture decision to a later stage.

Separation of privilege

High-impact actions may require multiple independent conditions, roles, approvals, or factors. Separation reduces the risk that one compromised identity or mechanism can authorize the entire action.

Example: Require multiple independent conditions, roles, approvals, or factors for high-impact actions so one compromise cannot authorize the whole operation.

Counterexample: Apply the documented pattern without checking its assumptions, context, trade-offs, or failure consequences, which overstates coverage. | Carry the same identity and privilege model across different trust boundaries without reevaluating assumptions, leaving control ownership unclear. | Use future penetration tests as a substitute for unresolved architecture decisions, deferring a system-wide architecture decision to implementation or operations.

Least privilege as an architectural principle

Users, services, components, and administrative planes should receive only the permissions, data access, and execution capabilities required for their current responsibilities and duration.

Example: Limit users, services, components, and management planes to the permissions, data, capabilities, and duration required for current responsibilities.

Counterexample: Treat all participating components as having the same trust level and accountable owner, which overstates coverage. | Optimize for initial deployment and omit update, recovery, and support behavior, leaving control ownership unclear. | Pick a product before identifying requirements, assets, trust boundaries, and credible threats, deferring architectural judgment.

Least common mechanism

Minimize mechanisms and mutable state shared across users, tenants, components, or security domains when sharing increases interference, information leakage, or blast radius. Shared services must be evaluated for isolation, consistency, and concentration risk.

Example: Reduce mutable mechanisms shared across security domains, while evaluating necessary shared services for isolation, consistency, and concentration risk.

Counterexample: Use a successful initial deployment as proof that failure and recovery behavior are secure, which overstates coverage. | Favor familiar controls without comparing their fit to requirements, threats, dependencies, and risk reduction, leaving trust boundaries and control ownership unclear. | Accept a deployment diagram as complete architecture without documenting responsibilities or assumptions, deferring an architecture decision to a later stage.

Psychological acceptability

Security controls should be understandable and usable in normal workflows. Controls that create excessive friction, confusing feedback, or unsafe workarounds are less likely to be used correctly.

Example: Make security controls understandable and usable in normal workflows so users do not create unsafe workarounds.

Counterexample: Call the architecture complete after naming components, despite missing data flows and responsibilities. | Rely on one stakeholder view while ignoring privacy, operations, assurance, and incident-response concerns, leaving control ownership unclear. | Omit residual-risk documentation because controls are planned but not yet validated, deferring an architecture decision to a later stage.

Perform secure interface design

Secure interface design treats every interface as a potential trust-boundary crossing and defines authentication, authorization, validation, protection, rate control, error behavior, observability, and lifecycle expectations.

Example: Define authentication, authorization, validation, protection, rate control, error behavior, observability, and lifecycle expectations.

Counterexample: Trust the secure interface design interface because it is internal and omit authoritative authorization. | Protect secure interface design only with transport encryption and omit operation-level authorization and replay handling. | Rely on client behavior and later testing to compensate for missing controls in secure interface design.

Security management interfaces

Administrative interfaces require stronger identity assurance, least privilege, separation from ordinary user paths, secure defaults, change logging, session controls, and restricted exposure.

Example: Require stronger identity assurance, least privilege, separation from user paths, secure defaults, change logging, session controls, and restricted exposure.

Counterexample: Use transport encryption as the only interface control, which assumes the interface is trustworthy without an authoritative policy decision. | Authenticate the caller but skip object, action, and tenant authorization, leaving validation, authorization, and failure behavior incomplete. | Defer authorization to application code without an explicit interface contract, deferring interface security to downstream code.

Out-of-band management

Out-of-band management uses a separate path for administration or recovery. It can remain available during primary-network failure but must be independently secured, monitored, and tested.

Example: Independently secure, monitor, and test the separate management path with strong identity, restricted exposure, and recovery procedures.

Counterexample: Trust the separate management network automatically and omit independent hardening, monitoring, and testing, which assumes the interface is trustworthy. | Validate input with one parser while downstream components interpret a different representation, leaving validation, authorization, and failure behavior incomplete. | Let downstream consumers invent validation, purpose, and retention rules independently, deferring an interface-contract decision to implementation or later testing.

Limitations: A separate management network is not automatically trusted or unreachable.

Log interfaces

Log interfaces must protect confidentiality, integrity, availability, time synchronization, source identity, schema stability, and resistance to injection or log-forging.

Example: Protect confidentiality, integrity, availability, time synchronization, source identity, schema stability, and resistance to injection or log-forging.

Counterexample: Keep obsolete versions indefinitely and treat backward compatibility as overriding security lifecycle needs, which assumes trust. | Expose the interface without rate limits, safe error handling, observability, or lifecycle policy, leaving authorization rules incomplete. | Treat successful connectivity as proof that the interface is securely designed, deferring interface security to downstream code.

Upstream and downstream dependencies

Interfaces depend on upstream identity, data, key, configuration, network, and service providers, and may affect downstream consumers. Architecture must model failure propagation, trust, versioning, and ownership across dependencies.

Example: Model failure propagation, trust, versioning, and ownership across dependencies.

Counterexample: Trust the internal interface and omit authoritative server-side authorization. | Use one shared key across unrelated applications and trust domains. | Use operational monitoring to compensate for ambiguous protocol states and downgrade paths.

Key sharing between applications

Shared keys create coupling and broaden compromise impact. Prefer scoped identities and keys, define rotation and revocation, and avoid using one secret across unrelated applications.

Example: Replace the shared secret with scoped application identities and keys, defining independent rotation, revocation, ownership, and compromise containment.

Counterexample: Assume that key sharing should be treated as a convenience with no architectural consequence, which assumes trust. | Preserve obsolete the shared-key arrangement endpoints and downgrade paths indefinitely, leaving validation, authorization, and failure behavior incomplete. | Defer concurrency and consistency decisions for the shared-key arrangement to unit testing, deferring interface design.

Limitations: Key sharing should not be treated as a convenience with no architectural consequence.

Data sharing between applications

Data-sharing interfaces require purpose limitation, schema and classification awareness, authorization, minimization, integrity, provenance, retention, and downstream-use controls.

Example: Enforce purpose limitation, schema and classification awareness, authorization, minimization, integrity, provenance, retention, and downstream-use controls.

Counterexample: Rely on client-side checks as authoritative enforcement, which assumes the interface is trustworthy without an authoritative policy decision. | Fail every request closed without evaluating safety, continuity, or recovery objectives, leaving validation, authorization, and failure behavior incomplete. | Allow legacy versions to remain indefinitely because deprecation is treated as an operational concern, deferring interface design.

Protocol design choices

Protocol design specifies message formats, state transitions, identities, cryptographic protection, negotiation, replay behavior, error handling, versioning, and downgrade resistance.

Example: Define message formats, state transitions, identities, cryptographic protection, negotiation, freshness, replay handling, versioning, errors, and downgrade resistance.

Counterexample: Keep obsolete versions indefinitely and treat backward compatibility as overriding security lifecycle needs. | Rely on manual operator judgment for high-impact actions without clear context, confirmation, or separation of privilege, leaving controls incomplete. | Assume a separate management path is trusted without independent security controls or review, deferring interface security to downstream code.

Application programming interfaces

API architecture should use explicit contracts, server-side authorization, input and output validation, rate limits, secure pagination, idempotency where required, versioning, and observability.

Example: Use explicit contracts, server-side authorization, input and output validation, rate limits, secure pagination, idempotency where required, versioning, and observability.

Counterexample: Trust the internal interface and omit authoritative server-side authorization, which assumes the interface is trustworthy. | Protect the API only with transport encryption and omit operation-level authorization and replay handling, leaving authorization rules incomplete. | Rely on client behavior and later testing to compensate for missing controls in the API, deferring interface security to downstream code.

Protocol weaknesses

Weaknesses may arise from unauthenticated messages, ambiguous parsing, insecure defaults, downgrade paths, replay, weak randomness, excessive metadata, or unsafe negotiation.

Example: Eliminate unauthenticated and ambiguous messages, insecure defaults, downgrade and replay paths, weak randomness, excessive metadata, and unsafe negotiation.

Counterexample: Use transport encryption as the only interface control, which assumes the interface is trustworthy without an authoritative policy decision. | Authenticate the caller but skip object, action, and tenant authorization, leaving validation, authorization, and failure behavior incomplete. | Defer authorization to application code without an explicit interface contract, deferring interface security to downstream code.

Stateful and stateless protocols

Stateful protocols retain server or session context and require secure state lifecycle. Stateless protocols reduce stored session state but still require integrity, freshness, authorization, and replay resistance.

Example: Secure state lifecycle.

Counterexample: Assume a stateless protocol needs no freshness, replay protection, authorization, or security-relevant context. | Validate input with one parser while downstream components interpret a different representation. | Let downstream consumers invent validation, purpose, and retention rules independently.

Limitations: Stateless does not mean memoryless, unauthenticated, or automatically scalable and secure.

Interface models and contracts

An interface model defines actors, operations, schemas, preconditions, postconditions, errors, authorization rules, and quality constraints. Contract clarity supports threat modeling and verification.

Example: Define actors, operations, schemas, preconditions, postconditions, errors, authorization rules, and quality constraints.

Counterexample: Keep obsolete versions indefinitely and treat backward compatibility as overriding security lifecycle needs. | Expose the interface without rate limits, safe error handling, observability, or lifecycle policy. | Treat successful connectivity as proof that the interface is securely designed, deferring interface design.

Canonicalization and parser consistency

Different interpretations of encodings, paths, schemas, or message boundaries can create validation bypasses. Architecture should minimize parser diversity and define canonical representations.

Example: Define one canonical representation and minimize parser differences so validation and downstream interpretation cannot diverge.

Counterexample: Trust the internal interface and omit authoritative server-side authorization, which assumes trust. | Use one shared key across unrelated applications and trust domains, leaving authorization rules incomplete. | Use operational monitoring to compensate for ambiguous protocol states and downgrade paths, deferring interface design.

Fail-closed and safe degradation at interfaces

When authorization, policy, identity, or integrity services fail, interfaces should follow explicitly designed failure behavior that protects assets while supporting necessary safety or continuity requirements.

Example: Select an explicit failure mode from safety, security, availability, and continuity objectives instead of applying fail-closed mechanically.

Counterexample: Deny every operation during policy-service failure even when the result creates a greater life-safety hazard, which assumes trust. | Fail open for all requests whenever an identity or integrity dependency becomes unavailable, leaving controls incomplete. | Leave interface failure behavior undefined and allow each implementation to choose independently, deferring interface design.

Limitations: Fail closed is not universally correct in life-safety or availability-critical systems; the safe failure mode depends on system objectives.

Interface versioning and deprecation

Secure evolution requires version support policy, compatibility analysis, deprecation timelines, downgrade prevention, and removal of obsolete endpoints and algorithms.

Example: Define supported versions, compatibility analysis, deprecation dates, downgrade prevention, and removal of obsolete endpoints and algorithms.

Counterexample: Rely on client-side checks as authoritative enforcement, which assumes the interface is trustworthy without an authoritative policy decision. | Fail every request closed without evaluating safety, continuity, or recovery objectives, leaving validation, authorization, and failure behavior incomplete. | Allow legacy versions to remain indefinitely because deprecation is treated as an operational concern, deferring interface design.

Human-machine and administrative workflow interfaces

Security depends on usable workflows, clear authorization context, confirmation for high-impact actions, safe defaults, and resistance to social-engineering or confused-deputy behavior.

Example: Show the authorization context and target, require confirmation for high-impact actions, use safe defaults, and resist social-engineering and confused-deputy behavior.

Counterexample: Keep obsolete versions indefinitely and treat backward compatibility as overriding security lifecycle needs, which assumes the interface is trustworthy. | Rely on manual operator judgment for high-impact actions without clear context, confirmation, or separation of privilege, leaving authorization rules incomplete. | Assume a separate management path is trusted without independent security controls or review, deferring an interface-contract decision to implementation or later testing.

Architectural control of race conditions and TOCTOU

Race conditions occur when security or consistency depends on timing between concurrent actions. Architecture can reduce time-of-check-to-time-of-use risk through atomic operations, transaction boundaries, uniqueness constraints, idempotency, serialization, state-machine enforcement, and revalidation immediately before commitment.

Example: Use an appropriate atomic operation, transaction boundary, uniqueness rule, idempotency control, state machine, or revalidation immediately before commitment.

Counterexample: Add a process-local lock even though concurrent operations occur across several distributed nodes, which assumes trust. | Validate the balance once and trust the value until a later asynchronous commit completes, leaving controls incomplete. | Use client retries without idempotency or uniqueness constraints and rely on testing to find duplicates, deferring interface design.

Limitations: Locks are not a universal answer; the correct concurrency control depends on consistency requirements, failure modes, distribution, performance, and deadlock risk.

Tradeoffs: Domain 4 defines concurrency and consistency models; Domain 5 implements them, and Domain 6 tests race and replay behavior.

Evaluate and select reusable technologies

Reusable technologies should be evaluated for security capability, assurance, compatibility, maturity, support lifecycle, configuration complexity, trust assumptions, known weaknesses, licensing, and operational fit.

Example: Evaluate security capability, assurance, compatibility, maturity, support lifecycle, configuration complexity, trust assumptions, weaknesses, licensing, and operational fit.

Counterexample: Select a technology solely because it is widely used or already available, which overstates assurance. | Compare purchase price for reusable technologies but omit assurance, integration, expertise, and lifecycle cost, leaving lifecycle gaps. | Defer secure configuration of reusable technologies to deployment teams without architecture constraints, deferring architecture constraints.

Limitations: Do not select a technology solely because it is widely used or already available.

Build, buy, reuse, or subscribe decision

The decision should compare control, assurance, time, expertise, lifecycle cost, supplier dependency, integration risk, and the organization’s ability to operate and update the technology.

Example: Compare control, assurance, time, expertise, lifecycle cost, supplier dependency, integration risk, and the organization’s ability to operate and update the technology.

Counterexample: Approve the design after a successful feature demonstration without lifecycle or failure analysis, which overstates what the technology or certification can prove. | Adopt the technology without defining management-plane exposure, privileged operation, or failure containment, leaving trust anchors, privileged operation, support, and replacement risk unexamined. | Use a certification as a substitute for integration, configuration, and failure analysis, deferring configuration and lifecycle decisions to deployment teams without constraints.

Credential management

Credential-management architecture governs issuance, storage, use, rotation, recovery, revocation, and auditing for human and non-human identities.

Example: Define issuance, protected storage, use, rotation, recovery, revocation, and auditing for both human and workload credentials.

Counterexample: Choose the immediately available option without evaluating patching, support, migration, or replacement, which overstates assurance. | Use the default configuration without reviewing trust anchors, identities, secrets, privileged paths, or logging, leaving lifecycle gaps. | Assume vendor support will continue for the full product lifecycle without a migration plan, deferring architecture constraints.

X.509 certificates

X.509 supports public-key certificates and trust chains. Architecture must define certificate authorities, enrollment, validation, name constraints, key protection, revocation or short lifetimes, renewal, and trust-store management.

Example: Define trust anchors, enrollment, endpoint-name validation, constraints, key protection, revocation or short lifetimes, renewal, and trust-store governance.

Counterexample: Validate only the certificate signature and ignore endpoint name, constraints, revocation, and trust-store scope, which overstates assurance. | Use one issuing authority for unrelated trust domains without enrollment or name-constraint policy, leaving lifecycle gaps. | Keep expired and compromised certificates trusted until the next application release, deferring architecture constraints to deployment.

Single sign-on

SSO reduces repeated authentication and centralizes policy, but creates reliance on the identity provider and tokens. Architecture must address session scope, token audience, step-up authentication, outage behavior, and compromise impact.

Example: Restrict token audience and session scope, require step-up authentication where needed, and design identity-provider outage and compromise behavior.

Counterexample: Issue one broad-audience token for every application and administrative operation, which overstates the technology's assurance. | Treat successful SSO authentication as authorization for all local roles and resources, leaving lifecycle duties unclear. | Fail open for privileged actions whenever the identity provider is unavailable, deferring architecture constraints.

Flow control

Flow control regulates how data or requests move through the system to enforce policy, contain abuse, manage load, and preserve availability and ordering.

Example: Regulate how data or requests move through the system to enforce policy, contain abuse, manage load, and preserve availability and ordering.

Counterexample: Approve the design after a successful feature demonstration without lifecycle or failure analysis, which overstates what the technology or certification can prove. | Choose the technology without a migration path even though support ends before the product lifecycle, leaving configuration, support, and recovery duties unclear. | Defer restoration evidence until an actual outage, deferring configuration and lifecycle decisions to deployment teams without constraints.

Proxies

Forward and reverse proxies can mediate access, terminate protocols, enforce policy, hide internal topology, and centralize logging. They also become privileged chokepoints requiring hardening and resilience.

Example: Use the proxy as a hardened, observable policy chokepoint with restricted administration, explicit trust handling, sufficient capacity, and resilient failover.

Counterexample: Choose the immediately available option without evaluating patching, support, migration, or replacement, which overstates the technology's assurance. | Centralize enforcement without designing resilience, leaving trust anchors, privileged operation, support, and replacement risk unexamined. | Treat a successful proof of concept as production assurance, deferring configuration and lifecycle decisions to deployment teams without constraints.

Firewalls

Firewalls constrain network flows according to policy. Architecture should define placement, default-deny behavior, rule ownership, egress control, segmentation, change management, and limitations at encrypted or application layers.

Example: Define placement, default-deny behavior, rule ownership, egress control, segmentation, change management, and limitations at encrypted or application layers.

Counterexample: Select the available technology without evaluating architectural suitability, assurance, or integration risk, which overstates assurance. | Approve the technology after a feature demonstration while omitting support, patching, configuration, and replacement analysis, leaving lifecycle gaps. | Treat supplier popularity as proof that the technology can be operated securely in every context, deferring architecture constraints.

Protocols and queuing for flow control

Protocols and queues can provide backpressure, rate limits, admission control, ordering, retries, and isolation. Their failure and overload behavior must be designed explicitly.

Example: Design backpressure, rate limits, admission control, ordering, retries, isolation, overload behavior, and failure handling explicitly.

Counterexample: Treat a supplier certification as proof that the technology is secure in every deployment context. | Compare purchase price but omit assurance, integration, required expertise, and lifecycle cost, leaving lifecycle gaps. | Defer secure configuration to deployment teams without architecture constraints or approved defaults.

Data loss prevention

DLP identifies and constrains unauthorized movement of sensitive data across endpoints, networks, applications, or storage. Architecture must define classification inputs, enforcement points, false-positive handling, privacy, and bypass risks.

Example: Place DLP at risk-relevant enforcement points using reliable classification, while retaining access control, minimization, privacy safeguards, and bypass analysis.

Counterexample: Deploy DLP and remove least privilege because outbound inspection now controls sensitive data, which overstates the technology's assurance. | Apply DLP without reliable classification or privacy rules and block every matching pattern, leaving configuration, support, and recovery duties unclear. | Use endpoint DLP alone while ignoring application exports, cloud storage, archives, and encrypted channels, deferring architecture constraints to deployment.

Limitations: DLP does not replace access control, minimization, or secure application design.

Virtualization

Virtualization introduces isolation layers and management planes. Security depends on hypervisor or runtime trust, image integrity, workload isolation, device access, management interfaces, and escape resistance.

Example: Protect the hypervisor and management plane, verify images, isolate workloads and devices, restrict administration, and design against escape and cross-tenant impact.

Counterexample: Adopt the immediately available option without evaluating patching, support, migration, or replacement, which overstates the technology's assurance. | Use the default configuration without reviewing trust anchors, identities, secrets, privileged paths, or logging, leaving configuration, support, and recovery duties unclear. | Assume vendor support will continue for the full product lifecycle without a migration plan, deferring configuration and lifecycle decisions to deployment teams without constraints.

Infrastructure as code

IaC expresses infrastructure configuration in versioned, repeatable definitions. Architecture should require review, secret separation, policy checks, provenance, drift detection, and controlled deployment.

Example: Require versioned review, secret separation, policy checks, provenance, controlled deployment, and drift detection for infrastructure definitions.

Counterexample: Select the available technology without evaluating architectural suitability, assurance, or integration risk, which overstates assurance. | Treat the technology as a point product and omit the surrounding operational and key lifecycle. | Select the technology before defining compromise response, recovery, and replacement, deferring architecture constraints to deployment.

Tradeoffs: Implementation and pipeline enforcement are emphasized in Domains 5 and 7; Domain 4 defines the architecture and control points.

Hypervisors

Hypervisors are high-value isolation and management components. Architecture should minimize management exposure, protect images, separate tenants, restrict device passthrough, and maintain patchability.

Example: Minimize management exposure, protect images, separate tenants, restrict device passthrough, and maintain patchability.

Counterexample: Treat a supplier certification as proof that the technology is secure in every deployment context. | Accept the widely used technology without testing architectural assumptions under failure. | Let implementation teams decide trust anchors and privileged interfaces without architecture governance.

Containers

Containers share more host resources than traditional virtual machines. Architecture must account for image provenance, namespace and capability isolation, host security, secrets, network policy, runtime controls, and orchestration trust.

Example: Account for image provenance, namespace and capability isolation, host security, secrets, network policy, runtime controls, and orchestration trust.

Counterexample: Approve the design after a successful feature demonstration without lifecycle or failure analysis, which overstates the technology's assurance. | Choose the technology without a migration path even though support ends before the product lifecycle, leaving lifecycle duties unclear. | Defer restoration evidence until an actual outage, deferring configuration and lifecycle decisions to deployment teams without constraints.

Trusted computing

Trusted computing uses defined trust anchors and measured or verified components to establish evidence about platform state and protect critical functions.

Example: Use defined trust anchors and measured or verified components to establish evidence about platform state and protect critical functions.

Counterexample: Select the immediately available option without evaluating patching, support, migration, or replacement, which overstates the technology's assurance. | Centralize enforcement without designing resilience, leaving trust anchors, privileged operation, support, and replacement risk unexamined. | Treat a successful proof of concept as production assurance, deferring configuration and lifecycle decisions to deployment teams without constraints.

Trusted Platform Module

A TPM can protect keys, support measured boot, sealing, and attestation. Architecture must define what measurements mean, how evidence is verified, and how recovery and ownership changes are handled.

Example: Use TPM measurements and protected keys as scoped evidence, defining verifier policy, recovery, and ownership change without claiming complete application trust.

Counterexample: Accept any TPM quote as proof that the application and all runtime components are correct, which overstates assurance. | Ignore nonce freshness and acceptable-state policy because TPM signatures establish trust automatically, leaving configuration, support, and recovery duties unclear. | Seal keys to measurements without defining recovery for updates or ownership changes, deferring configuration and lifecycle decisions to deployment teams without constraints.

Trusted Computing Base

The TCB is the set of hardware, software, and controls relied upon to enforce security policy. Its correctness and protection are critical; minimizing the TCB reduces assurance burden.

Example: Identify every hardware, software, and control element relied upon to enforce policy, minimize that set, and protect and assure each member.

Counterexample: Define the TCB as the kernel alone while privileged services and hardware also enforce policy, which overstates the technology's assurance. | Expand the TCB with optional plugins and shared services without increasing assurance review, leaving configuration, support, and recovery duties unclear. | Assume every TCB component is vulnerability-free because it is inside the trusted boundary, deferring architecture constraints to deployment.

Limitations: The TCB is not limited to an operating-system kernel and should not be assumed vulnerability-free.

Remote attestation

Remote attestation provides signed evidence about platform or workload state. The verifier must understand freshness, measurement coverage, trust anchors, acceptable-state policy, and privacy implications.

Example: Verify signed, fresh evidence against defined trust anchors, measurement coverage, and acceptable-state policy while considering privacy.

Counterexample: Accept replayed signed measurements without nonce freshness or current acceptable-state policy, which overstates the technology's assurance. | Treat a passing platform measurement as proof that application data and authorization are correct, leaving lifecycle duties unclear. | Collect attestation evidence without defining trust anchors, measurement coverage, or privacy limits, deferring architecture constraints to deployment.

Database security

Database architecture should protect data confidentiality, integrity, availability, and separation through encryption, access control, views, stored logic, auditing, secure connections, backup, and controlled administration.

Example: Protect data confidentiality, integrity, availability, and separation through encryption, access control, views, stored logic, auditing, secure connections, backup, and controlled administration.

Counterexample: Adopt the readily available option without evaluating patching, support, migration, or replacement, which overstates the technology's assurance. | Use the default configuration without reviewing trust anchors, identities, secrets, privileged paths, or logging, leaving configuration, support, and recovery duties unclear. | Assume vendor support will continue for the full product lifecycle without a migration plan, deferring configuration and lifecycle decisions to deployment teams without constraints.

Database encryption

Encryption may protect files, volumes, tablespaces, columns, fields, backups, or connections. Architecture must match encryption scope to threats and define key separation and operational access.

Example: Match encryption scope to the threat and separate keys, while recognizing that an authorized or compromised application can still access plaintext.

Counterexample: Use transparent encryption and assume a compromised application cannot request decrypted records, which overstates the technology's assurance. | Store encryption keys with the database service account and treat separation as unnecessary, leaving configuration, support, and recovery duties unclear. | Encrypt the primary files while leaving backups, exports, and network connections outside the design, deferring configuration and lifecycle decisions to deployment teams without constraints.

Limitations: Transparent encryption does not prevent an authorized or compromised application from reading decrypted data.

Database triggers

Triggers can enforce integrity or generate audit events, but hidden side effects and privilege context can increase complexity. Their use should be documented, reviewed, and tested.

Example: Document, review, and test trigger logic, privilege context, integrity effects, audit behavior, and hidden side effects.

Counterexample: Treat the trigger as trusted because it executes inside the database and skip documenting its privilege context or side effects. | Accept the widely used technology without testing architectural assumptions under failure, leaving lifecycle gaps. | Let implementation teams decide trust anchors and privileged interfaces without architecture governance, deferring architecture constraints.

Database views

Views can restrict exposed rows or columns and provide stable interfaces, but underlying privileges and inference risks must still be controlled.

Example: Use views to restrict exposed rows or columns while separately controlling underlying privileges and inference risk.

Counterexample: Approve the design after a successful feature demonstration without lifecycle or failure analysis, which overstates assurance. | Choose the technology without a migration path even though support ends before the product lifecycle, leaving lifecycle gaps. | Defer restoration evidence until an actual outage, deferring configuration and lifecycle decisions to deployment teams without constraints.

Database privilege management

Use distinct identities, least privilege, separation of administration, controlled stored procedures, and regular review. Applications should not routinely connect with database-owner privileges.

Example: Use distinct identities, least privilege, separated administration, controlled stored procedures, and regular review instead of database-owner access.

Counterexample: Select the available option for convenience without evaluating patching, support, migration, or replacement, which overstates assurance. | Centralize enforcement without designing resilience, leaving configuration, support, and recovery duties unclear. | Treat a successful proof of concept as production assurance, deferring configuration and lifecycle decisions to deployment teams without constraints.

Secure database connections

Connections should authenticate endpoints, protect data in transit, validate certificates or trust, limit network paths, and avoid credentials embedded in code or connection strings.

Example: Authenticate endpoints, protect data in transit, validate certificates or trust, limit network paths, and avoid credentials embedded in code or connection strings.

Counterexample: Select the available technology without evaluating architectural suitability, assurance, or integration risk, which overstates what the technology or certification can prove. | Approve the technology after a feature demonstration while omitting support, patching, configuration, and replacement analysis, leaving configuration, support, and recovery duties unclear. | Treat supplier popularity as proof that the technology can be operated securely in every context, deferring configuration and lifecycle decisions to deployment teams without constraints.

Programming-language environment

Language runtimes shape memory safety, type safety, sandboxing, reflection, package loading, interoperability, and execution policy. Selection should consider security properties, ecosystem, tooling, and support.

Example: Consider security properties, ecosystem, tooling, and support.

Counterexample: Treat a supplier certification as proof that the technology is secure in every deployment context. | Compare purchase price but omit assurance, integration, required expertise, and lifecycle cost. | Defer secure configuration to deployment teams without architecture constraints or approved defaults.

Common language runtime and Java virtual machine

Managed runtimes can provide type and memory safety, verification, garbage collection, and policy mechanisms, but native interfaces, reflection, deserialization, and runtime configuration remain risk areas.

Example: Use managed-runtime safety features while separately controlling native interfaces, reflection, deserialization, package loading, and runtime configuration.

Counterexample: Approve the design after a successful feature demonstration without lifecycle or failure analysis, which overstates assurance. | Adopt the technology without defining management-plane exposure, privileged operation, or failure containment, leaving configuration, support, and recovery duties unclear. | Use a certification as a substitute for integration, configuration, and failure analysis, deferring architecture constraints to deployment.

Python and PowerShell environments

Dynamic and scripting environments increase flexibility but require control of modules, execution policy, package provenance, interpreter exposure, privilege, and command injection risks.

Example: Control of modules, execution policy, package provenance, interpreter exposure, privilege, and command injection risks.

Counterexample: Adopt the readily available option without evaluating patching, support, migration, or replacement. | Use the default configuration without reviewing trust anchors, identities, secrets, privileged paths, or logging, leaving lifecycle gaps. | Assume vendor support will continue for the full product lifecycle without a migration plan, deferring architecture constraints for the logistics optimization service.

Memory-safe versus memory-unsafe language trade-offs

Memory-safe languages can remove classes of memory-corruption defects, but do not eliminate authorization, logic, injection, cryptographic, supply-chain, or configuration vulnerabilities.

Example: Use memory safety to remove corruption classes, while continuing to address authorization, logic, injection, cryptography, configuration, and supply-chain risk.

Counterexample: Select the available technology without evaluating architectural suitability, assurance, or integration risk, which overstates the technology's assurance. | Treat the technology as a point product and omit the surrounding operational and key lifecycle, leaving lifecycle gaps. | Select the technology before defining compromise response, recovery, and replacement, deferring configuration and lifecycle decisions to deployment teams without constraints.

Operating-system controls and services

Architecture should use OS identity, permissions, process isolation, service control, auditing, memory protection, secure boot, patching, and resource limits while minimizing unnecessary services.

Example: Use OS identity, permissions, process isolation, service control, auditing, memory protection, secure boot, patching, and resource limits while minimizing unnecessary services.

Counterexample: Treat a supplier certification as proof that the technology is secure in every deployment context, which overstates the technology's assurance. | Accept the widely used technology without testing architectural assumptions under failure, leaving configuration, support, and recovery duties unclear. | Let implementation teams decide trust anchors and privileged interfaces without architecture governance, deferring architecture constraints to deployment.

Secure backup and restoration planning

Backup architecture must define protected scope, frequency, isolation, encryption, integrity, retention, access, recovery priority, and restoration testing.

Example: Define protected scope, isolation, encryption, integrity, retention, recovery priority, and restoration tests against the required recovery objectives.

Counterexample: Use successful backup-job status as proof that recovery objectives can be met, which overstates the technology's assurance. | Keep online backups under the same administrative credentials as production without isolation, leaving configuration, support, and recovery duties unclear. | Test file retrieval but never restore the full service, identities, dependencies, and integrity state, deferring architecture constraints.

Limitations: A successful backup job does not prove that restoration will meet recovery objectives.

Immutable and offline backups

Immutable or offline copies can reduce ransomware and administrative-compromise risk, but require controlled retention, key management, monitoring, and tested restoration.

Example: Combine immutable or offline copies with controlled retention, key management, monitoring, access governance, and tested restoration.

Counterexample: Select the available option for convenience without evaluating patching, support, migration, or replacement, which overstates assurance. | Centralize enforcement without designing resilience, leaving configuration, support, and recovery duties unclear. | Treat a successful proof of concept as production assurance, deferring configuration and lifecycle decisions to deployment teams without constraints.

Secure data retention, retrieval, and destruction

Architecture must support retention rules, legal holds, efficient authorized retrieval, minimization, backup alignment, and verified destruction across primary, replicated, cached, and archived copies.

Example: Support retention rules, legal holds, efficient authorized retrieval, minimization, backup alignment, and verified destruction across primary, replicated, cached, and archived copies.

Counterexample: Select the available technology without evaluating architectural suitability, assurance, or integration risk, which overstates the technology's assurance. | Approve the technology after a feature demonstration while omitting support, patching, configuration, and replacement analysis, leaving lifecycle duties unclear. | Treat supplier popularity as proof that the technology can be operated securely in every context, deferring architecture constraints to deployment.

Cryptographic agility

Cryptographic agility is the ability to replace algorithms, keys, protocols, or providers without redesigning the entire system. It requires abstraction, inventory, versioning, policy, and migration planning.

Example: Use abstraction, inventory, versioning, policy, and migration planning so algorithms, keys, protocols, or providers can be replaced safely.

Counterexample: Use a supplier certification as proof that the technology is secure in every deployment context, which overstates assurance. | Compare purchase price but omit assurance, integration, required expertise, and lifecycle cost, leaving lifecycle duties unclear. | Defer secure configuration to deployment teams without architecture constraints or approved defaults, deferring architecture constraints.

Technology evaluation proof of concept

A proof of concept can validate assumptions about security features, integration, performance, operability, and failure behavior before commitment. It does not replace formal assurance or production testing.

Example: Use the proof of concept to test security assumptions, integration, performance, operability, and failure behavior, then require separate production assurance.

Counterexample: Accept the design after a successful feature demonstration without lifecycle or failure analysis, which overstates what the technology or certification can prove. | Adopt the technology without defining management-plane exposure, privileged operation, or failure containment, leaving trust anchors, privileged operation, support, and replacement risk unexamined. | Use a certification as a substitute for integration, configuration, and failure analysis, deferring configuration and lifecycle decisions to deployment teams without constraints.

Reusable technology lifecycle and end-of-support risk

Selection must consider patch cadence, vendor or community support, update mechanisms, migration path, licensing, and planned end of support. Unsupported technology creates architectural debt.

Example: Consider patch cadence, vendor or community support, update mechanisms, migration path, licensing, and planned end of support.

Counterexample: Adopt the readily available option without evaluating patching, support, migration, or replacement, which overstates assurance. | Use the default configuration without reviewing trust anchors, identities, secrets, privileged paths, or logging, leaving lifecycle duties unclear. | Assume vendor support will continue for the full product lifecycle without a migration plan, deferring architecture constraints to deployment.

Tradeoffs: Supply-chain pedigree and supplier assessment are primarily Domain 8; Domain 4 determines architectural suitability and replacement implications.

Hardware Security Module

A Hardware Security Module provides a high-assurance boundary for generating, protecting, and using cryptographic keys and for performing operations such as signing, key wrapping, and decryption. It can reduce raw-key exposure and enforce auditable key-use policy.

Example: Use the HSM to protect keys and cryptographic operations, while separately governing authorization, rotation, recovery, destruction, audit, and application use.

Counterexample: Place keys in an HSM and omit application authorization, rotation, recovery, and destruction policy, which overstates assurance. | Allow every application to invoke every HSM key because raw key material is not exposed, leaving lifecycle duties unclear. | Treat HSM availability as sufficient key lifecycle governance without audit or compromise recovery, deferring configuration and lifecycle decisions to deployment teams without constraints.

Key Management System architecture

A Key Management System governs key lifecycle activities such as generation, activation, distribution, versioning, rotation, revocation, archival, destruction, access policy, recovery, and audit across applications and environments.

Example: Define generation, activation, distribution, versioning, rotation, revocation, archival, destruction, recovery, access policy, and audit across environments.

Counterexample: Use the KMS only as a secret store and leave activation, versioning, rotation, revocation, and destruction undefined. | Grant one shared KMS role across applications and environments to simplify key access, leaving lifecycle gaps. | Rotate keys without planning data re-encryption, rollback, recovery, or audit evidence, deferring architecture constraints.

HSM versus KMS

An HSM is primarily a protected cryptographic execution and key-storage boundary; a KMS is a lifecycle-management service or architecture and may use an HSM underneath. Neither term implies complete authorization, application security, or operational governance by itself.

Example: Use an HSM as a protected execution and storage boundary and a KMS for lifecycle governance, allowing the KMS to rely on an HSM where appropriate.

Counterexample: Use an HSM as the complete key lifecycle service and omit policy, rotation, archival, and destruction workflows, which overstates what the technology or certification can prove. | Use a KMS as proof that private keys always execute inside a high-assurance hardware boundary, leaving trust anchors, privileged operation, support, and replacement risk unexamined. | Deploy both products but leave application authorization, ownership, recovery, and audit responsibilities unassigned, deferring configuration and lifecycle decisions to deployment teams without constraints.

Perform threat modeling

Threat modeling systematically identifies assets, actors, trust boundaries, attack paths, threats, assumptions, mitigations, and residual risk during design and when material changes occur.

Example: Identify assets, actors, trust boundaries, attack paths, threats, assumptions, mitigations, and residual risk during design and when material changes occur.

Counterexample: Give every imaginable threat to threat modeling equal priority regardless of relevance, which treats one input as complete analysis. | Treat the automated tool report for threat modeling as complete without multidisciplinary review, leaving assets, preconditions, and attack paths incomplete. | Move requirement-level abuse cases for threat modeling directly into tests without architectural expansion, deferring architecture-specific threat analysis to testing or incident response.

Threat-model scope and system decomposition

Effective modeling establishes scope, diagrams components and data flows, identifies entry points and privileges, and records external dependencies before enumerating threats.

Example: Identify entry points and privileges, and records external dependencies before enumerating threats.

Counterexample: Use one severity score as the complete threat and business-risk analysis. | List generic threats without decomposing components, entry points, privileges, trust boundaries, and data flows. | Defer architectural threat analysis until testing and assume discovered vulnerabilities reveal every attack path.

Threat modeling methodologies

Methodologies structure analysis and improve repeatability. Selection should match system type, objective, available information, and team skill; no single method is universally best.

Example: Match system type, objective, available information, and team skill, no single method is universally best.

Counterexample: Treat a generic checklist as a completed threat model without system decomposition or attack-path analysis. | Score vulnerabilities without modeling attacker goals, preconditions, attack paths, or business impact, leaving paths incomplete. | Treat a clean scanner result as proof that the relevant threats and attack paths are controlled.

STRIDE

STRIDE prompts analysis of Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It is often applied to data-flow elements and trust boundaries.

Example: Apply spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege to relevant data-flow elements and trust boundaries.

Counterexample: Accept tool-generated findings without validating scope, assumptions, relevance, or completeness, which treats one score, method, or data source as complete analysis. | Copy a prior threat model despite changed identity, deployment, data flows, and dependencies, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Choose mitigations before defining assets, actors, trust boundaries, and attack paths, deferring architecture-specific threat analysis to testing or incident response.

PASTA

Process for Attack Simulation and Threat Analysis is a risk-centric methodology that links business impact, technical scope, decomposition, threat analysis, vulnerability analysis, attack modeling, and risk treatment.

Example: Use PASTA as a risk-centric methodology that links business impact, technical scope, decomposition, threat analysis, vulnerability analysis, attack modeling, and risk treatment.

Counterexample: Give every imaginable threat equal priority regardless of system exposure, assets, or adversary relevance, which treats one input as complete analysis. | Enumerate attack techniques without selecting mitigations, owners, or residual-risk treatment, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Use one threat-modeling method regardless of the system type, objective, evidence, or team skill, deferring architecture-specific threat analysis to testing or incident response.

Hybrid Threat Modeling Method

Hybrid methods combine compatible techniques to gain complementary coverage, such as asset-centric, attacker-centric, and software-centric analysis. The combined method should remain documented and repeatable.

Example: Combine compatible techniques in a documented and repeatable method that reconciles asset, attacker, and software perspectives.

Counterexample: Use one severity score as the complete threat and business-risk analysis, which oversimplifies risk. | Use threat intelligence for the hybrid method without checking relevance, confidence, timeliness, or actionability, leaving paths incomplete. | Treat threat-intelligence predictions about the hybrid method as certain, deferring architecture-specific threat analysis to testing or incident response.

CVSS in the threat-modeling list

The official outline lists CVSS under threat-modeling methodologies. CVSS is primarily a vulnerability severity scoring system and can support prioritization, but it is not a complete threat-modeling methodology.

Example: Use CVSS only as vulnerability-severity input, combining it with assets, attack paths, likelihood, business impact, controls, and residual risk.

Counterexample: Use the highest CVSS score as the direct business-risk value, which oversimplifies risk. | Treat CVSS as a complete method for discovering assets, actors, trust boundaries, and attack paths, leaving paths incomplete. | Prioritize every high-severity weakness equally without considering reachability, controls, or business impact, deferring threat analysis.

Limitations: Do not treat CVSS score alone as business risk, exploit likelihood, or a substitute for threat modeling.

Data-flow diagrams for threat modeling

Data-flow diagrams commonly show external entities, processes, data stores, flows, and trust boundaries. They help teams reason about where threats and controls apply.

Example: Document external entities, processes, data stores, flows, and trust boundaries so threats and controls can be placed against the architecture.

Counterexample: Adopt tool-generated findings without validating scope, assumptions, relevance, or completeness, which treats one score, method, or data source as complete analysis. | Keep unused interfaces and compensate only with monitoring rather than removing exposure, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Keep the original threat model after material changes to identity, data, deployment, or dependencies, deferring threat analysis to testing.

Attack trees and attack graphs

Attack trees decompose an attacker goal into alternative and combined steps. Attack graphs model paths through states or vulnerabilities. Both support path analysis and control placement.

Example: Model alternative and combined attacker steps or reachable compromise states, then place controls where they break the highest-value paths.

Counterexample: Give every imaginable threat equal priority regardless of system exposure, assets, or adversary relevance, which oversimplifies risk. | Treat an automated report as complete without multidisciplinary review or assumption validation, leaving assets, preconditions, and attack paths incomplete. | Move requirement-level abuse cases directly into tests without expanding them through architecture and attack paths, deferring threat analysis to testing.

Misuse and abuse cases as threat-model inputs

Misuse and abuse cases from requirements work provide attacker goals and negative scenarios. Threat modeling expands them using architecture, data flow, trust boundaries, and concrete attack paths.

Example: Expand requirement-level adverse scenarios across components, data flows, trust boundaries, concrete attack paths, mitigations, and residual risk.

Counterexample: Use one severity score as the complete threat and business-risk analysis, which oversimplifies risk. | List generic threats without decomposing components, entry points, privileges, trust boundaries, and data flows, leaving paths incomplete. | Defer architectural threat analysis until testing and assume discovered vulnerabilities reveal every attack path, deferring threat analysis.

Tradeoffs: Domain 3 develops requirement-level misuse and abuse cases; Domain 4 performs architectural threat modeling.

Common threats

Common threats provide reusable categories but must be filtered for relevance and credibility in the specific architecture.

Example: Filter reusable threat categories for relevance and credibility against the actual architecture, assets, exposure, and adversaries.

Counterexample: Treat a generic checklist as a completed threat model without system decomposition or attack-path analysis. | Score vulnerabilities without modeling attacker goals, preconditions, attack paths, or business impact, leaving paths incomplete. | Treat a clean scanner result as proof that the relevant threats and attack paths are controlled.

Advanced persistent threat

APT scenarios involve capable, persistent adversaries using multiple stages and long dwell time. Architecture should assume credential compromise, stealth, lateral movement, and repeated attempts where relevant.

Example: Assume credential compromise, stealth, lateral movement, and repeated attempts where relevant.

Counterexample: Accept tool-generated findings without validating scope, assumptions, relevance, or completeness, which oversimplifies risk. | Copy a prior threat model despite changed identity, deployment, data flows, and dependencies. | Choose mitigations before defining assets, actors, trust boundaries, and attack paths, deferring threat analysis.

Insider threat

Insiders may have legitimate access, knowledge, and trust. Architecture should use least privilege, separation of duties, monitoring, data controls, and approval workflows without assuming all insiders are malicious.

Example: Use least privilege, separation of duties, monitoring, data controls, and approval workflows without assuming all insiders are malicious.

Counterexample: Assign every imaginable threat equal priority regardless of system exposure, assets, or adversary relevance, which oversimplifies risk. | Enumerate attack techniques without selecting mitigations, owners, or residual-risk treatment, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Use one threat-modeling method regardless of the system type, objective, evidence, or team skill, deferring threat analysis to testing.

Common malware

Malware threats include ransomware, trojans, spyware, worms, and malicious scripts. Architecture should reduce execution opportunities, privilege, persistence, propagation, and recovery impact.

Example: Reduce execution opportunities, privilege, persistence, propagation, and recovery impact.

Counterexample: Use one severity score as the complete threat and business-risk analysis. | Use threat intelligence for the malware scenario without checking relevance, confidence, timeliness, or actionability. | Treat threat-intelligence predictions about the malware scenario as certain, deferring threat analysis.

Third-party supplier threats

Suppliers can introduce compromised components, services, updates, credentials, or support paths. Architecture must constrain third-party access and failure propagation.

Example: Constrain third-party access and failure propagation.

Counterexample: Treat a generic checklist as a completed threat model without system decomposition or attack-path analysis. | Model only external attackers against the supplier attack path and omit insiders, suppliers, and compromised workloads. | Leave residual risk for the supplier attack path implicit after listing controls.

Tradeoffs: Supplier evaluation, provenance, and contractual assurance are primarily Domain 8.

Attack surface evaluation

Attack-surface evaluation identifies reachable interfaces, exposed functionality, privileges, data, dependencies, and trust transitions. The objective is to reduce unnecessary exposure and prioritize high-value paths.

Example: Identify reachable interfaces, exposed functionality, privileges, data, dependencies, and trust transitions.

Counterexample: Adopt tool-generated findings without validating scope, assumptions, relevance, or completeness, which oversimplifies risk. | Keep unused interfaces and compensate only with monitoring rather than removing exposure, leaving paths incomplete. | Keep the original threat model after material changes to identity, data, deployment, or dependencies.

Attack-surface reduction

Reduce unnecessary services, endpoints, protocols, privileges, data, code, dependencies, and administrative paths. Removal is often stronger than adding compensating controls around unused capability.

Example: Remove unnecessary services, endpoints, protocols, privileges, data, code, dependencies, and administrative paths before adding compensating controls.

Counterexample: Give every imaginable threat equal priority regardless of system exposure, assets, or adversary relevance. | Treat an automated report as complete without multidisciplinary review or assumption validation, leaving attack paths incomplete. | Move requirement-level abuse cases directly into tests without expanding them through architecture and attack paths, deferring threat analysis.

Threat analysis

Threat analysis evaluates attacker capability, intent, opportunity, attack path, preconditions, likelihood, impact, existing controls, and residual exposure.

Example: Evaluate attacker capability, intent, opportunity, preconditions, attack path, likelihood, impact, existing controls, and residual exposure.

Counterexample: Use one severity score as the complete assessment of attacker capability, likelihood, and business impact. | List generic threats without decomposing components, entry points, privileges, trust boundaries, and data flows. | Defer architecture-stage analysis until testing and assume discovered vulnerabilities reveal every attack path, deferring the assessment.

Threat versus vulnerability versus risk

A threat is a potential cause of harm; a vulnerability is a weakness; risk reflects uncertainty about adverse impact considering threats, vulnerabilities, assets, and controls.

Example: Record the threat as a potential cause of harm, the vulnerability as a weakness, and risk as uncertain adverse impact in context.

Counterexample: Call the software weakness a threat and use its severity as the complete business risk, which treats one input as complete analysis. | Treat the adversary’s capability as a vulnerability even when no exploitable weakness is identified, leaving assets, preconditions, and attack paths incomplete. | Record a risk without the affected asset, credible threat, vulnerability, impact, or control context, deferring threat analysis to testing.

Limitations: Do not use threat, vulnerability, and risk as interchangeable terms.

Threat intelligence

Threat intelligence supplies evidence about adversaries, techniques, campaigns, vulnerabilities, targeting, and trends. It should be evaluated for relevance, timeliness, confidence, and actionability.

Example: Evaluate intelligence for relevance, timeliness, confidence, and actionability before changing the architecture.

Counterexample: Use tool-generated findings without validating scope, assumptions, relevance, or completeness, which oversimplifies risk. | Copy a prior threat model despite changed identity, deployment, data flows, and dependencies, leaving paths incomplete. | Choose mitigations before defining assets, actors, trust boundaries, and attack paths, deferring threat analysis.

Identify credible relevant threats

Architecture teams should prioritize threats that plausibly apply to the system, assets, sector, exposure, and adversary landscape rather than attempt equal treatment of every imaginable threat.

Example: Prioritize threats that plausibly apply to the system, assets, sector, exposure, and adversary landscape rather than attempt equal treatment of every imaginable threat.

Counterexample: Assign every imaginable threat equal priority regardless of system exposure, assets, or adversary relevance, which treats one input as complete analysis. | Enumerate attack techniques without selecting mitigations, owners, or residual-risk treatment, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Use one threat-modeling method regardless of the system type, objective, evidence, or team skill, deferring architecture-specific threat analysis to testing or incident response.

Predictive use of threat intelligence

Threat intelligence can inform anticipated attack paths and future controls, but predictions contain uncertainty and should not be treated as deterministic forecasts.

Example: Use the intelligence as uncertain input to plausible attack paths and future controls, documenting confidence rather than treating it as a forecast.

Counterexample: Treat one campaign forecast as certainty and redesign the system around that single prediction, which treats one input as complete analysis. | Ignore confidence and relevance because recent intelligence is automatically actionable, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Use threat-intelligence volume as the priority instead of plausible attack paths and business exposure, deferring architecture-specific threat analysis to testing or incident response.

Mitigation selection and residual risk

Mitigations should break attack paths, reduce likelihood or impact, improve detection or recovery, and be traceable to threats. Remaining exposure must be documented and owned.

Example: Break attack paths, reduce likelihood or impact, improve detection or recovery, and be traceable to threats.

Counterexample: Treat a generic checklist as a completed threat model without system decomposition or attack-path analysis. | Model only external attackers against the mitigation plan and omit insiders, suppliers, and compromised workloads. | Leave residual risk for the mitigation plan implicit after listing controls, deferring threat analysis.

Threat-model maintenance

Update threat models after material changes to architecture, data, identity, dependencies, deployment, threats, or incidents. A static model becomes stale as the system evolves.

Example: Refresh the model after material changes to architecture, data, identity, dependencies, deployment, threats, or incidents.

Counterexample: Adopt tool-generated findings without validating scope, assumptions, relevance, or completeness, which treats one input as complete analysis. | Keep unused interfaces and compensate only with monitoring rather than removing exposure, leaving attack paths incomplete. | Keep the original threat model after material changes to identity, data, deployment, or dependencies, deferring threat analysis.

Threat-model quality and facilitation

A high-quality model uses diverse participants, clear scope, evidence, documented assumptions, actionable mitigations, and review. Tool output alone is not a completed threat model.

Example: Use diverse participants, clear scope, evidence, documented assumptions, actionable mitigations, and review.

Counterexample: Assign equal priority to every imaginable threat regardless of system exposure, assets, or adversary relevance. | Treat an automated report as complete without multidisciplinary review or assumption validation, leaving paths incomplete. | Move requirement-level abuse cases directly into tests without expanding them through architecture and attack paths.

Method-neutral threat-modeling four-question framework

A practical threat-modeling cycle asks: What are we working on? What can go wrong? What will we do about it? Did we do a good enough job? These questions map to system decomposition, threat identification, mitigation, and review while allowing iteration as the system changes.

Example: Use the four questions iteratively to decompose the system, identify threats, select mitigations, and review adequacy without presenting them as the only valid method.

Counterexample: Treat the four questions as the only valid method and execute them once without iteration, which treats one input as complete analysis. | List generic threats without decomposing components, entry points, privileges, trust boundaries, and data flows, leaving relevant assets, preconditions, attack paths, and mitigations unexamined. | Defer architectural threat analysis until testing and assume discovered vulnerabilities reveal every attack path, deferring architecture-specific threat analysis to testing or incident response.

Limitations: The four-question framework is method-neutral guidance, not the only valid threat-modeling sequence.

OCTAVE

OCTAVE is an asset- and organizational-risk-oriented approach that examines critical information assets, operational context, threats, vulnerabilities, and risk-management priorities. It is broader than application-centric DFD analysis and can inform architectural risk decisions.

Example: Use OCTAVE for asset- and organizational-risk analysis that links critical information assets, operational context, threats, vulnerabilities, and treatment priorities.

Counterexample: Describe OCTAVE as a purely technical data-flow method that is universally superior to other approaches, which oversimplifies risk. | Score vulnerabilities without modeling attacker goals, preconditions, attack paths, or business impact, leaving attack paths incomplete. | Treat a clean scanner result as proof that the relevant threats and attack paths are controlled.

Limitations: Do not describe OCTAVE as purely nontechnical or universally superior to STRIDE, PASTA, or other methods.

Perform architectural risk assessment and design reviews

Architectural risk assessment and design review evaluate whether the proposed architecture satisfies requirements, addresses credible threats, uses acceptable trust assumptions, and leaves manageable residual risk.

Example: Use acceptable trust assumptions, and leaves manageable residual risk.

Counterexample: Review architectural risk assessment and design reviews only on the annual calendar despite material changes. | Apply the same review depth to architectural risk assessment and design reviews regardless of criticality, exposure, novelty, or safety impact. | Let the architecture reviewer approve exceptions for architectural risk assessment and design reviews without business authority.

Architecture review inputs

Inputs include requirements, diagrams, data classifications, threat models, control mappings, technology evaluations, deployment assumptions, prior findings, and relevant standards.

Example: Require requirements, diagrams, data classifications, threat models, control mappings, technology evaluations, deployment assumptions, findings, and applicable standards.

Counterexample: Make the independent reviewer solely accountable for security of the review evidence set, which exceeds review authority. | Use independent review for the review evidence set but remove accountability from the design team, leaving disposition unclear. | Close the review evidence set findings when a ticket is created rather than when treatment is verified, deferring risk authority.

Architecture review criteria

Criteria may include least privilege, complete mediation, isolation, resilience, secure defaults, attack-surface minimization, cryptographic design, observability, recoverability, privacy, and supportability.

Example: Evaluate least privilege, complete mediation, isolation, resilience, secure defaults, attack surface, cryptography, observability, recovery, privacy, and supportability.

Counterexample: Let the architect accept the residual risk associated with the review criteria, which exceeds review authority. | Close the review criteria decision without recording alternatives, rationale, assumptions, or consequences, leaving finding ownership unclear. | Wait for the annual review to revisit the review criteria after material changes, deferring risk disposition without authority.

Risk-based review depth

Review rigor should scale with criticality, exposure, novelty, data sensitivity, safety impact, regulatory obligation, and architectural change. High-risk systems may require independent expertise or formal assurance.

Example: Scale with criticality, exposure, novelty, data sensitivity, safety impact, regulatory obligation, and architectural change.

Counterexample: Treat a clean review checklist as proof that the review depth is secure. | Retain the prior the review depth approval after a material identity, supplier, or deployment change. | Use one diagram as complete evidence.

Design-review findings and disposition

Findings should identify affected assets and requirements, severity, evidence, recommended treatment, owner, due date, status, exception, and verification expectations.

Example: Identify affected assets and requirements, severity, evidence, recommended treatment, owner, due date, status, exception, and verification expectations.

Counterexample: Review the review finding only on the annual calendar despite material changes, which gives the reviewer excessive authority. | Let the reviewer accept business risk for the review finding without the authorized risk owner, leaving finding ownership unclear. | Treat independent review of the finding as sufficient and eliminate design-team accountability, deferring risk disposition without authority.

Independent review

Independence can reduce confirmation bias and conflicts of interest. The required degree depends on risk, regulation, and assurance objectives.

Example: Use risk-appropriate independent expertise to reduce confirmation bias while retaining the design team’s accountability for security.

Counterexample: Transfer all security accountability from the design team to the independent assessor, which exceeds review authority. | Use security testing results as a substitute for architectural reasoning about the design under review, leaving disposition unclear. | Defer architecture decision records until after implementation, deferring a material architecture-risk decision without documented authority.

Limitations: Independent review does not eliminate the design team’s accountability for security.

Architecture decision records

Architecture decision records document context, options, decision, rationale, assumptions, trade-offs, and consequences. Security-significant decisions should remain traceable and revisitable.

Example: Keep security-significant decisions traceable and revisitable by recording context, options, rationale, assumptions, trade-offs, and consequences.

Counterexample: Let the architect accept the residual risk associated with the decision record, which exceeds review authority. | Approve the decision record from the diagram alone without tracing requirements, threats, assumptions, controls, and findings. | Use a clean design-review checklist as proof that implemented the decision record behavior passed validation, deferring risk authority.

Risk acceptance and design authority

Reviewers identify and communicate risk; an authorized business or system risk owner accepts residual risk at the appropriate level.

Example: Have reviewers communicate the residual exposure and obtain acceptance from the authorized business or system risk owner.

Counterexample: Let the architect accept material business risk because the architecture diagram is technically complete, which exceeds review authority. | Let the assessor approve the residual risk because the assessor identified the weakness, leaving disposition unclear. | Close the finding when a remediation ticket is created without an authorized acceptance decision.

Limitations: An architect or assessor should not silently accept material business risk merely by approving a diagram.

Review triggers

Reviews should be triggered by major architecture, data, identity, trust, technology, deployment, supplier, threat, or regulatory changes—not only by calendar milestones.

Example: Trigger review after material changes to architecture, data, identity, trust, technology, deployment, suppliers, threats, or regulations.

Counterexample: Review the review schedule only on the annual calendar despite material changes, which exceeds review authority. | Apply the same review depth to the review schedule regardless of criticality, exposure, novelty, or safety impact, leaving disposition unclear. | Let the architecture reviewer approve exceptions for the review schedule without business authority, deferring risk authority.

Model non-functional security properties and constraints

Architecture models measurable security qualities and constraints such as confidentiality, integrity, availability, privacy, resilience, performance under controls, auditability, scalability, and recovery behavior.

Example: Model measurable confidentiality, integrity, availability, privacy, resilience, performance, auditability, scalability, and recovery conditions.

Counterexample: State non-functional security properties and constraints as a broad aspiration without measurable conditions or evidence. | Assume a dependency supporting non-functional security properties and constraints is always available and trustworthy. | Use encryption as the complete architecture for non-functional security properties and constraints, deferring property definition.

Security property model

A property model states the protected asset, required property, operating condition, failure condition, threshold or invariant, and method of verification.

Example: State the protected asset, required property, operating and failure conditions, threshold or invariant, and planned verification method.

Counterexample: Treat encryption alone as complete modeling of the required security property, which overstates proof. | Model normal operation for the property model but omit overload, degraded modes, and recovery behavior, leaving properties undefined. | Assume redundancy guarantees the availability and recovery objectives of the property model, deferring property definition to testing.

Confidentiality and information-flow constraints

Models may specify who or what can observe data, permitted flows, classification boundaries, aggregation limits, and conditions for release or declassification.

Example: Define who can observe data, permitted information flows, classification boundaries, aggregation limits, and release or declassification conditions.

Counterexample: Disable mandatory controls when performance pressure affects the information-flow constraints, which treats one mechanism as complete proof. | Choose a formal method for the information-flow constraints without considering risk, feasibility, or the property being assured. | Ignore environmental assumptions when claiming guarantees, deferring property definition.

Integrity invariants

Integrity constraints define conditions that must remain true, such as authorized state transitions, transaction balance, immutability of audit events, or valid provenance.

Example: Define conditions that must remain true, including authorized state transitions, transaction balance, immutable audit events, and valid provenance.

Counterexample: Treat redundancy alone as complete assurance, which treats one mechanism as complete proof. | Claim privacy protection for the integrity invariant without minimization, purpose separation, or deletion propagation, leaving the property undefined. | Model the integrity invariant without a traceable source requirement, deferring an architecture-stage property and evidence decision to the test team.

Availability, resilience, and capacity constraints

Architecture should model tolerated failures, redundancy, recovery objectives, overload behavior, dependency availability, degraded modes, and denial-of-service resistance.

Example: Model tolerated failures, redundancy, recovery objectives, overload behavior, dependency availability, degraded modes, and denial-of-service resistance.

Counterexample: State the resilience model as a broad aspiration without measurable conditions or evidence. | Model the resilience model qualitatively without identifying the asset, operating condition, threshold, or failure state, leaving properties undefined. | Choose one technology for the resilience model before defining the required property and operating conditions, deferring property definition.

Performance-security trade-offs

Encryption, validation, logging, isolation, and policy evaluation consume resources. The architecture must meet security and performance objectives without disabling controls under load.

Example: Meet security and performance objectives without disabling controls under load.

Counterexample: Treat encryption alone as complete modeling of the required security property. | Define the latency and control trade-off without tracing it to requirements, controls, decisions, and planned evidence. | Defer measurable verification planning for the latency and control trade-off to the test team.

Limitations: Performance concerns do not justify bypassing mandatory controls without approved risk treatment.

Privacy and data-minimization constraints

Models can constrain collection, precision, retention, linkability, processing location, third-party sharing, and inference risk across architectural components.

Example: Constrain collection, precision, retention, linkability, processing location, sharing, and inference risk across components.

Counterexample: Disable mandatory controls when performance pressure affects the privacy constraints, which overstates proof. | Ignore aggregation and permitted-flow constraints when modeling the privacy constraints, leaving properties undefined. | Treat a normal-path demonstration as sufficient evidence.

Formal methods and state models

State machines, invariants, model checking, information-flow models, and formal specification can provide stronger assurance for critical properties when justified by risk and feasibility.

Example: Use state machines, invariants, model checking, information-flow models, or formal specification where critical risk and feasibility justify stronger assurance.

Counterexample: Treat redundancy alone as complete assurance, which treats one mechanism as complete proof. | Preserve performance for the formal state model by disabling mandatory controls under load, leaving the operating condition, threshold, and invariant undefined. | Allow performance pressure to override mandatory the formal state model constraints without risk treatment, deferring property definition to testing.

Assumptions, constraints, and guarantees

Architecture should distinguish environmental assumptions, design constraints, and guarantees supplied by components. Invalid assumptions are a common source of systemic failure.

Example: Distinguish environmental assumptions, design constraints, and guarantees supplied by components.

Counterexample: State the assumption and guarantee set as a broad aspiration without measurable conditions or evidence. | Assume a dependency supporting the assumption and guarantee set is always available and trustworthy. | Use encryption as the complete architecture.

Constraint traceability and verification planning

Each modeled property should trace to requirements, design decisions, controls, and planned verification evidence.

Example: Trace to requirements, design decisions, controls, and planned verification evidence.

Counterexample: Treat encryption alone as complete modeling of the required security property. | Model normal operation for the traceability plan but omit overload, degraded modes, and recovery behavior. | Assume redundancy guarantees the availability and recovery objectives of the traceability plan.

Tradeoffs: Domain 4 models the property; Domain 6 executes testing and validation against it.

Privacy and data protection by design and by default

Architecture should embed privacy early and use protective defaults. Relevant design outcomes include data minimization, purpose separation, pseudonymization, retention enforcement, controlled secondary use, user-rights workflows, access segregation, deletion propagation, and auditable data flows.

Example: Embed minimization, purpose separation, protective defaults, retention enforcement, controlled secondary use, rights workflows, and deletion propagation in the architecture.

Counterexample: Use encryption as the only privacy architecture and retain all collected personal data indefinitely, which overstates proof. | Enable broad secondary use by default and rely on users to locate an opt-out later, leaving properties undefined. | Implement deletion only in the primary database while leaving replicas, caches, and restored backups unchanged, deferring property definition.

Limitations: Privacy by design is not satisfied merely by encrypting personal data.

Tradeoffs: Domain 2 governs the privacy process, Domain 3 defines privacy requirements, Domain 4 realizes them in architecture, and Domain 7 operates retention and deletion controls.

Define secure operational architecture

Secure operational architecture defines how the system is deployed, administered, observed, scaled, updated, recovered, and integrated with operational security services.

Example: Define how the system is deployed, administered, observed, scaled, updated, recovered, and integrated with operational security services.

Counterexample: Treat successful backups as proof of recoverability for secure operational architecture, which assumes placement establishes operational trust. | Ignore incidents and capacity failures when maintaining the architecture for secure operational architecture, leaving privileged paths, observability, and recovery unclear. | Keep the architecture for secure operational architecture unchanged after repeated operational failures, deferring operational design until deployment.

Deployment topology

Topology defines environments, regions, zones, networks, clusters, nodes, data stores, and communication paths. Security architecture uses topology to enforce segmentation, resilience, data-location, and management boundaries.

Example: Define environments, regions, zones, networks, clusters, nodes, data stores, and communication paths.

Counterexample: Defer ownership and recovery decisions for the regional and network layout until after deployment. | Draw regions, zones, and nodes but omit operational identity, ownership, telemetry, and recovery paths. | Assume operators will invent safe rollout and recovery behavior after the topology is approved.

Operational interfaces

Operational interfaces include administration, monitoring, support, backup, deployment, and recovery paths. They require explicit identities, authorization, logging, availability, and emergency-access design.

Example: Require explicit identities, authorization, logging, availability, and emergency-access design for administration, monitoring, support, backup, deployment, and recovery paths.

Counterexample: Treat a topology diagram as complete operational architecture without ownership, recovery, or observability design, which assumes operational trust. | Use the same credentials and network paths for administrative and workload operations, leaving operational ownership unclear. | Defer protection of administrative and recovery paths until production hardening, deferring recovery, ownership, and operational control design until after deployment.

CI/CD architecture

CI/CD architecture should separate duties and environments, protect source and secrets, control runners and plugins, verify artifacts, enforce gates, preserve provenance, and restrict production deployment authority.

Example: Separate duties and environments, protect source and secrets, control runners and plugins, verify artifacts, enforce gates, preserve provenance, and restrict production deployment authority.

Counterexample: Use zero-trust terminology as a reason to remove segmentation and resilience, which assumes topology or terminology establishes operational trust. | Copy production data and secrets into lower environments to simplify the delivery pipeline, leaving privileged paths, observability, and recovery unclear. | Treat successful deployment of the delivery pipeline as proof that rollback and recovery work, deferring operational design until deployment.

Tradeoffs: Domain 4 defines pipeline architecture; Domains 5 and 7 implement and operate build and release controls.

Environment separation

Development, test, staging, and production environments should have defined trust, data, identity, connectivity, and promotion boundaries. Production secrets and data should not flow casually into lower environments.

Example: Have defined trust, data, identity, connectivity, and promotion boundaries.

Counterexample: Treat successful backups as proof of recoverability. | Design the environment boundaries for deployment but omit rollback, regional failure, and dependency failure. | Let each environment use unrelated identity and promotion rules.

Management-plane and data-plane separation

Separating management and workload paths reduces exposure and allows stronger controls for privileged actions. The separation must exist in identity, network, logging, and operational policy—not only diagrams.

Example: Exist in identity, network, logging, and operational policy—not only diagrams.

Counterexample: Defer ownership and recovery design for the management/data-plane boundary until after deployment. | Collect telemetry for the management/data-plane boundary without protected transport, stable identity, time, or privacy controls. | Rely on perimeter location rather than explicit verification.

Observability architecture

Logs, metrics, traces, and security events should be designed into components with protected transport, consistent identity and time, privacy controls, retention, and actionable context.

Example: Design logs, metrics, traces, and security events into components with protected transport, consistent identity and time, privacy controls, retention, and actionable context.

Counterexample: Treat a topology diagram as complete operational architecture without ownership, recovery, or observability design, which assumes placement establishes operational trust. | Use long-lived shared secrets for the observability design without workload identity or rotation, leaving privileged paths, observability, and recovery unclear. | Defer secret rotation and break-glass design for the observability design to incident response, deferring recovery, ownership, and operational control design until after deployment.

Secrets and key architecture

Operational architecture should centralize or govern secret issuance, workload identity, short-lived credentials, key rotation, access policy, break-glass use, and auditability.

Example: Centralize or govern secret issuance, workload identity, short-lived credentials, key rotation, access policy, break-glass use, and auditability.

Counterexample: Use zero-trust terminology as a reason to remove segmentation and resilience, which assumes operational trust. | Assign controls for the secret and key design without runbooks or accountable operational owners, leaving operations incomplete. | Collect logs for the secret and key design without architectural context or ownership, deferring operational design.

Resilient deployment and recovery architecture

Design should support safe rollout, rollback, redundancy, backup, restoration, region or zone failure, dependency failure, and known degraded modes.

Example: Support safe rollout, rollback, redundancy, backup, restoration, region or zone failure, dependency failure, and known degraded modes.

Counterexample: Treat successful backups as proof of recoverability, which assumes operational trust. | Ignore incidents and capacity failures when maintaining the architecture, leaving operational ownership unclear. | Keep the architecture for the deployment and recovery design unchanged after repeated operational failures, deferring operational design.

Zero-trust operational architecture

Zero Trust applies explicit verification, least privilege, device or workload context, policy enforcement, and continuous evaluation across operational communications. It does not eliminate the need for segmentation or resilience.

Example: Apply explicit verification, least privilege, context, policy enforcement, and continuous evaluation while retaining segmentation and resilience.

Counterexample: Remove segmentation because every request is explicitly verified by a policy service, which assumes operational trust. | Grant broad standing privileges after device verification and stop continuous evaluation, leaving privileged paths, observability, and recovery unclear. | Depend on one policy engine without resilient failure behavior or constrained management access, deferring operational design until deployment.

Operational ownership and runbooks

Architecture should define who operates controls, handles alerts, rotates credentials, approves changes, restores service, and maintains dependencies. Runbooks operationalize architectural assumptions.

Example: Define who operates controls, handles alerts, rotates credentials, approves changes, restores service, and maintains dependencies.

Counterexample: Treat a topology diagram as complete operational architecture without ownership, recovery, or observability design. | Use the same credentials and paths for management and workload operations involving the operational ownership model. | Defer management-plane protection for the operational ownership model until production hardening, deferring operational design until deployment.

Architecture-to-operations feedback

Operational incidents, telemetry, capacity limits, and control failures should feed architecture updates and threat models.

Example: Feed architecture updates and threat models.

Counterexample: Use zero-trust terminology as a reason to remove segmentation and resilience. | Copy production data and secrets into lower environments to simplify the architecture feedback loop. | Treat successful deployment of the architecture feedback loop as proof that rollback and recovery work.

Tradeoffs: Domain 7 executes monitoring and incident response; Domain 4 incorporates operational realities into architecture.

Decouple core application logic from unpredictable AI inference engines

Architect AI-integrated systems so probabilistic inference components cannot directly redefine deterministic business rules, authorization, safety constraints, or system-of-record state.

Example: Keep deterministic business rules, authorization, safety constraints, and system-of-record updates outside direct model control.

Counterexample: Allow model output to rewrite authorization rules when the model reports high confidence, which assumes determinism. | Let the model update system-of-record state directly and use logging as the only safeguard, leaving boundaries incomplete. | Embed deterministic business rules in the prompt so the inference service becomes the final policy authority.

Policy enforcement outside the model

Use deterministic policy engines, schemas, allowlists, authorization services, transaction limits, and approval workflows around model outputs and tool calls.

Example: Constrain model outputs and tool calls with deterministic authorization, schemas, allowlists, transaction limits, and approval workflows.

Counterexample: Use a system prompt as the only restriction on tool names, parameters, and transaction limits. | Let the model approve its own exceptions when an action does not match the allowlist, leaving boundaries incomplete. | Validate the model response format but skip independent authorization of the requested operation, deferring deterministic control to model behavior.

Limitations: Natural-language instructions inside a prompt are not a reliable authorization boundary.

Zero Trust boundaries around vector databases

Treat vector stores as sensitive data systems. Apply explicit workload identity, authorization, tenant isolation, data classification, retrieval filters, encryption, logging, and controlled ingestion.

Example: Require workload identity, tenant-aware authorization, classification, retrieval filters, protected ingestion, encryption, and logging for the vector store.

Counterexample: Use one shared vector index for every tenant and filter results from a tenant value in the prompt. | Allow ingestion from any document source because retrieval is read-only, leaving AI trust boundaries incomplete. | Grant the inference service unrestricted vector-store access and rely on output filtering to protect privacy, deferring external control.

AI processing-cluster boundaries

AI processing clusters require segmented management planes, protected model and data access, workload isolation, secrets control, telemetry, capacity protection, and constrained egress.

Example: Separate management planes, isolate workloads, protect model and data access, govern secrets and egress, and add telemetry and capacity controls.

Counterexample: Allow probabilistic model output to change authoritative state without deterministic validation, which treats model behavior as deterministic. | Observe the AI processing cluster without recording model, policy, context, tool, confidence, or refusal information, leaving boundaries incomplete. | Treat AI-generated threats about the AI processing cluster as complete without expert review, deferring external control.

AI-driven threat modeling

AI may assist with attack-surface mapping, scenario generation, and model maintenance, but human reviewers must validate scope, assumptions, relevance, and mitigations.

Example: Use AI to propose attack surfaces and scenarios, then require human validation of scope, assumptions, relevance, mitigations, and completeness.

Counterexample: Accept every AI-generated threat as credible and add all proposed controls to the baseline, which treats model behavior as deterministic. | Use the model output without validating architecture scope, trust boundaries, assumptions, or mitigations, leaving model, data, tool, and policy boundaries incomplete. | Replace multidisciplinary threat-model review with a single automated generation run, deferring authorization and fallback decisions to probabilistic model behavior.

Limitations: Do not treat AI-generated threats as authoritative or complete without expert validation.

Adapt SABSA for probabilistic AI behavior

Business-driven architecture should account for uncertain outputs, model drift, confidence, bias, human oversight, model and data supply chains, and non-deterministic failure modes.

Example: Account for uncertain outputs, model drift, confidence, bias, human oversight, model and data supply chains, and non-deterministic failure modes.

Counterexample: Use prompt instructions as the sole control, which treats model behavior as deterministic. | Treat the business-driven AI architecture as one trusted service that combines model, data, retrieval, tools, and policy, leaving boundaries incomplete. | Allow probabilistic output from the business-driven AI architecture to change authoritative state and monitor errors afterward, deferring deterministic control to model behavior.

Federated learning architecture

Federated learning distributes training across nodes while aggregating updates. Architecture must address participant identity, poisoning, privacy leakage, secure aggregation, update validation, availability, and untrusted clients.

Example: Authenticate participants, validate and aggregate updates securely, limit poisoning and privacy leakage, and design for untrusted clients and availability.

Counterexample: Accept every signed participant update without checking poisoning, quality, or privacy leakage, which treats model behavior as deterministic. | Aggregate raw updates centrally and retain them indefinitely because the model is federated, leaving AI trust boundaries incomplete. | Use one participant credential for the fleet and omit client isolation, availability, and update validation, deferring deterministic control to model behavior.

High-volume message queuing for inference

Inference pipelines may require queues for scale and decoupling. Security must cover prompt and response confidentiality, tenant context, replay, poison messages, backpressure, retention, and denial-of-wallet or resource exhaustion.

Example: Use queues for scale and decoupling while enforcing tenant context, confidentiality, replay controls, poison-message handling, backpressure, retention, and cost protection.

Counterexample: Allow probabilistic model output to change authoritative state without deterministic validation, which treats model behavior as deterministic. | Share training, retrieval, inference, and telemetry data for the inference queue without purpose separation, leaving boundaries incomplete. | Defer trust-boundary analysis for the inference queue until red-team testing, deferring deterministic control to model behavior.

Model, prompt, retrieval, tool, and agent trust boundaries

Model AI systems as multiple interacting components rather than one trusted box. Each boundary can introduce injection, data leakage, confused-deputy, privilege, or provenance risk.

Example: Model the model, prompts, retrieval store, tools, and agent as separate boundaries with explicit identity, authorization, provenance, and data-flow controls.

Counterexample: Accept AI-generated architecture decisions about the AI component boundaries without human validation, which treats probabilistic model behavior as a deterministic security control. | Use one vector store for the AI component boundaries across tenants without identity-aware retrieval controls, leaving model, data, tool, and policy boundaries incomplete. | Treat the provider model for the AI component boundaries as a trusted black box, deferring deterministic control to model behavior.

Agent tool-use architecture

Tool-using agents should receive narrowly scoped capabilities, explicit parameters, transaction limits, approval for high-impact actions, isolated execution, and complete audit trails.

Example: Grant narrowly scoped tools and parameters, enforce limits outside the model, isolate execution, require approval for high-impact actions, and log every call.

Counterexample: Give the agent one broad production credential and rely on the prompt to limit its actions, which assumes determinism. | Allow arbitrary tool parameters and require human review only after a high-impact action completes, leaving model, data, tool, and policy boundaries incomplete. | Run tool calls in the application process without isolation, transaction limits, or complete audit records, deferring authorization and fallback decisions to probabilistic model behavior.

Model fallback and safe degradation

Design for unavailable, slow, low-confidence, toxic, manipulated, or drifting model behavior. Fallbacks may include abstention, deterministic rules, human review, cached safe responses, or service isolation.

Example: Define abstention, deterministic rules, human review, cached safe responses, or isolation for unavailable, slow, low-confidence, toxic, manipulated, or drifting models.

Counterexample: Treat fallback and safe degradation as one trusted deterministic component, which treats model behavior as deterministic. | Queue fallback and safe degradation requests without replay, tenant, retention, backpressure, or cost controls, leaving AI trust boundaries incomplete. | Reuse data across fallback and safe degradation planes and address privacy only after deployment, deferring deterministic control to model behavior.

AI data-plane separation

Separate training, evaluation, retrieval, inference, and operational telemetry data according to purpose, classification, trust, and retention. Avoid uncontrolled reuse across these planes.

Example: Separate training, evaluation, retrieval, inference, and telemetry data by purpose, classification, trust, access, and retention.

Counterexample: Allow probabilistic model output to change authoritative state without deterministic validation, which assumes determinism. | Observe the AI data planes without recording model, policy, context, tool, confidence, or refusal information. | Treat AI-generated threats about the AI data planes as complete without expert review.

Model and embedding confidentiality

Protect model weights, system prompts, embeddings, and retrieval indexes against extraction, inference, unauthorized modification, and cross-tenant leakage according to their business value and privacy impact.

Example: Protect weights, system prompts, embeddings, and retrieval indexes from extraction, inference, unauthorized change, and cross-tenant leakage.

Counterexample: Accept AI-generated architecture decisions about and embedding confidentiality without human validation, which treats model behavior as deterministic. | Change models, data, tools, or autonomy for and embedding confidentiality without refreshing threat and risk reviews, leaving boundaries incomplete. | Change autonomy for and embedding confidentiality without new approval or risk analysis, deferring deterministic control to model behavior.

AI architecture observability

Observe prompts, retrieved context, model versions, policies, tool calls, confidence, refusals, output classifications, and user feedback while minimizing sensitive-data retention.

Example: Record model and policy versions, prompts, retrieved context, tool calls, confidence, refusals, classifications, and feedback while minimizing sensitive retention.

Counterexample: Use prompt instructions as the sole control, which treats model behavior as deterministic. | Treat the AI observability design as one trusted service that combines model, data, retrieval, tools, and policy, leaving boundaries incomplete. | Allow probabilistic output from the AI observability design to change authoritative state and monitor errors afterward, deferring deterministic control to model behavior.

AI architecture change triggers

Retraining, model replacement, prompt-template changes, new tools, new datasets, vector-store changes, and changed autonomy can invalidate prior threat models and risk reviews.

Example: Trigger new threat and risk reviews for retraining, model or prompt replacement, new data, vector-store changes, new tools, or changed autonomy.

Counterexample: Treat the AI change process as one trusted deterministic component, which treats probabilistic model behavior as a deterministic security control. | Give the AI change process broad tool credentials without parameter limits, approval, isolation, or audit, leaving AI trust boundaries incomplete. | Use model instructions as the only authorization control, deferring authorization and fallback decisions to probabilistic model behavior.

Common Criteria (ISO/IEC 15408)

Common Criteria is an international standard (ISO/IEC 15408) for specifying and evaluating IT product security functionality and assurance. Evaluation results are mutually recognized among participating nations under the Common Criteria Recognition Arrangement (CCRA), helping architects select independently assessed components rather than relying on vendor claims alone.

Example: Use a Common Criteria certificate as scoped, time-bound evidence of an independently evaluated security claim, and still verify the certified version, configuration, and assurance level against the deployment's actual needs.

Counterexample: Treat a Common Criteria certification as proof the product is secure in every configuration and version, without checking scope, evaluated configuration, or assurance level. | Assume a higher Evaluation Assurance Level means the product resists more attacks in practice, rather than that it was evaluated with more rigor and formality. | Select a component solely because it is Common Criteria certified without confirming the certified configuration matches how it will actually be deployed.

Evaluation Assurance Levels (EAL1-EAL7)

EAL1 through EAL7 measure how rigorously and formally a Common Criteria evaluation was performed, from functional testing (EAL1) to formally verified design and testing (EAL7). A higher EAL reflects greater evaluation rigor and evidence, not a direct measure of how secure the product is or how many features it has.

Example: Interpret a higher EAL as more rigorous, better-documented evaluation evidence, and still assess whether the evaluated security functionality matches the system's actual requirements.

Counterexample: Treat EAL7 as inherently more secure than EAL4 regardless of what security functionality was actually evaluated or how it fits the deployment. | Assume assurance level alone determines whether a product is fit for a given risk context, ignoring the specific claims in its Security Target. | Select the highest available EAL without regard to cost, schedule, or whether that rigor is proportionate to the system's risk.

Protection Profile and Security Target

A Protection Profile (PP) is an implementation-independent set of security requirements for a category of products, typically defined by a community of consumers. A Security Target (ST) is a vendor's specific security claims for one evaluated product, often written to conform to one or more Protection Profiles.

Example: Use a Protection Profile to define category-wide requirements before selection, then evaluate a vendor's Security Target against those requirements for the specific product being considered.

Counterexample: Treat a vendor's Security Target as an independent, category-wide requirement rather than that vendor's own product-specific claims. | Assume a product without a Protection Profile mapping cannot be evaluated or trusted, rather than assessing its Security Target on its own merits. | Confuse the Security Target (what was evaluated and claimed) with the actual production configuration, which may differ from the evaluated configuration.

Cloud deployment models

Public, private, hybrid, and community cloud describe who owns and shares the underlying infrastructure, independent of the service model (IaaS/PaaS/SaaS). Public cloud is multi-tenant and provider-owned; private cloud is dedicated to one organization; hybrid combines both with integration between them; community cloud is shared among organizations with common requirements.

Example: Select a deployment model based on tenancy, data-sensitivity, and integration needs, independent of which service model (IaaS/PaaS/SaaS) is chosen.

Counterexample: Treat deployment model and service model as the same decision, assuming private cloud automatically means IaaS or that public cloud automatically means SaaS. | Assume private cloud eliminates the need for shared-responsibility analysis simply because tenancy is dedicated. | Select hybrid cloud without accounting for the added complexity of securing the integration and data flow between environments.