In the middle of an audit this month, someone asked, “Do you have a VPN?” My first thought wasn’t yes or no, it was why would that matter for the risks we actually face? That moment stuck with me. Too often, security discussions get reduced to a checklist of tools: VPNs, firewalls, password policies, and so on. But security isn’t about stacking products until you feel covered. It’s about identifying the threats that matter and applying the simplest, most effective controls to reduce them.
The Trap of Box-Checking Security#
It’s easy to treat security like an audit scorecard. A checklist feels comforting: if we can say we have a VPN, a firewall, an IDS, and a dozen other acronyms, then we must be secure… right? The problem is that these tools often get added without anyone stopping to ask the obvious question: what risk are we actually trying to solve?
This is where box-checking creates an illusion of safety. A VPN might look impressive on paper, but if it doesn’t tie access back to real user identities or provide meaningful logs, it isn’t solving the real problem of controlling who can reach sensitive systems. Worse, it can quietly add new risks. Every extra tool is another piece of software to patch, another configuration that can drift, another credential that might leak, and another service an attacker could target. The more moving parts you add, the more likely it is that one of them will become the weakest link. In other words, the tools you adopt to “check the box” can actually make the system harder to defend.
I’ve seen teams pile on tools simply because “that’s what secure companies do.” The reality is that real security isn’t about appearances. It’s about being clear on which threats matter in your environment and choosing controls that actually reduce those risks.
Real Security Is About Outcomes, Not Tools#
The real test of any control isn’t whether you can point to it on a diagram. It’s whether it reduces the risk you actually face. That’s why the starting point for any security decision should be a simple question: what problem are we trying to solve?
If the problem is preventing unauthorized access to sensitive data, then the right answer probably involves identity-aware access controls, strong authentication, and clear audit logs. If the problem is insider misuse, then monitoring, least-privilege permissions, and rapid revocation of access matter more. None of those problems are meaningfully solved just by dropping a VPN or a firewall into the environment. Those tools might give the impression of protection, but they don’t get to the outcome you need.
When you focus on outcomes, the conversation shifts. Instead of “Do we have a VPN?” the question becomes “Can we prove that only the right people accessed this system, at the right time, for the right reasons?” That’s a much harder question, but it’s also the one that actually matters.
Complexity is the Enemy of Security#
One of the easiest mistakes to make in security is assuming that adding more tools always makes things safer. In reality, complexity often has the opposite effect. Every additional piece of infrastructure comes with its own patches, configuration files, secrets, and quirks. Each of those is another opportunity for human error.
I’ve seen this play out in real environments: a new tool gets added to “harden” the system, but six months later no one remembers who owns it, the documentation is stale, and it’s quietly running with default settings. The tool is still there, so it looks like a box has been checked, but in practice it’s become a liability.
Attackers know this too. They don’t go after the well-maintained, well-audited parts of your system. They look for the forgotten corners, the half-configured services, the single jump server someone spun up for “temporary” access that ended up sticking around for years. That’s where complexity creates cracks.
Real security isn’t about piling on layers until nobody can keep track of them. It’s about building a small number of strong, simple controls that you can understand, maintain, and explain to an auditor without sweating.
Controls That Actually Work#
So if piling on tools isn’t the answer, what does real security look like? In my experience, the most effective controls share three qualities: they are identity-based, auditable, and enforce least privilege.
Identity-based means access is tied to a real person or service account, not just an IP address or a machine on the “inside” of a network. When you know who is connecting, you can enforce stronger authentication, tailor permissions, and revoke access immediately when someone leaves the organization.
Auditable means you can prove what happened. It’s not enough to log that “an IP connected.” You want records that say “this user accessed this resource at this time.” Those logs become invaluable during audits and even more critical during incident response.
Least privilege means granting only the access that’s truly needed, and nothing more. It sounds simple, but in practice it’s one of the hardest disciplines to stick to. In a small organization, the pressure is always there to “just give them broad permissions so they can get unblocked.” I’ve done it. Most of us have. It feels like the fastest way to keep things moving.
The problem is that these shortcuts never really stay temporary. Once someone has admin rights or blanket access to a system, it almost always sticks around. Over time, you end up with half the team carrying keys to everything, not because they need them, but because it was convenient in the moment. That’s not security — that’s hoping nobody misuses the access you already handed out.
Enforcing least privilege takes more effort up front. It means pausing to ask what exactly does this person need to do their job? and setting permissions that match. Sometimes it means saying no and finding another path. But the payoff is worth it: tighter access makes insider mistakes less damaging, reduces the blast radius if an account is compromised, and keeps your environment cleaner over time. In short, it turns access control from a box-checking exercise into a real line of defense.
When you apply these principles, the tools almost pick themselves. Whether it’s identity-aware proxies, fine-grained IAM roles, or short-lived access tokens, the common thread is that they enforce real accountability and reduce risk, not just the appearance of risk.
Don’t Confuse Compliance With Security#
Audits are useful because they force us to take a hard look at our systems. But they can also push teams into a bad habit: thinking that if the boxes are checked, we must be secure. Compliance is about meeting a minimum bar. Security is about protecting what matters. Those are not the same thing.
If you only chase compliance, you end up with controls that look good on paper but don’t do much in practice. A VPN, a firewall rule, another tool in the stack… they might help you pass the review, but they don’t stop the risks that actually hurt you. Things like overbroad access, weak identity management, or missing logs don’t show up on a simple checklist, but they cause most of the real problems.
The teams that handle this well don’t aim for compliance as the goal. They aim for solid security practices. Compliance then becomes the natural outcome. If you focus on identity, least privilege, and clear audit trails, the audit usually takes care of itself. And more importantly, so does the day-to-day safety of your systems.
Conclusion#
Real security isn’t about piling up tools or racing through checklists. It’s about reducing the risks that matter in ways you can actually trust and maintain. That usually means fewer, stronger controls built around identity, auditability, and least privilege.
The difference is like putting a sticker on your car that says “Safe Vehicle” versus buckling your seatbelt. The sticker might make you look compliant, but it won’t protect you in a crash. The seatbelt will.
Don’t settle for stickers. Wear the seatbelt.