How do misconfigurations cause breaches? The 27-minute problem

An open port. A permission that policy never allowed. A hardening setting that quietly reverted after an update. None of these is a clever attack, and all of them are how organisations actually get breached. The danger is not that misconfigurations are hard to find. It is the gap between finding one and closing it, and with attacker breakout time now measured in minutes, that gap is where the exposure lives.

This guide explains why misconfiguration and configuration drift are a leading cause of breaches, why point-in-time compliance no longer catches them, and how continuous detection paired with gated, reversible automated remediation closes the gap without a large security team or the risk of automation running loose.

How do misconfigurations cause breaches?

Misconfigurations cause breaches because they leave a door open that an attacker can simply walk through, no exploit required. An over-permissioned account, an exposed service, a legacy protocol left enabled, a default that was never hardened: each is a direct path in that does not depend on the attacker being sophisticated. Industry reporting consistently attributes a large majority of breaches to configuration errors rather than to novel hacking.

This is the uncomfortable part. The thing most likely to breach you is not a zero-day. It is a setting that drifted out of place and stayed there. So the security question that matters most is not "can we stop advanced attacks", it is "how fast do we notice and close the ordinary openings we create ourselves every day".

What is configuration drift, and why is it so dangerous?

Configuration drift is the gradual divergence of a system's actual settings from its intended secure baseline over time. It happens through routine activity: manual changes, updates, new deployments, and temporary fixes that were never reverted. An engineer disables a protocol to resolve an urgent problem and forgets to re-enable it. A permission is widened for a project and never narrowed again.

Drift is dangerous precisely because it is invisible and constant. No single change looks like an incident. Each is a small, reasonable-seeming adjustment, and each one sits open until something notices. The estate you secured at the last review is not the estate you have today, and the difference between them is pure, unmonitored exposure.

Why doesn't point-in-time compliance catch this?

Point-in-time compliance does not catch drift because it assumes a control stays effective between checks, and drift breaks that assumption the day after the audit. A control tested once and signed off is only known-good on the day it was tested. Every day after, the estate moves, and nothing in a cadence-based model is designed to notice.

An annual audit or quarterly review made sense when the gap between a configuration drifting and an attacker finding it was measured in weeks or months. There was slack in the system. That slack is gone. A point-in-time control tested once a year is a lock you inspect on your birthday, defending a door that gets rattled every 27 minutes for the other 364 days. Compliance is a useful discipline, and certifications like Cyber Essentials matter, but a passed audit is a snapshot, not a guarantee that the door is still shut this afternoon.

Average criminal breakout time fell to around 27 minutes in 2025, with the fastest observed intrusion at 27 seconds, according to CrowdStrike's 2026 Global Threat Report. Any process for closing an open misconfiguration that is slower than that is, by definition, too slow.

What is attacker breakout time, and why does 27 minutes matter?

Breakout time is the interval between an attacker compromising their first machine and moving laterally to the next. When that interval is around 27 minutes, it sets the clock everyone else has to beat. A remediation cycle measured in days or weeks is not a delay, it is a standing exposure the attacker has ample time to use.

The number is also the clearest evidence of what AI actually changed. It did not give attackers a new capability. The documented incidents where attackers used AI this past year were well-understood techniques run faster. What AI delivered was compression: the collapse of the time between reconnaissance and exploitation, and between one machine and the next. AI did not hand attackers a new key. It handed them a much faster locksmith. Your tolerance for a slow-closing misconfiguration just dropped to near zero.

Isn't finding the misconfiguration the hard part?

No, and this is the most commonly misdirected point in the whole discussion. Finding misconfigurations is largely solved. The tooling to flag an open port, an over-permissioned account, an unpatched host, or a setting that has fallen out of policy is mature and widely deployed. Most teams can already see their drift. The problem is what happens after the flag.

A misconfiguration flagged on Monday and remediated three weeks later was exposed for three weeks. The finding protected nothing. The fix protected something, eventually, slowly, after it worked through a ticket queue, a change window and manual effort. The real gap is the distance between seeing a problem and closing it, and in most organisations that distance is filled entirely by human labour. Set a human-paced remediation cycle against a 27-minute breakout time and the mismatch is obvious. No amount of better detection closes it, because detection was never where the time was being lost.

How do you fix misconfigurations at scale, fast enough to matter?

You fix them at scale by pairing continuous detection with automated remediation, so drift is both seen and closed without waiting on a queue. Continuous detection means validating the estate against its secure baseline constantly rather than on a calendar. Automated remediation means closing the gap between that detection and the fix programmatically, so exposure does not sit open while a human works through tickets.

Continuous detection alone is not enough. Visibility without response just produces a faster-growing backlog of things you have seen but not fixed. The reduction in risk comes from the remediation half, because a misconfiguration protects no one until it is actually closed. This is the shift from a point-in-time badge to continuous compliance that holds all year, and it is also the half that has to be designed with care, because handing broad, unsupervised change rights to an automated system is a genuine hazard, not a free win.

Is automated remediation safe?

Automated remediation is safe when it is scoped, and dangerous when it is not. An engine with broad standing rights to change production at machine speed is, from one angle, indistinguishable from the threat you are defending against. The answer is not "automate everything". It is a narrower discipline built on three rules:

• •Auto-remediate high-confidence, low-blast-radius drift. Re-enabling a hardening setting that drifted, revoking a permission policy never allowed, disabling a legacy protocol that should have been off. These are well-understood, reversible and low-risk to apply automatically, and they are the bulk of the backlog.
• •Gate high-impact changes behind a human and a preview. Anything that could take a system down or break a dependency should not fire automatically. It should surface with a blast-radius preview so a person can decide quickly and informed, rather than slowly and blind.
• •Make everything reversible. Clean, instant rollback is the precondition that makes automation defensible at all. If any change can be reversed the moment something unexpected happens, the cost of being wrong drops sharply, and speed stops being reckless.

Speed where it is safe. Judgement where it is not. That is the entire design, and it is a world away from robots patching everything unsupervised.

What about AI systems and shadow AI?

A misconfigured AI agent is still a misconfiguration. An over-privileged AI assistant, an unsanctioned tool with access to sensitive data, a connector with more reach than anyone intended: these are the same problem on a newer surface, and they drift the same way. The same discipline applies, continuous discovery followed by scoped, reversible remediation, which is why AI governance and assurance belongs in the same programme rather than a separate one. For boards weighing where this sits alongside other cyber risk, cyber risk reporting for boards sets out what good looks like.

Who should act now

• •Organisations that pass audits but have no visibility of drift between them.
• •Teams whose remediation backlog is measured in weeks, not hours.
• •SMEs meeting the Cyber Essentials 14-day patching rule by manual effort, and struggling.
• •Anyone deploying AI tooling without knowing what those agents can actually reach.

If the distance between finding a misconfiguration and fixing it is longer than the time it takes an attacker to move through it, that gap is your real risk. See how continuous compliance closes it, explore the technology and solutions that sit behind it, or book a call and we will tell you the smallest sensible next step.

Further reading

• •CrowdStrike 2026 Global Threat Report, CrowdStrike
• •10 Steps to Cyber Security, NCSC