Security by design moves responsibility upstream because many failures occur before a customer ever configures the product. If a device ships weak, unpatchable, or opaque, users inherit risk they cannot realistically remove. The approach aims to make secure settings, update paths, and baseline protections part of the default product, which reduces dependence on customer hardening alone.
Why security by design changes who carries the burden
Security by design shifts responsibility because the product’s baseline security posture is created before the customer ever logs in. If secure defaults, updateability, safe authentication, and defensive configuration are built in, the vendor controls the biggest leverage points. The end user still operates the system, but they are no longer expected to compensate for structural weaknesses the product shipped with.
What the vendor is now accountable for
The practical change is that the vendor owns more of the secure outcome, not just the feature set. That includes hardening the default configuration, limiting exposed functionality, reducing the need for customer tuning, and providing a patch path that actually works in the field. If a product requires users to discover and fix its core weaknesses, the security model is already back-loaded onto the buyer.
This is one reason product-level obligations are increasingly reflected in EU Cyber Resilience Act expectations, where security is treated as part of the product lifecycle rather than an optional deployment choice. It is also why guidance such as CISA Secure by Design emphasizes removing insecure defaults instead of asking customers to offset them after purchase.
Why end users cannot realistically absorb the full burden
Most buyers do not control the codebase, firmware, update channel, dependency chain, or hidden implementation choices that determine whether a product is actually secure. They can configure, monitor, and compartmentalise, but they usually cannot make an insecure product safe in every deployment. That is especially true when weaknesses are unpatchable, undocumented, or tied to opaque vendor decisions that the customer never sees.
That asymmetry is why secure design matters more than user caution alone. A customer may be able to reduce exposure, but they cannot reliably remove insecure logic, weak crypto choices, unsafe device defaults, or a broken lifecycle model if the vendor never built those controls in. NIST Cybersecurity Framework 2.0 fits this thinking because it frames security as an organisational outcome across governance, protection, detection, response, and recovery, not as a user-only problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act | Products with digital elements must be secure by design across their lifecycle. |
| Recommendation — Design products with secure defaults, vulnerability handling, and updateability built in. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management | Vendor security responsibility is central when buyers depend on shipped product assurances. |
| PR.PS-05 — Configuration Management | Secure-by-design shifts baseline configuration burden away from end users. | |
| Recommendation — Set supplier security requirements for defaults, patching, and disclosure support. Ship hardened defaults that reduce customer-side configuration risk. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | This question is about moving secure baseline responsibility into the product itself. |
| Recommendation — Enforce secure baseline configurations before deployment. | ||
Practitioner Guidance
What to verify: Treat vendor claims as incomplete until you can confirm the product ships with secure defaults, a supported update path, and clear ownership for vulnerability disclosure and remediation. If those are missing, the buyer is inheriting avoidable operational risk.
Decision rule: If the control only works after extensive customer hardening, treat that as a product-quality issue, not a deployment success. Prefer products that reduce the number of settings a customer must get right to reach a safe baseline.
What practitioners underestimate: The hardest failures are often the ones users cannot observe or reverse, such as weak bootstrapping, long-lived exposure, or unpatchable design flaws. That is why procurement, architecture review, and lifecycle support are security controls, not just commercial checks.
Practitioner takeaway: Security by design does not remove user responsibility, it rebalances it so vendors own the security properties customers cannot practically create after delivery.
Related resources from NHI Mgmt Group
- Why do critical infrastructure cyber strategies push more responsibility onto providers, operators, and government rather than end users alone?
- How should organisations assign responsibility for IoT device security across manufacturers and end users?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
