Most SME breaches begin long before the attacker arrives. They start with small identity failures that accumulate quietly: a dormant account left active, a shared password that never gets rotated, a "temporary" admin permission that becomes permanent. In a recent UK SME breach, attackers didn't exploit a vulnerability—they simply logged in using a contractor account that should have been disabled months earlier.
The breach unfolded in three predictable stages. First, the attacker authenticated successfully using valid credentials. Second, they moved laterally through SaaS tools with inconsistent MFA enforcement. Third, they escalated privileges by exploiting an unmonitored admin role created during a past project. None of these steps required technical sophistication. They required only one thing: identity drift.
This incident highlights a truth SMEs rarely hear: identity is the primary failure surface. Firewalls didn't matter. Antivirus didn't matter. Backups didn't matter. The breach succeeded because identity governance had eroded over time. SMEs need visibility into who has access, why they have it, and how that access changes. Without identity-first observability, breaches like this are inevitable.
The Attack Timeline
The breach began with a contractor account—let's call it "james@contractorpartners.co.uk"—that had been created eighteen months earlier for a short-term finance project. When the project ended, the account should have been disabled. It wasn't.
Here's what made this possible:
Day 1-30: The contractor finished their engagement. HR sent a termination email. IT disabled the AD account. But the contractor's account on the accounting SaaS platform remained active—and no one tracked it.
Day 31-180: The contractor account sat dormant. No one logged in. No one asked about it. It existed in the system with full read/write access to financial data.
Day 181: Attackers obtained leaked credentials from an unrelated data breach (a separate company's database). Using automated tools, they tested these credentials across multiple services. The contractor account credentials worked on the accounting SaaS.
Day 182: The attacker logged in. They had full access to invoices, vendor details, and bank account information. They exported three months of financial data.
Day 183-195: The attacker used the initial access to map the environment. They found the accounting system connected to a CRM platform. They found the CRM connected to a marketing automation tool. None of these integrations enforced MFA consistently.
Day 196: The attacker found an admin role—not a named admin account, but a role assignment that had been created temporarily for a system migration and never removed. This role had elevated permissions across multiple systems.
Day 197: The attacker escalated. They used the admin role to create a new service account with broad access. They exported the entire customer database.
Day 205: The breach was discovered—not by the company's security tools, but by a customer who received a phishing email that only could have come from the stolen data.
The Identity Failures That Made This Possible
This breach succeeded because of five specific identity failures:
1. Contractor Account Lifecycle Gaps
The contractor account was provisioned outside the normal joiner process. It was created directly in the accounting system, bypassing any formal access request workflow. When the contractor left, there was no formal process to trigger its deprovisioning.
What should have happened: Every identity—whether full-time employee, contractor, or third party—should be tracked in a central identity register with a defined lifecycle. When the contractor's engagement ended, their access should have been automatically revoked across all systems.
2. Dormant Account Blind Spot
The contractor account sat unused for six months. No one noticed because there was no monitoring for dormant accounts. The account existed, authenticating successfully, but no human ever looked at it.
What should have happened: Any account inactive for 30-60 days should be flagged for review. Accounts inactive for 90 days should be automatically disabled pending formal review.
3. Inconsistent MFA Enforcement
The accounting system didn't require MFA. The CRM required it only for admin accounts. The marketing automation tool required it for everyone—but allowed SMS-based authentication, which is easily intercepted.
What should have happened: MFA should be enforced consistently across all systems, for all accounts, with phishing-resistant methods (FIDO2, authenticator apps) preferred over SMS.
4. Shadow Admin Roles
The admin role that enabled privilege escalation was created during a system migration project. It was never documented, never reviewed, and never removed. It existed outside the normal access governance process.
What should have happened: Every privileged role should be documented, reviewed quarterly, and removed when no longer needed. Temporary roles should have automatic expiration dates.
5. No Identity Observability
At no point did the company have visibility into the complete identity landscape—who had access to what, across all systems. They had pieces of the picture but never the whole view.
What should have happened: Continuous identity observability that maps every identity across every system, tracks access changes over time, and alerts on anomalies.
Lessons for Every SME
This breach didn't happen because the SME was careless or negligent. It happened because identity governance was treated as an afterthought—something to handle manually when there's time, rather than a continuous operational process.
The attackers didn't need to be sophisticated. They needed the company to have gaps. And gaps in identity governance are easy to find.
Key Takeaways
- Every identity matters—contractor accounts, service accounts, shared accounts. If it can authenticate, it can be exploited.
- Dormant accounts are active threats—an account that no one uses is still an account that attackers can use.
- MFA must be universal—attackers target the weakest link, not the strongest. One system without MFA is all they need.
- Temporary access becomes permanent—unless there's a process to remove it. Temporary admin roles are among the most dangerous identity risks.
- You can't secure what you can't see—visibility into your complete identity landscape is the foundation of identity security.
How to Protect Your Organisation
Start with a 30-minute identity risk review:
- List all active accounts across your core systems—AD, email, SaaS tools, cloud platforms
- Identify dormant accounts—anyone who hasn't logged in for 60+ days
- Review admin roles—document who has elevated access and why
- Check MFA coverage—ensure every system enforces it for every user
- Find temporary access—look for admin roles created for projects that have ended
This simple review won't solve every problem, but it will surface the most common identity risks and give you a foundation for building a more secure posture.
The Path Forward
Identity failures are the primary driver of breaches in 2026. Attackers know that SMEs have gaps—and they automate the process of finding and exploiting them.
The good news: these failures are detectable and preventable. With continuous identity observability, SMEs can see their complete identity landscape, track changes over time, and act before small problems become big breaches.
The question isn't whether your organisation has identity gaps. The question is whether you'll find them before the attackers do.