The most significant attack surface in your identity estate is not inside your perimeter — it is your vendors. Every managed service provider, SaaS integration, IT consultant, and outsourced support team that has access to your systems brings with it a credential that lives outside your direct control. NIS2 and DORA both make one point unmistakably clear: you are accountable for that access, regardless of where the identity originates.
The Scale of the Third-Party Identity Problem
In a typical mid-size enterprise, third-party identities — vendor accounts, partner system integrations, contractor credentials, API keys issued to external services — number in the hundreds. Most have been provisioned through informal processes: a contractor requests access, a ticket is raised, access is granted, and the offboarding step is either forgotten or deprioritised when the engagement ends. The result is a growing population of active credentials attached to people and systems that may no longer have any legitimate reason to hold them.
Unlike your permanent workforce, third-party identities rarely go through the same identity lifecycle governance. They are not captured in your HR system, so automated provisioning and deprovisioning workflows do not apply. They are not reviewed in your access certification cycles, because the tools running those cycles were not designed with external identities in scope. And they are not monitored by your user behaviour analytics, because the baseline of "normal" behaviour was built from internal users. This governance gap is precisely what attackers exploit.
What NIS2 and DORA Require
NIS2 Article 21(2)(d) explicitly requires organisations to implement security measures covering supply chain security, including the security aspects of relationships between entities and their direct suppliers or service providers. This is not a general recommendation — it is a mandatory control category that competent authorities will assess during supervision.
DORA goes further. Article 28 establishes a comprehensive ICT third-party risk management framework that requires financial entities to maintain a register of all ICT service providers, conduct pre-engagement due diligence, establish contractual provisions covering audit rights, security standards, and incident notification obligations, and continuously monitor the risk posed by critical third-party providers. The EBA and ESMA have published regulatory technical standards specifying exactly what those contractual provisions must contain.
The critical point both regulations establish: you cannot delegate accountability. If a vendor's compromised credential is the entry point for an incident affecting your systems, the regulatory exposure is yours. The vendor's own compliance posture is relevant — but it does not substitute for your obligation to govern the access that vendor holds in your environment.
NIS2 and DORA hold your organisation accountable for third-party access to your systems — not the third party itself. A vendor's SOC 2 certification does not satisfy your regulatory obligation to govern how that vendor's credentials are provisioned, monitored, and deprovisioned within your environment. Certification attests to the vendor's internal controls; it says nothing about what they do with the access you gave them.
How Vendors Become Attack Vectors
The anatomy of a supply chain breach follows a consistent pattern. An attacker targets a vendor with access to multiple downstream clients — often a smaller organisation with less mature security controls than its enterprise customers. They compromise a credential held by that vendor, typically through phishing, credential stuffing against a weak authentication mechanism, or exploitation of an unpatched system. Using that credential, they access the downstream client's environment — appearing as a legitimate third-party connection, which blends into the baseline of expected activity.
The detection challenge is acute. Vendor accounts by definition have legitimate access — their traffic looks like authorised activity because it is authorised activity, just not by the original account holder. Standard anomaly detection built around user behaviour baselines performs poorly against this pattern because the behavioural baseline for vendor accounts is typically sparse and irregular. The adversary operating as a vendor account has time, because the detection gap is wide. Session recording on all vendor privileged access is not optional — it is the only control that produces usable forensic evidence after a supply chain compromise.
Governing Third-Party Identities
Effective third-party identity governance starts with visibility. Build a complete inventory of every external identity with access to your systems — account name, vendor, access scope, the internal owner who requested it, and the date it was granted. This inventory is the foundation for everything else; you cannot govern what you cannot see, and most organisations discover significant surprises when they run this exercise for the first time. Orphaned vendor accounts from completed engagements are the most common finding — and the most immediately remediable risk.
From that inventory, apply just-in-time access provisioning for vendor accounts wherever technically feasible. Rather than maintaining standing access that is active 24 hours a day, provision vendor access on request for a defined window and deprovision automatically when that window closes. PAM solutions with vendor access management capabilities support this pattern natively and provide the session recording and audit trail that both NIS2 and DORA require.
Require MFA on all vendor accounts without exception. Privileged vendor access should require hardware-backed authentication — no SMS, no push notifications that are susceptible to fatigue attacks. Enforce this technically, not just contractually; a contractual requirement that is not enforced at the authentication layer is not a control. Your IdP must be able to block authentication for vendor accounts that do not present a compliant credential.
Contractual and Technical Controls
Your vendor contracts must now specify security obligations that would have seemed excessive five years ago. Under DORA Article 30, contracts with ICT service providers must include provisions covering data security standards, audit and access rights for your organisation and competent authorities, incident notification timelines, and the vendor's obligation to cooperate with regulatory examinations. Template your standard vendor security addendum now — retrofitting these clauses into existing contracts under regulatory pressure is a painful and time-consuming exercise.
Technically, segment vendor access at the network and application layer. Vendor accounts should access only the systems required for their specific function — not broad access to your environment provisioned for convenience. Implement privileged access workstations or broker solutions that force all vendor sessions through a controlled, monitored, and recorded channel. The combination of contractual obligation and technical enforcement is what regulators look for when assessing the maturity of your third-party risk programme — and the combination is what provides actual security, rather than documented compliance that does not reflect operational reality.