The provider should own the complex security configurations when those settings are part of the product’s safe baseline. Secure by default is meant to ship critical controls already enabled, so customers do not need to engineer safety from scratch. Organisations still own their local decisions, but the manufacturer should carry responsibility for insecure defaults and hard to configure protections.
Who Should Own Complex Security Settings in a Secure by Default Model?
In a secure by default model, the provider should own the hard security choices that most customers would otherwise misconfigure or leave incomplete. That includes shipping safe defaults, enabling critical protections, and reducing the need for customers to understand every low-level control just to reach a defensible baseline. Customer ownership remains for local policy decisions and business-specific exceptions.
Why Provider Ownership Matters for Default Security
Secure by default is not just a convenience principle, it is an accountability model. If a product requires customers to discover, assemble, and correctly tune essential protections, then the real burden of security has been shifted downstream. That creates predictable gaps, especially where the configuration is complex, failure is silent, or the safe state is easy to bypass during setup.
Provider ownership matters most when the setting affects the product’s safe baseline rather than a customer-specific preference. In those cases, the manufacturer is best placed to design the control, test it across the full user population, and keep it aligned with product updates. Customers can still choose stricter settings, but they should not have to engineer the minimum safe state from scratch.
Good secure by default design also makes security repeatable. A baseline that is enabled automatically is easier to validate, support, and document than one that depends on every deployment team making the same judgment call. That is why the accountability question is less about convenience and more about who can realistically prevent avoidable misconfiguration at scale.
Where Responsibility Still Stays with the Customer
Provider responsibility does not remove customer accountability. Organisations still own their local data classification, exception handling, administrative approval, and any changes that weaken the safe baseline. If a customer deliberately relaxes a protection for compatibility, performance, or operational preference, that choice becomes their responsibility.
The practical boundary is whether the decision is product-wide or deployment-specific. Product-wide safe defaults, hard-to-understand protections, and controls that should be enabled for almost everyone belong with the provider. Environment-specific policies, internal approvals, and business risk acceptance belong with the customer. The cleanest model is shared responsibility, but not shared ambiguity.
This is also why configuration complexity itself is a security issue. A protection that is technically available but difficult to enable is functionally weaker than one that is enabled by design. Providers that externalise complexity often create the very class of insecure deployments they claim to help customers manage.
What Strong Secure by Default Ownership Looks Like
Strong ownership means the provider treats safe configuration as part of product quality, not as optional hardening. The product should ship with protections enabled, dangerous shortcuts minimised, and setup paths that make the safe choice the easiest choice. Where exceptions are necessary, they should be explicit, visible, and reversible.
For practitioners, the useful question is not whether customers can technically override the default, but whether they can accidentally arrive at an unsafe state without understanding the consequence. If the answer is yes, the baseline is too fragile. Secure by default should narrow the gap between what is intended and what is actually deployed.
That logic aligns with product security guidance that pushes security into the shipped baseline rather than into customer-led hardening, including CISA Secure by Design. It also fits the control expectation that configuration, access, and system integrity should be managed as part of normal security architecture, not treated as afterthoughts, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Secure defaults depend on safe configuration and controlled access settings at deployment. |
| Recommendation — Standardise secure configuration defaults and remove optional insecure setup paths. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The question is about who owns the secure baseline and its configuration. |
| CM-6 — Configuration Settings | It addresses responsibility for complex security settings that affect the safe state. | |
| SI-2 — Flaw Remediation | Provider ownership includes fixing insecure defaults and hard-to-configure protections. | |
| Recommendation — Define and maintain a secure configuration baseline for shipped products and deployments. Set and enforce secure configuration settings by default rather than leaving them to customers. Remediate insecure defaults and security defects before release. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Secure by default depends on controlled, secure product configuration. |
| A.8.20 — Network security | Default-secure products often require network protections to be enabled at shipment. | |
| Recommendation — Control configuration changes so the secure baseline remains intact. Enable network protections as part of the default secure posture. | ||
Practitioner Guidance
What to verify: Check whether the product ships with the highest-risk protections enabled by default, and whether turning them off requires an explicit, documented decision rather than an accidental setting change. If the safe baseline depends on a manual checklist, the ownership model is too weak.
Decision rule: If a control is part of the minimum safe product state, the provider should own its design and default posture; if it is a local policy choice or business exception, the customer should own the decision and any associated risk acceptance.
Common mistake: Treating “we exposed the option” as equivalent to “we made the product secure.” Exposing a control is not the same as making the secure path the default, or making the unsafe path hard to reach.
Practitioner takeaway: Secure by default works only when the provider assumes responsibility for the baseline security outcome and the customer owns deliberate deviations from that baseline.
