If your security architecture is not documented in your DHF, then under SW96 it does not exist.
What SW96 requires from architects
- Threat modelling, in the DHF. A formal design activity across the lifecycle, not a post-development pentest. If it isn't documented and traceable to security risk controls, it is a DHF gap.
- SBOM. Required under section 524B of the FD&C Act and FDA's 2025 cybersecurity guidance. Every component, dependency and third-party library, documented and traceable. Your SBOM is your SOUP list made visible to the regulator.
- Security risk is not safety risk. FDA treats them as distinct processes. A threat actor's intent can't be modelled statistically like an ISO 14971 probability, so the architecture has to assume breach and limit impact, not just prevent it.
- Post-market patching is an architecture decision. If your system can't be patched without full revalidation, that is an architecture problem created on day one, not a process gap.
Architecture decisions that are SW96 controls
- Network segmentation. The Blast Radius Principle, formally documented as a risk control.
- Stateless JWT with edge validation. Locally validated trust is auth resilience, and it has to be in the DHF with justification.
- Isolated patch pathways. Microservices let you patch without full revalidation. Design for it from day one.
Good security architecture and regulatory compliance are not two conversations. They are the same conversation, and one has legal consequences.
Seen this differently?
Questions, corrections and counterexamples are welcome.
