A supplier's compromise gives an attacker access to your systems. What should the architecture have done?

The assumption to design against

A supplier will be compromised. Questionnaires and certifications assess a point in time and do not prevent it, so the architecture's job is to limit what a compromised supplier can reach and to detect it quickly.

The controls that matter

• Least privilege for supplier access, scoped to the specific systems and data the service requires. The common failure is broad standing access granted at onboarding and never narrowed.
• Time-bounded and just-in-time access, so a compromised credential is useful only during an approved window rather than indefinitely.
• Separate credentials per supplier, with individual revocation, so containment does not mean disconnecting everyone.
• Network segmentation, so supplier access reaches a defined zone rather than the estate.
• Monitoring of supplier activity, with alerting on deviation from the normal pattern — this is what detects a compromise, since the credentials themselves are valid.
• Data minimisation in what the supplier receives, because what they never hold cannot be lost with them.

The dependency that is easy to overlook

Suppliers inside the build. A compromised package, a build plugin or a CI action runs with the pipeline's authority and reaches production without any external access at all. That needs dependency pinning, provenance verification, and a pipeline whose credentials are scoped as tightly as any supplier's.

What must exist operationally

• An inventory of suppliers, their access and the data they hold, maintained rather than assembled during the incident.
• A rehearsed disconnection procedure, since deciding how to cut off a supplier while under attack is too late.
• Contractual notification obligations, because the most common way this is discovered is the supplier telling you — and the notification timeline determines the exposure window.