Third-Party Risk Rules Are Reshaping B2B Identity Management

Third-party risk is getting harder to ignore. The 2026 Verizon Data Breach Investigations Report found that third parties were involved in 48% of breaches, up from 30% a year earlier. At the same time, the first EU-wide DORA incident report found that 29% of major incidents in 2025 came from failures at third-party providers.

Regulators are taking notice. DORA and amended Regulation S-P put third-party oversight into law for financial firms, and NIS2 covers many other sectors. Even if you aren’t regulated directly, you may face these rules through the contracts of customers who are.

A big share of third-party exposure comes down to B2B access. Partners, suppliers, and customer organizations log in to systems they don’t own, using accounts their own companies manage. Teams now have to prove, at any moment, who from those organizations has access, what they can reach, and that the access ends when it should. That puts B2B identity management at the center of third-party risk.

Why B2B Identities Are Different

With employees, organizations have full control over the identity provider and the HR lifecycle. With partners, vendors, or customer organizations, they have none of that. Third parties authenticate through their own identity systems and onboard or offboard people on their own schedule.

But regulators don’t accept that as an excuse. Under DORA, financial entities stay fully responsible for compliance when they use ICT third parties. The technical standards require a unique identity and user account for every staff member of a third-party provider who accesses the entity’s assets.

The entity must also keep records of those assignments after the contract ends. Generic shared “vendor” accounts are effectively off the table.

Strong Authentication for External Users

Just a password is usually not enough. DORA Article 9(4)(d) requires policies and protocols for strong authentication mechanisms. The technical standards don’t list which methods to use. Instead, they call for leading practices that match the risk of each asset. The technical standards specifically require strong authentication for remote access to the network, privileged access, and access to systems that support critical or important functions.

NIS2 is more specific on this point. Article 21(2)(j) names multi-factor or continuous authentication outright. Its predecessor, NIS1, which was repealed in October 2024, set only general security duties and never mentioned MFA.

The practical answer for this requirement is enterprise SSO, federated with each partner’s identity provider over SAML or OIDC. Then you can enforce MFA at the point of access. Phishing-resistant options like passkeys should be prioritized where possible. Major identity providers are already moving that way, making passkeys the default and phasing out built-in SMS and voice codes.

It’s important to standardize how every organization connects instead of relying on one-off integrations. This lets you enforce the same MFA and access rules consistently.

Least Privilege Across Organizational Boundaries

Strong authentication isn’t the end of third-party risk. That’s why regulators put a lot of emphasis on what happens after.

DORA’s technical standards require access rights based on need-to-know, need-to-use and least privilege. Access must be reviewed at least every six months for systems that support critical or important functions, and it must be withdrawn without delay when it is no longer required.

NIS2 is less specific, but it points the same way. It requires access control policies under Article 21(2)(i). It also requires supply chain security under Article 21(2)(d), which covers an entity’s direct suppliers and service providers.

In practice, this means role-, attribute- and relationship-based access control. Roles define the job, attributes add context, and relationships tie each user to their own partner organization. That keeps one partner from seeing another’s data. A B2B identity management platform can apply those rules to every partner.

Access That Ends When the Relationship Does

A big part of access management is knowing when to take access away.

It starts with the contract. DORA Article 30 requires termination rights and minimum notice periods in contracts for ICT services. For critical or important functions, Article 28(8) also requires an exit strategy that is documented and tested. Regulation S-P works similarly in the US, with written policies and procedures for service provider oversight.

The underlying expectations aren’t new. The 2019 EBA outsourcing guidelines already asked banks, investment firms and payment firms for an outsourcing register and exit strategies. DORA turns them into binding law for a wider range of financial firms and the providers that serve them.

A contract clause doesn’t switch off a login, though. That takes automation. Use SCIM provisioning and deprovisioning tied to each partner’s directory. This way, when a partner’s employee leaves, or the contract ends, access disappears immediately.

Knowing and Controlling Where Identity Data Lives

Rules are also pretty tight around where you process and store identity and other sensitive data. DORA Article 30(2)(b) requires contracts to name these regions or countries. It also requires the provider to give advance notice before changing those locations.

DORA also discourages relying on a provider you can’t leave. If your identity data is stuck with one vendor, you can’t move it when the rules on location change.

Partner identities count as personal data, so GDPR’s transfer rules apply too. One caveat is that the legal footing for EU-US transfers is still uncertain. The EU General Court upheld the EU-US Data Privacy Framework in September 2025, but that ruling is under appeal and still pending at the time of writing. If you move partner identity data between the EU and the US, plan for either outcome.

The practical answer is flexibility. Use multi-region deployment so partner identity data stays in the jurisdictions you need. Pick a platform that can run self-hosted or managed. That gives you a real exit plan, because you can move in-house if the provider becomes a problem.

Evidence for Incident Reporting

Regulations keep the window for incident reporting short, and failure to adhere can lead to hefty fines. DORA requires an initial notification within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. NIS2 requires an early warning within 24 hours and an incident notification within 72 hours.

Under Reg S-P, firms must notify affected customers within 30 days. Their policies must also require service providers to notify them within 72 hours.

The EU’s proposed Digital Omnibus would also send incident reports through a single entry point, aligning GDPR with NIS2 and DORA. It has not been adopted yet, and it would only change where you file, not the DORA and NIS2 deadlines.

Keeping detailed authentication and access control logs for all third-party access will allow you to catch incidents faster, especially if you alert on unusual partner activity, like logins from new locations or access at odd hours.

Conclusion

Third-party risk programs used to live in questionnaires and contracts. Regulators now want operational evidence, and most of it sits in the identity layer. B2B identity management will cover a lot of ground when auditors ask who has access, what they can reach, and when it ends.