← Back to Blog

How Policy Erosion Turned a Minor Incident Into a Major Breach

By IdentityFirst Ltd | November 2025

Policy erosion is the slow decay of rules, controls, and expectations. It happens when exceptions accumulate, shortcuts become habits, and "just this once" becomes the new normal. In one manufacturing SME, policy erosion turned a minor phishing incident into a full-scale breach.

The attacker gained access to a non-privileged user account. Under normal circumstances, this should have limited the blast radius. But over the years, the user had accumulated permissions from previous roles—none of which had been removed. They also had access to a shared mailbox used by multiple departments, and a legacy integration that bypassed MFA entirely.

The attacker didn't need to escalate privileges. The organisation had already done it for them.

This breach demonstrates why SMEs need governance-aware orchestration. Policies must be enforced consistently, exceptions must be tracked, and identity drift must be detected early. Without these capabilities, policy erosion becomes a silent threat that only reveals itself during a crisis.

The organisation

This manufacturing SME had been operating for 25 years. They had grown from 20 employees to 180. They had implemented an identity management system early in their growth—Active Directory, an ERP system, and a CRM platform. They had policies documented: quarterly access reviews, role-based access control, least privilege principles.

What they didn't have was enforcement.

The initial compromise

The breach started with a phishing email. A finance employee clicked a malicious link and entered their credentials on a fake login page. Standard phishing. Common enough.

The attacker now had:

In a well-governed environment, this should have been containable. The employee had a standard user account with no elevated privileges. Their access was limited to their department's resources. The blast radius should have been minimal.

But the employee's account had accumulated permissions over seven years of service.

How permissions accumulated

When Sarah (not her real name) joined the company, she was a junior accountant with limited access. Over the years, she was promoted three times: senior accountant, finance team lead, and finally finance manager. Each promotion came with new responsibilities and new system access.

What didn't happen: her old access was never removed.

Year 1: Junior accountant—access to accounting software, finance share drive
Year 3: Senior accountant—added access to the ERP system, vendor payment approvals
Year 5: Finance team lead—added access to the banking integration, board reporting system
Year 7: Finance manager—added admin access to the accounting system

At the time of the breach, Sarah's account had:

The result: one account with permissions spanning seven years of organisational changes, accumulated through neglect rather than any formal access governance.

The second problem: shared resources

Sarah wasn't the only one with accumulated access. The finance department had a shared mailbox—finance@company.com—used by four team members to handle customer inquiries. Everyone had full access to this mailbox.

When the attacker accessed Sarah's account, they also got access to the shared mailbox. Inside, they found:

The shared mailbox wasn't in any access review. It existed outside the formal access governance process.

The third problem: the legacy integration

Years earlier, the company had implemented a third-party reporting tool to generate board dashboards. This tool needed to pull data from the ERP system.

The easy way to do this, the IT team decided at the time, was to create a service account with direct database access. This account bypassed the normal authentication flow—and bypassed MFA entirely.

The reporting tool was decommissioned two years later. The service account was never removed.

The attacker found this account in their enumeration of the network. With some simple password guessing (the password was "Company2021!"), they gained direct database access to the ERP system.

Now they had:

The actual breach

Within 48 hours of the initial phishing email, the attacker had:

  1. Exfiltrated the customer database—12,000 customer records with contact details, order history, and payment terms
  2. Accessed the ERP system—viewed 18 months of transactions, pricing data, and vendor relationships
  3. Compromised the payroll system—viewed employee records, salary information, and bank details for all 180 employees
  4. Established persistence—created two additional service accounts with elevated permissions

The total data exfiltration: approximately 50GB of data.

The role of policy erosion

This breach wasn't caused by a sophisticated attack. It was caused by policy erosion—the slow accumulation of exceptions, shortcuts, and neglected processes.

Here's what eroded over time:

Quarterly access reviews

The policy required quarterly access reviews. In practice, they happened once a year, then occasionally, then never. The last formal access review was 18 months before the breach.

Role-based access control

The policy required that access be tied to roles. In practice, when employees changed roles, their old access wasn't removed—it was just "left in place" until the next review.

Least privilege

The policy required least privilege—employees should have only the access needed for their current role. In practice, privilege accumulated because removing access required effort and justification, while adding access was easy.

Exception tracking

The policy required that any exception to standard access be documented and approved. In practice, exceptions became so common that they were no longer tracked. The legacy integration, the shared mailbox, the temporary RDP access—all exceptions that became permanent.

Service account management

The policy required that service accounts be reviewed quarterly and removed when no longer needed. In practice, no one owned service account governance. They were created when needed and forgotten when not.

What should have happened

This breach could have been prevented—or at least contained—at multiple points:

1. The initial access should have been limited

When Sarah changed roles, her old access should have been automatically removed. This requires either:

2. The shared mailbox should have been governed

Shared mailboxes are a common security gap. They should be:

3. The legacy integration should have been removed

When the reporting tool was decommissioned, the service account should have been:

4. MFA should have been universal

Every account—human or service—should require MFA. The legacy integration and service accounts were operating without any second-factor authentication.

5. Anomalies should have been detected

The attacker accessed the database from an unusual location at an unusual time. This should have triggered:

The cost

This breach cost the company:

The company had cyber insurance, but the payout only covered a fraction of the direct costs. The long-term business impact was uninsured.

Lessons for every organisation

This breach demonstrates a pattern we see repeatedly: not sophisticated attacks, but accumulated governance failures that create opportunity.

Policy erosion is invisible

Unlike a missing patch or a misconfigured firewall, policy erosion doesn't generate alerts. It's a slow process that happens in the background while everyone focuses on more urgent tasks.

Exceptions become permanent

Every exception you make today becomes a potential vulnerability tomorrow. A temporary workaround becomes permanent infrastructure. A one-time access grant becomes a standing permission.

Access reviews are essential

If you're not reviewing access regularly, you're not governing access. Quarterly reviews—even brief ones—catch accumulated drift before it becomes exploitable.

Shared resources are risky

Shared mailboxes, shared accounts, shared credentials—anything shared creates multiple points of failure. Every shared resource should be documented, reviewed, and minimized.

Legacy systems persist

Old integrations, deprecated tools, discontinued services—these leave behind service accounts and permissions that attackers can exploit. Regular cleanup of decommissioned systems is essential.

How to prevent policy erosion

  1. Automate access changes—tie access modifications to HRIS events so role changes automatically adjust permissions
  2. Enforce access reviews—schedule them, make them brief, but make them happen
  3. Track exceptions—every deviation from standard policy should be documented, approved, and reviewed regularly
  4. Decommission rigorously—when a system, tool, or integration is retired, remove all associated accounts and permissions
  5. Monitor continuously—continuous identity observability catches drift before it becomes exploitable

The path forward

Policy erosion isn't a technical problem—it's an operational one. It happens because governance processes aren't enforced consistently, not because people don't care.

The solution isn't more policies. It's enforcing the policies you have.

With continuous identity observability, organisations can see their complete identity landscape, track how access changes over time, and detect the drift that policy erosion creates. This visibility is the foundation of effective identity governance.