Secure by Default

Secure by default means a system arrives in its most secure usable state without the user having to configure anything. Security is the starting point, and loosening it requires a deliberate, informed decision. The principle counters the reality that most breaches stem not from exotic exploits but from misconfiguration — open buckets, default passwords, permissive CORS, debug endpoints left on in production.

How It Works

Designers choose safe defaults at every decision point. Access defaults to deny, not allow. Encryption (TLS, encryption at rest) is on out of the box. Features that widen attack surface — verbose error pages, directory listing, sample apps, remote admin — are disabled until explicitly turned on. There are no default credentials; the system forces creation of a strong one on first use. Ports and services are closed unless needed. The system fails closed: when something goes wrong (an auth service is unreachable, a policy can't be evaluated), it denies access rather than falling open.

The complementary principle is making the secure path the easy path so users do not route around it. Defaults should also be safe for the least-experienced operator, since they are the ones who never change settings.

When to Use It

Apply secure-by-default to any product, framework, library, platform, or internal service that others configure and deploy — anything where a user's omission could create a vulnerability. It is foundational for cloud platforms, frameworks, and developer tooling, where a single insecure default propagates to thousands of deployments. It is increasingly a regulatory and procurement expectation (CISA's "secure by design/default" initiative).

Trade-offs

Secure defaults can add friction and break naive first-run experiences, tempting vendors to ship permissive defaults for a smoother demo — the very mistake the principle warns against. Some secure defaults reduce convenience or performance (encryption overhead, stricter validation rejecting sloppy input). There is a usability balance: defaults too strict drive users to disable security wholesale rather than adjust it carefully. The goal is secure and usable defaults, not security that forces users to opt out entirely.

Related Patterns

Secure by default operationalizes least privilege (default-deny permissions) and is a layer of defense in depth. It pairs with secrets rotation by never shipping static default credentials, and with zero-trust segmentation by treating everything as untrusted until explicitly permitted.

Example

A managed object-storage service that exemplifies the pattern: new buckets are private with public access blocked at the account level, server-side encryption is enabled automatically, TLS is required for access, and making a bucket public requires several explicit confirmations with warnings. An operator who creates a bucket and does nothing else still has a secure resource; exposing data takes conscious, friction-laden action — the inverse of the open-by-default services responsible for countless data leaks.