When an integration partner leaks credentials: what to do first
Rotate every credential the partner held before doing anything else. Confirm what was exposed, in which systems, and since when. Preserve the partner's incident notice and your own access logs. Check whether a notification duty under NIS2 has already started running, on you or on the partner. Only once the exposure is contained and the record is preserved does the contract file and any claim become worth building.
The legal basis
The relevant instrument is Directive (EU) 2022/2555 (NIS2), in force since 18 October 2024. It sets cybersecurity risk-management and incident-notification duties for essential and important entities across a defined list of sectors, including managed service providers and providers of ICT services under contract.
Whether the duty falls on you, on the partner, or on both depends on how each party is classified under the sectoral scope of NIS2. A credential leak at an integration partner does not automatically transfer that partner's notification duty to you. It can, however, start your own duty running, if the exposed access sits inside your own systems and your own entity falls within scope.
Where the partner delivers integration work through its own subcontractors, the chain of responsibility for the leaked credentials should already be mapped in the agreement — see Subprocessors, including local delivery partners in practice, for how that mapping is normally documented.
What changes in timing and risk
A credential leak does not wait for anyone's internal sign-off process. The moment you or the partner becomes aware of the incident, at least two clocks start at once: the notification clock under NIS2, where it applies, and any contractual notice clock written into the integration agreement itself.
These two clocks are not the same, and they do not always run from the same trigger event. A delay in one does not excuse a delay in the other. The practical risk is not the leak itself — it is losing the evidence of when each side became aware, which is exactly what a later dispute or a regulator will ask for first.
What to do
- Rotate every affected credential immediately — the client's own IT or security function, without waiting for the partner's confirmation.
- Request a written incident notice from the partner — the contract manager, referencing the security clauses of the integration agreement.
- Preserve logs, timestamps, and the partner's notice as received — the compliance or IT function, before any system is reconfigured further.
- Check the entity's own classification and notification status under NIS2 — legal counsel, in parallel with the technical response.
- Notify downstream customers where the contract requires it — the commercial team, only once the scope of exposure is confirmed.
- Open a dated file with a single timeline of events — legal counsel, as the basis for any later claim or defence.
Who decides
| Question | Who decides first | On what basis |
|---|---|---|
| Whether a NIS2 notification duty applies to your entity | Your own compliance function, then the competent national authority | Sector, size, and role classification under NIS2 |
| Whether the partner breached the integration agreement | The parties, then a court or arbitral tribunal under the contract | The incident notice, the preserved logs, and the security clauses |
| Whether personal data was among the exposed credentials | Your data protection function | The nature and scope of the leaked access |
If your situation differs
If the leaked credentials give access to production systems, treat the exposure as active compromise until proven otherwise, and rotate access before you finish confirming scope.
If the partner itself falls within NIS2 scope, its own notification duty runs independently of yours. Your own duty, where it exists, still starts from your own awareness, not from the partner's filing.
If the exposed access was tied to a right the partner claimed to hold rather than to infrastructure it operated, that question sits outside this page — see A token claims to carry a licence tokenised rights for how a disputed right is assessed separately from an operational leak.
What this page does not resolve
This page does not identify which national authority receives a NIS2 notification in your specific jurisdiction, since that depends on the national implementing measure, not on the directive itself. It does not price a review of the incident file, and it does not establish whether the partner is liable — both require the facts of the specific file.
Verified
Last verified: 12 March 2025. Source: Directive (EU) 2022/2555 (NIS2), official text as published on the EU digital strategy portal.
What the file itself can establish about the partner as a counterparty is a separate, factual question — see Counterparty in United Arab Emirates and its limits in for what that kind of check can and cannot confirm.
The same applies to the leaked material as a document — see Document in United Arab Emirates and the deadline for how a document's origin and timing are established once the incident file is open.
Related situations
A related timing question arises where the integration itself is nearing the end of its usefulness rather than the end of its term — see When the contract term outlives the product and the.
FAQ
What is the first step when an integration partner leaks credentials?
Rotate every credential the partner held, across every system it touched, before confirming anything else.
Which deadline is already running?
At least two: the notification clock under NIS2, where the entity falls within its scope, and the contractual notice clock in the integration agreement. Both start from awareness of the incident, not from its resolution.
Who decides, and on what evidence?
The competent national authority decides on the notification duty, based on sector and size classification. A court or arbitral tribunal decides on any contractual breach, based on the incident notice, the preserved logs, and the agreement's security clauses.