A supplier's breach notice says their support system was accessed — which of your credentials must you replace?

## Sort by direction first A third-party compromise is confusing because "our credentials with that supplier" names two different sets of values with different owners and different remedies. | Direction | Example | Who replaces it | What you must be able to do | |---|---|---|---| | You issued it to them | An account on your side their platform calls, or a credential you created so they could integrate | You | Mint a new one, move them across, refuse the old one | | They issued it to you | A credential your services present when calling theirs | They | Accept a new value without a code change or a release | | Shared through their support path | A value pasted into a ticket, attached to a diagnostic bundle, read out on a call | You | Find it, replace it, and stop putting values there | | Neither, but stored with them | A value they hold on your behalf for an integration you no longer run | You | Establish it exists at all, then replace and have them delete their copy | The first row is the one you can act on immediately and the one most often deferred, because it feels like their incident. It is not: those were **your** values, sitting as copies in an estate that has just been described as compromised. ## Why the support path is the dangerous bucket A support system is, by function, the place where customers put things so that someone can help them. Over years it accumulates configuration files, logs with values in them, screenshots of a console, and tickets where an engineer under pressure pasted a working credential to prove a call failed. None of it is inventoried anywhere on your side. When the notice says the support system was accessed, that archive is exactly what was reached. The practical move is to search **your own** record of what you sent — outbound attachments, your ticket history, the change records around the time an integration was set up — rather than waiting for the supplier to tell you what of yours they held. They usually cannot. ## Their window is an estimate; yours is a fact The notice will state a period. That period is their reconstruction, produced under time pressure, from whatever their own records support, and it will be revised. Meanwhile there is a bound you can defend without them: **a value is at risk from the moment you last changed it**, because anything older than that has been sitting in their estate the whole time. Plan against the longer of the two. The supplier's contract usually sets when they must tell you, and that clock has nothing to do with the exposure window either — a notice can arrive promptly and still describe access that started long before. ## The order of work 1. **List what of yours they hold**, in both directions, from your own records. 2. **Rank by reach** — what a value would let the holder do, not how important the supplier is. 3. **Replace and then withdraw** each of your own values: new value in place, holders moved, old value refused at the system that accepts it. Deleting your copy is not the withdrawal. 4. **Chase their re-issuance** for their values, with a date, and check that your services can take the new one before it arrives. 5. **Record the decision for anything you deliberately do not replace**, with the reason, so it is a decision and not an omission. ## The direction people get wrong Two mistakes are common. The first is assuming the supplier's re-issuance covers everything, which leaves your own values live. The second is assuming replacement retroactively protects you: it bounds what the holder of an old value can do **from now on**, and says nothing about what was already done with it. Establishing that is separate work, and it is not what the trigger is for.