Saint Paul cyberattack shows why configuration drift is the real risk

At a glance

What this is: This is an independent analysis of the Saint Paul cyberattack and the role configuration drift plays in weakening security controls over time.

Why it matters: It matters because municipalities and other resource-constrained organisations often lose control not through one bad change, but through the accumulation of small identity and configuration exceptions.

👉 Read Senserva's analysis of the Saint Paul cyberattack and configuration drift

Context

Configuration drift is the gradual gap between what a security policy says should be true and what is actually configured in production. In municipal environments, that gap can quietly widen across identity, access, and platform settings until the baseline no longer reflects the intended control model.

The Saint Paul incident is a reminder that local government security is often constrained by older systems, limited staff, and many small administrative exceptions that are hard to track. For IAM and security teams, the governance problem is not only prevention but proving that access and configuration remain aligned after the first deployment.

Key questions

Q: How should security teams manage configuration drift in municipal environments?

A: They should treat drift as a continuous control problem, not a periodic audit finding. That means comparing live settings to approved baselines, assigning owners to every exception, and removing temporary changes before they become normal operating state. In constrained environments, automated detection matters more because manual review rarely keeps pace with change.

Q: Why does configuration drift create more risk than a single bad setting?

A: A single bad setting is visible and usually removable. Drift is more dangerous because it accumulates silently across many small changes, making the documented policy less and less accurate over time. By the time an issue is obvious, the organisation may already be relying on a weakened control model.

Q: What signals show that a configuration baseline is no longer trustworthy?

A: The main signals are repeated exceptions, repeated emergency changes, settings that differ between environments, and review findings that keep returning without remediation. If approvals are current but production does not match them, the baseline is not describing reality and should not be used as assurance evidence.

Q: Who should own remediation when configuration drift affects security controls?

A: The owner should be the team responsible for the affected control, not a central queue that only records findings. If the issue involves identity, policy, or platform settings, the remediation path should land with the people who can change and validate that control. That is what makes correction durable.

Technical breakdown

How configuration drift changes the control surface

Configuration drift occurs when approved settings, policies, or exceptions slowly diverge from the secure state originally defined by the organisation. In identity and access environments, that can mean disabled protections being re-enabled inconsistently, policy exceptions staying in place, or service settings no longer matching the documented baseline. The result is a moving control surface that attackers can exploit because defenders are comparing against intent, not reality. Practical implication: monitor the live configuration state continuously, not just during periodic reviews.

Practical implication: monitor the live configuration state continuously, not just during periodic reviews.

Why temporary exceptions become permanent risk

Temporary workarounds are one of the most common causes of drift because they are introduced under pressure and rarely removed with equal discipline. Over time, those exceptions accumulate into an alternate operating model that no longer matches the security policy. In IAM terms, this can affect privileged roles, conditional access rules, account settings, or platform controls that were weakened to solve an urgent problem. Practical implication: treat every exception as a tracked control change with an owner, expiry, and review point.

Practical implication: treat every exception as a tracked control change with an owner, expiry, and review point.

How drift defeats baseline-driven security programmes

Baseline-driven programmes assume the gap between policy and production remains visible enough to correct before it becomes material. Drift breaks that assumption by making the baseline stale while operational teams continue to trust it. That is especially dangerous in municipalities and mid-sized organisations, where limited tooling and staffing reduce the chance that small deviations will be caught early. Practical implication: pair configuration baselines with automated detection and remediation so the control model stays current.

Practical implication: pair configuration baselines with automated detection and remediation so the control model stays current.

Threat narrative

Attacker objective: The attacker seeks to exploit control drift so that a municipal environment becomes easier to disrupt, degrade, or control than its documented policies imply.

1. Entry occurs when an organisation's real security posture has drifted away from the documented baseline, creating an opening that defenders no longer expect.
2. Escalation follows as accumulated exceptions, stale settings, or weakened controls give an attacker more room than the policy model suggests.
3. Impact lands when the mismatch between configuration intent and production reality allows critical services to be disrupted or trust in the environment to be undermined.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration drift is the quiet failure mode that turns policy into theatre. The problem is not usually a single catastrophic misconfiguration. It is the slow accumulation of exceptions, overrides, and stale settings that make documented controls increasingly fictional. Municipal and mid-market environments feel this first because they have less operational slack to reconcile intent with reality. Practitioners should treat drift as a governance defect, not a housekeeping issue.

Identity controls fail when teams trust the baseline more than the live state. Access reviews, conditional access, and privileged setting controls only work if the system they describe is still the system in production. Once drift sets in, assurance processes certify yesterday's environment instead of today's. That breaks the core assumption that policy, identity posture, and execution remain aligned. Practitioners need continuous verification of actual control state, not confidence in prior approvals.

Temporary exceptions are a lifecycle problem, not just a change-management problem. A workaround introduced for operational urgency often becomes the default state because no one owns its removal. In identity programmes, that means privileged paths, access exceptions, or security relaxations survive long after the incident they were meant to solve. The implication is that lifecycle governance must include expiry, ownership, and enforcement for every exception path.

Community infrastructure exposes the cost of under-instrumented security. When public services depend on systems that cannot show their live configuration drift, recovery becomes slower and accountability becomes harder. The issue is not only breach recovery, but the inability to prove which controls were present at the point of failure. Practitioners should assume that resilience depends on observability as much as on hardening.

Baseline drift is now a visibility gap that identity governance can no longer ignore. IAM teams have traditionally treated configuration as a platform issue and access as an identity issue. In practice, the two converge because access decisions depend on the controls surrounding them. The field needs a tighter view of control-state integrity across identity, endpoint, and platform layers.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a deeper view of how identity failures compound over time, see 52 NHI Breaches Analysis and map recurring patterns to your own control gaps.

What this signals

Control drift is increasingly an identity governance problem, not just a platform hygiene issue. If live state and approved state diverge, IAM assurance breaks down because reviews certify paper controls rather than operational controls. The practical next step is to treat configuration integrity as part of identity governance and link it to continuous monitoring.

The scale of the issue is already familiar in NHI programmes, where 72% of organisations have experienced or suspect a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities. That same governance pattern applies when municipal systems rely on stale settings and unmanaged exceptions.

Identity blast radius: when small exceptions compound, the security problem shifts from individual misconfigurations to the amount of trust an organisation is still willing to place in a stale environment. Teams should prepare for stronger control-state telemetry, faster remediation workflows, and stricter exception expiry discipline.

For practitioners

• Inventory every security exception and assign an expiry owner Build a register of temporary access, platform, and configuration exceptions, then require an owner, an expiry date, and a review outcome for each one.
• Compare live settings to documented baselines continuously Use automated drift detection to compare current configurations against approved baselines across identity, policy, and platform controls.
• Tie remediation to the control owner, not the alert queue Route drift findings to the team responsible for the setting itself so correction happens where the change originated.
• Review privileged and exception paths after every major change Re-check admin roles, conditional access exceptions, and emergency changes after deployments, incident response, or policy updates.

Key takeaways

• The Saint Paul incident shows how security programmes can fail gradually when configuration drift is allowed to accumulate unchecked.
• The governing risk is not one bad change but the steady loss of confidence that documented controls still match the live environment.
• Teams should operationalise drift detection, exception expiry, and live-state validation if they want their control model to remain credible.

Key terms

• Configuration Drift: Configuration drift is the gradual mismatch between approved security settings and the live environment. It happens when exceptions, emergency changes, or ad hoc fixes remain in place long after they were introduced, weakening the organisation's intended control posture.
• Control Baseline: A control baseline is the documented reference state an organisation expects systems to maintain. It is the benchmark used for assurance, but it only remains meaningful when teams continuously compare it to actual production settings and update it as operations change.
• Security Exception: A security exception is a deliberate deviation from a policy or control, usually granted to solve an immediate operational need. It becomes risky when ownership is unclear, expiry is not enforced, or the exception silently turns into permanent practice.

What's in the full article

Senserva's full analysis covers the operational detail this post intentionally leaves for the source:

• The specific configuration drift management workflow used to detect baseline deviation across Microsoft environments
• The automated remediation approach that closes gaps once drift is identified
• The Saint Paul case framing and local-response context that informed the original commentary
• The practical assessment offer and consultation details for organisations comparing their current posture

👉 Senserva's full post covers the local response context, configuration drift framing, and remediation approach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.