They persist because responsibility is often pushed downstream to customers while vendors ship products with weak defaults, known vulnerabilities, or unvetted components. That creates preventable exposure at scale, especially when products underpin critical infrastructure or connected devices. Risk falls when security is built in before release, supported by testing, and reinforced by incentives that make insecure delivery harder.
Why insecure defaults turn design mistakes into avoidable risk
Security-by-design failures become expensive because the product ships with the wrong assumptions baked in: weak defaults, permissive settings, and fragile trust boundaries. Once those choices are replicated across deployments, the cost is no longer a one-off defect, it is a systemic exposure that customers inherit and then have to discover, harden, and monitor themselves.
The core issue is that insecure defaults shift the burden from the vendor to the operator. A well-designed product makes the safe path the easy path, so that basic use does not depend on every customer having deep security expertise or perfect implementation discipline.
Why downstream patching and customer hardening do not scale
When vendors rely on customers to compensate for known weaknesses, the result is inconsistent protection across the installed base. Some organisations will apply compensating controls quickly, but many will not, and that creates a wide attack surface for the same defect to be exploited repeatedly across environments, especially when the product is widely deployed or embedded in critical services.
This is why secure configuration, testing before release, and prompt vulnerability handling matter as product properties, not as optional extras. A product that only becomes safe after bespoke customer tuning is already a risk multiplier, because the security outcome depends on local skill, time, and budget rather than on the design itself.
That logic is reflected in CISA Secure by Design, which pushes vendors toward safer defaults and less customer burden, and in the EU Cyber Resilience Act, which ties product security expectations to the lifecycle of digital products.
Why this becomes a supply-chain and infrastructure problem
Security-by-design failures are not limited to the product owner. They spread through dependency chains, third-party components, and connected deployments, so a single insecure library, exposed secret, or unvetted component can become a repeated failure mode across many systems. That is why these issues are especially serious in connected devices, software platforms, and operational technology where patching is slow and blast radius is large.
The practical lesson is that product risk and deployment risk are linked. If the shipped product cannot be trusted to start from a secure baseline, then every customer environment becomes part of the control plane, and every integration inherits part of the vendor’s security debt.
For teams tracking active exploitation and hardening priorities, CISA Known Exploited Vulnerabilities Catalog is useful because it shows how quickly design and patching failures can turn into real-world exposure, while CISA Industrial Control Systems highlights why insecure defaults in operational environments can have outsized impact.
Risk and Threat Considerations
Insecure defaults create predictable attack paths because adversaries look for the settings, components, and deployment patterns that remain unchanged across many targets. A weak default password, exposed interface, overbroad permission set, or unreviewed dependency can give attackers a repeatable entry point long after the vendor considers the issue “known.”
Failure mechanism: The product ships with insecure assumptions or weak baseline controls, and those defaults persist into production because customers either do not notice them, cannot change them safely, or lack the time and expertise to do so at scale.
Impact: The same defect can be exploited across many installations, creating avoidable compromise, broad exposure, and slow, expensive remediation, especially where the product is embedded in critical infrastructure or connected device fleets.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while EU Cyber Resilience Act defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act | Governs secure-by-design obligations for digital products and lifecycle security. |
| Recommendation — Design products to ship secure defaults and support vulnerability handling across the product lifecycle. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Addresses building security into software and reducing avoidable product weaknesses. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Directly addresses insecure defaults and baseline hardening. | |
| Recommendation — Build secure-by-design checks into development and release gates. Enforce secure baseline configurations before deployment. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Requires established secure baselines rather than permissive defaults. |
| SI-2 — Flaw Remediation | Covers fixing known weaknesses before they become exposed in production. | |
| Recommendation — Define and enforce secure configuration baselines for shipped systems. Patch known flaws before release and track remediation through closure. | ||
Practitioner Guidance
What to prioritise: Treat defaults, onboarding state, and first-run configuration as security controls, not usability details. If the secure state is not the default state, assume adoption will be uneven and the risk will persist.
What to verify: Confirm that the product can be deployed safely without customer-customised hardening, that insecure features are off by default where possible, and that dependency, patch, and testing processes are strong enough to catch known weaknesses before release.
Practitioner takeaway: The biggest mistake is assuming customers will reliably compensate for weak product design; in practice, the safest product is the one that is secure before anyone has to configure it.
Related resources from NHI Mgmt Group
- How should security teams use OTP without creating avoidable risk?
- How should security teams handle PCI data in Box without creating avoidable exposure risk?
- How should security teams design app request workflows so employees get access quickly without creating shadow IT risk?
- How should security teams automate dependency updates without creating avoidable breakage risk?
