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 AI-enabled incidents of the 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.

Doesn't our MTTR already measure this?

Partly, and it is worth being precise about what it misses. Most organisations can report mean time to remediate from their ticketing system or vulnerability platform, and many report SLA compliance to the board every month. The number exists. The problem is where the clock starts.

MTTR is measured from detection, not from exposure. If a setting drifts on the 3rd and the scan picks it up on the 17th, those fourteen days sit outside the number entirely. They were real exposure, and no SLA was breached, because the clock had not started. Closing the detection interval is exactly what continuous validation does, and it is invisible to a metric that begins at the ticket.

The second gap is distribution. A mean is a poor summary of remediation, because a respectable five-day average can conceal a long tail of items open for months, usually the awkward ones nobody wants to own. If you only look at the average, that tail stays hidden.

The third point is the most uncomfortable, and it is not a measurement problem at all. Plenty of teams know their number precisely, report it accurately, and it is still far slower than an attacker needs. Knowing you are exposed for three weeks does not make you any less exposed. The metric is fine. The gap it describes is the issue.

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 reporting a healthy MTTR that starts at detection, with no measure of how long drift sat unnoticed first.
• •Teams whose remediation backlog is measured in weeks, not hours, or whose average hides a long tail.
• •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.

Your MTTR is not the whole picture. The exposure that matters runs from the moment a setting drifts, not from the moment a scanner notices, and if that combined window is longer than the time it takes an attacker to move through it, the 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