It doesn’t start with a hack.
It starts on an ordinary Tuesday morning.
An external IT provider logs in to resolve a support ticket. The connection succeeds. The account is familiar. The system accepts the identity without hesitation.
Nothing about the access looks unusual.
This is how most serious security incidents in financial services begin—not with alarms, but with routine.
Something is shifting beneath the surface
Banks and insurers pride themselves on maturity. Processes are documented. Access is formally approved. Controls exist. And yet, the reality of their operating model has quietly changed.
Value creation no longer lives solely inside the organization. It extends to core banking vendors, KYC providers, collection agencies, software integrators, insurance brokers. Each partnership brings efficiency. Each one brings access.
That access is rarely designed from a clean model. It emerges from projects. From deadlines. From pragmatic decisions. A VPN connection here. A shared service account there. An API key needed “temporarily.”
Temporary becomes permanent.
Identities persist long after their purpose has expired. Trust becomes implicit. Control fragments across teams, tools, and reporting lines.
The escalation is not dramatic. It is gradual.
The initial compromise almost never happens inside the bank. It happens at the partner. A phishing email at a small IT services firm. Malware on a contractor’s laptop. Credentials reused on a partner portal. An API key exposed in a CI pipeline or code repository.
The attacker does not gain privileged access.
They gain something more dangerous: a valid identity.
From the security stack’s perspective, everything looks correct. The login succeeds. MFA is satisfied—or exempted because “otherwise the tool wouldn’t work.” There is no exploit, no malware signature, no obvious anomaly.
Zero Trust exists as a principle.
Not as a decision made at the moment of access.
Movement does not go up. It goes sideways.
What follows is not a classic privilege-escalation story. The attacker is not hunting for root access. There is no dramatic breakout.
Instead, they move horizontally.
Partner accounts are rarely tightly scoped. They accumulate permissions over time. They span environments because it was convenient. Test, pre-production, and production are often insufficiently separated. Human accounts and service accounts share identities or privileges.
The same identity exists in multiple systems. Not integrated. Not centrally visible. Not continuously evaluated.
The attacker exploits these seams. Application to application. Environment to environment. System to system. Each access is legitimate in isolation. Together, they create a movement space no one explicitly approved.
This is where the damage begins—long before anyone notices.
The impact is larger than most organizations expect
Sometimes the damage is obvious. Customer data is accessed and exfiltrated. Personal information. Account data. Contractual records. Systems respond correctly because access was formally authorized.
Regulatory obligations follow. GDPR. GLBA. State breach notification laws. Supervisory reviews. Reputational damage begins internally, with the realization that the access was not unauthorized—it was insufficiently governed.
Sometimes the damage is subtler. Transaction parameters are modified. Limits adjusted. Fraud rules altered. Weeks later, it becomes impossible to determine whether the issue was an error or manipulation.
And sometimes, nothing appears to happen at all. Backdoors are placed. Logging is reduced. Access paths are prepared. The real attack occurs months later—with far greater impact and exponentially higher incident-response costs.
The most expensive damage is rarely technical.
It is the loss of certainty.
Why traditional security controls don’t see this
This attack is neither network-driven nor malware-driven. It is identity-driven.
Login successful. MFA satisfied. No policy violated. No alert triggered.
Modern security stacks are exceptionally good at detecting malicious activity. They are far less effective at questioning legitimate identities operating in the wrong context.
Identity is verified.
Context is ignored.
Why existing IAM controls are not enough
After an incident, a familiar sentence appears.
“But we have IAM.”
Often followed by a list. IAM. IGA. PAM.
That is usually true.
The issue is not missing tools.
It is misaligned responsibility across identity domains.
Traditional workforce IAM is designed for employees. HR-driven lifecycles. Stable roles. Predictable transitions. It works extremely well—so long as identities belong to the organization.
External partners do not fit this model. They are not HR-managed. Their access is project-based, time-bound, and purpose-specific. Yet they are often administered as if they were internal users, where precision matters most.
Identity governance adds accountability. Certifications provide traceability. Audit trails answer the question of who had access, and when.
What governance does not provide is continuous risk assessment. Governance is periodic. Attacks are not. A compromised identity remains valid until the next review cycle.
Privileged access management protects the extremes. Root. Admin. Break-glass. The crown jewels. It is highly effective where privilege is explicit.
Many third-party accesses do not qualify. They are functionally privileged but not classified as such. APIs, service accounts, and B2B identities operate below the PAM threshold—and above the line of scrutiny.
This creates a gap no one intentionally designed.
Not because something is missing.
But because external identities sit between systems.
And often between owners.
What’s missing is an identity domain that models external access on its own terms—one that contextualizes it and evaluates it continuously.
Then come the questions
After the incident, the attackers are not in the room.
Auditors are. Legal is. Regulators are.
Why did this partner have access?
Why wasn’t it time-limited?
Why was there no clean offboarding?
Who approved it?
Where is the documentation?
And finally, the question that cannot be delegated.
Who is accountable?
Not the partner.
The institution.
The language of regulators is precise
They do not talk about advanced threats. They talk about uncontrolled third-party access. Identity sprawl. Missing least privilege. Lack of continuous access validation. Inadequate identity governance.
These findings are not dramatic.
They are routinely classified as high risk.
The question that remains
If a third-party partner were compromised tomorrow—
and every single access looked technically correct—
would your organization recognize
that someone is moving horizontally through its identity landscape?
Or only when the auditor asks—
and expects an answer.
