Secure by default sounds great.

You install something, and it just works. No extra steps. No risky settings. Safe out of the box.

That’s the promise. But reality doesn’t always match the marketing.

Let’s break down why assuming something is secure can be a trap.

What It Really Means

When vendors say "secure by default," they usually mean:

  • TLS is enabled
  • Auth is required
  • Only essential ports are open
  • Minimal permissions are granted

In other words: it’s not wide open.

But that’s just the surface.

The Problem with Assumptions

Security depends on context. What’s safe in one setup can be risky in another.

A few things that go wrong:

You assume defaults are enough

They rarely are. Especially in prod. Default passwords, weak keys, or permissive ACLs still show up all the time.

You don’t read the docs

Not all secure defaults are obvious. Some are opt-in. Some require flags. You miss one, and your system is exposed.

You trust upgrades blindly

Vendors change defaults. Something that was locked down last version might be looser now. Or vice versa.

You build on insecure foundations

If your base image, cloud setup, or container runtime isn't secure, the app sitting on top of it doesn’t matter.

Real Examples

Kubernetes

For years, kubelet ports were open by default. Anyone on the network could hit them. That’s not secure. But it was the default.

AWS S3

Public buckets were easy to create. People assumed AWS wouldn’t let that happen. They were wrong. Data leaks followed.

CI tools

Jenkins, GitLab, and others often run with wide-open permissions. Because ease > safety. Until it’s too late.

What You Should Do Instead

Don’t assume. Verify.

Start with a threat model

What are you protecting? From whom? In what environment?

Check the actual config

Don’t rely on docs or blog posts. Open the settings. Read the values. Test what’s exposed.

Automate your hardening

Use tools like OpenSCAP, CIS Benchmarks, or custom scripts to lock things down. And run them regularly.

Treat security as ongoing

Defaults might help you start secure. But staying secure takes work. Updates, audits, reviews, testing.

When Secure by Default Helps

Defaults aren’t bad. They’re helpful.

Especially for:

  • Teams without security expertise
  • New projects that need a safe starting point
  • Systems with lots of automation

But they’re not enough on their own.

The Takeaway

Secure by default is a baseline. Not a guarantee.

If you don’t test it, you don’t know.

Assume nothing. Check everything.

Working software is good. Working secure software is better.