Rethinking Vendor Audits
When a bank loses money through a service provider, the typical response is to scrutinize the vendor. Was due diligence thorough? Was the security questionnaire current? Did the Cyber Risk Rating slip before the incident?
This approach shapes most third-party risk management (TPRM) programs. You classify vendors by criticality, send a SIG Core to high-tier ones, review a SOC 2 report, check a Cyber Risk Rating, and repeat annually. The logic is simple: a stronger vendor means a safer institution.
It's not a foolish belief. It's the foundation of SR 23-4 and the EBA Outsourcing Guidelines, both of which expect you to assess a provider's capabilities before and during the relationship.
Why This Approach Falls Short
Vendor-centric assurance asks, "How secure is this provider?" The incident at Crédit Mutuel Arkéa raises a different question: "What can an attacker reach if they get into this provider's platform?"
Arkéa reported that attackers accessed an internal account via a third-party service provider's platform. The provider's platform became a doorway to an internal account at the bank. Regardless of the provider's controls, the damage depended on what that doorway connected to and how little stood between the doorway and the money.
A vendor can pass every assessment and still be a single compromise away from your payment rails. Conversely, a mediocre vendor with tightly constrained access is a manageable risk. The vendor's posture matters, but it's one input. Your exposure is set by your own architecture: entitlements, transaction limits, session controls, and how quickly you notice something odd.
The Evidence
Three details from this incident point the same direction.
Funds moved out to other institutions. Funds were transferred to other financial institutions and could then have been converted to cryptocurrency. The attacker's path ran through your authorization layer, not just the vendor's network. Questions about the vendor's patching cadence don't tell you whether an internal account could initiate transfers of this scale without a second control.
Detection came from outside. The attack was spotted by blockchain investigator ZachXBT, and a cryptocurrency news outlet reported it before the bank confirmed anything. This shows that the first reliable signal of a vendor-path compromise may appear downstream, on-chain, or in counterparty systems, before it appears in your own monitoring. An annual assessment can't catch that. Neither can a quarterly Cyber Risk Rating refresh.
Scale of the reported loss. A regional newspaper reported over €118 million taken; the bank wouldn't confirm the amount but said the order of magnitude was accurate. The group serves 5.8 million customers and manages more than €211 billion in assets, and it said the amounts weren't likely to jeopardize its Financial Viability. That's reassuring for solvency but not as a control outcome. A loss of that order moving through a single provider-facing account suggests the limiting factor was recovery, not prevention.
Note what we can't say. The provider hasn't been named, and the intrusion mechanics haven't been published. Anyone claiming to know whether this was a credential theft, a session hijack, or a provider-side flaw is guessing. That uncertainty is itself the point: your program shouldn't depend on knowing the vendor's failure mode in advance.
What to Do Instead
Keep the vendor assessment. Add an access-path review that runs on your side of the contract.
Map every provider-originated path to value. For each Critical or Important Function, list the accounts, APIs, and portals a provider's platform can touch, and what each can initiate: read, instruct, or release. Treat any path that can move funds as its own risk object.
Constrain by design, not by trust. Apply least privilege to service accounts. Require dual authorization for transfers above defined thresholds, regardless of who or what initiates them. Set velocity and destination limits so a single compromised session can't empty an account.
Make your own detection the first signal. Monitor outbound transfers for new beneficiaries, unusual destinations, and timing anomalies. Add a fast-freeze procedure and pre-agreed contacts at receiving institutions. The bank's report that some funds were frozen shows that speed of recall is where the money gets saved.
Use external intelligence deliberately. Blockchain analysis and similar threat intelligence aren't exotic extras. Build a channel to consume them, and define who acts on a tip that arrives from outside your perimeter, and how fast.
Rewrite the contract around incidents. Tighten the Notification Timeline for Vendor Breach Management, require logs that let you reconstruct provider-side sessions, and secure a Right to Audit that covers access controls on the integration, not just the provider's general environment. Check your Sub-Outsourcing Clause so you know who else sits on that path, which is a Fourth and Nth Party Management question.
Rehearse the bad day. Test Incident Escalation and your Wind-Down Plan against a scenario where a provider's platform must be cut off immediately. If you can't sever the integration without halting payments, you've found a Single-Provider Dependency worth fixing before an attacker finds it.
This aligns with where regulators are heading. European regulators' concern about cyber threats to financial institutions is tied to growing reliance on interconnected systems and external providers. Expect scrutiny of how you contain a provider failure, not only how you vetted the provider. ISO 27036's focus on supplier relationship security supports the same shift from vendor attributes to relationship controls.
When Vendor Audits Are Still Necessary
Vendor-centric due diligence still does real work. Weak providers do get breached, and a Pre-Contractual Assessment is where you catch structural problems like missing MFA, poor segregation between clients, or no incident process. Criticality Classification is also the right way to decide where to spend scarce assessment effort. And for providers with no direct access to your systems or funds, a lighter vendor-focused review is proportionate; building an access-path program around them would be wasteful.
So the argument isn't to abandon vendor assessment. It's to stop treating it as the control. Assessment tells you how likely a provider is to fail. Access design tells you how much that failure costs you. Your program needs both, and right now most are heavily weighted toward the first.
