They often treat secure-by-design as a development-time checklist instead of an operating model. The CRA links design, default settings, vulnerability handling, and post-market support, so the control does not end at launch. If access, update, and support identities are not governed after deployment, the design claim is incomplete.
Why This Matters for Security Teams
Secure-by-design fails when organisations treat it as a release gate instead of a lifecycle commitment. The EU Cyber Resilience Act changes that assumption by linking product design, default configuration, vulnerability handling, and post-market support. If identities that operate updates, support, telemetry, and admin functions are not governed after launch, the product is only partially secure by design.
That gap is not theoretical. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 20% of organisations have formal offboarding and revocation processes for API keys in the first place. Those numbers map directly to product reality, where build-time security is often stronger than runtime governance. See the Ultimate Guide to NHIs — The NHI Market and NIST SP 800-53 Rev 5 Security and Privacy Controls for the control expectations that often get missed. In practice, many security teams encounter the problem only after a shipped product is already being abused through update channels, support tools, or exposed API credentials.
How It Works in Practice
Secure-by-design should be implemented as a set of operating controls, not just a secure coding review. That means the product team defines the trust boundaries for humans, services, devices, and administrative functions before launch, then proves those boundaries still hold after deployment. The question is not only whether the code was reviewed, but whether access paths, defaults, update mechanisms, and recovery workflows remain constrained over time.
A practical programme usually includes:
- Least-privilege defaults for all product-facing and operator-facing identities.
- Explicit governance for service accounts, API keys, certificates, and support access.
- Rotation, revocation, and offboarding procedures tied to product lifecycle events.
- Secure update and recovery workflows that do not rely on permanent standing access.
- Monitoring that detects misuse of product identities, not just human logins.
This is where NHI governance becomes a product-security issue. The CI/CD pipeline exploitation case study shows how build and release systems can become the weak link when secrets and automation identities are overtrusted. Likewise, Millions of Misconfigured Git Servers Leaking Secrets demonstrates how “secure design” collapses when long-lived credentials are left in places that the design process never revisits. Best practice is evolving toward continuous validation because static assurance does not survive real operational change. These controls tend to break down when engineering, product, and support teams each own part of the lifecycle but no one owns identity governance end to end, because responsibility fragments faster than the attack surface does.
Common Variations and Edge Cases
Tighter secure-by-design controls often increase delivery overhead, requiring organisations to balance release speed against lifecycle assurance. That tradeoff is real, especially for embedded products, SaaS platforms, and connected devices where updates, diagnostics, and support access all need separate identity handling. Current guidance suggests the most dangerous mistake is assuming one secure design review can cover all future operational states.
There is no universal standard for this yet, but the direction is clear. Products that ship with hardcoded credentials, broad support privileges, or non-expiring service tokens undermine the original design claim the moment they are deployed. For connected products, post-market support is part of the security boundary. For SaaS, tenant administration and break-glass processes matter as much as code review. For regulated products, design evidence must be matched with evidence of runtime enforcement. The EU Cyber Resilience Act, NIST controls, and NHI governance practices all point to the same operational reality: secure-by-design is incomplete unless identities, defaults, and update channels remain controlled after release.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Defines secure-by-design across product design, defaults, vuln handling, and support. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Highlights risks from unmanaged service accounts, API keys, and other NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance are central to secure product operations. |
| NIST SP 800-63 | Identity proofing and authentication strength matter for administrative product access. | |
| NIST AI RMF | Supports governance across the full lifecycle of risky automated product behaviour. |
Treat secure-by-design as a lifecycle duty and keep update, support, and vulnerability processes under control after release.
