DORA Third-Party Access: Enforcing Strong Authentication (MFA) for Vendors and MSPs
Third-party access is one of the fastest ways a password compromise becomes a major ICT incident. Under DORA, financial institutions are expected to manage ICT risk across internal and external dependencies—so vendor access pathways must be governed, monitored, and hardened.
If you need the core requirement breakdown for strong authentication, start here: DORA MFA requirements.
Why third-party access is a DORA hotspot
Most organizations have MFA for employees. The gaps typically show up in:
- MSP/outsourcer admin access
- Vendor support portals
- Remote support tooling (screen-share, “support agents,” jump boxes)
- Shared admin credentials and “temporary” accounts
- Emergency access that bypasses normal controls
These are exactly the access paths that create outsized operational and regulatory impact.
Where MFA gets bypassed in real life
1) Support tools and remote admin channels
Common scenario: a vendor uses a support tool that isn’t tied to your IdP, and MFA isn’t consistently enforced (or is enforced by the vendor only).
Control objective: MFA must be enforced for the vendor’s identity, not just “a connection.”
2) Shared accounts (“vendor_admin”) and emailed passwords
Shared credentials are difficult to monitor and nearly impossible to defend during audit.
Control objective: named accounts + MFA + traceable logs.
3) Break-glass access that becomes normal access
Break-glass should be rare, governed, and reviewed—not a daily workaround.
Control objective: strict governance: approvals, time-bound access, monitoring, and post-access review.
A practical DORA playbook for vendor MFA (what CISOs can implement)
Step 1: Create a vendor access inventory
For each vendor/MSP:
- Access method (VPN, portal, bastion, support tool)
- Systems touched (especially privileged systems)
- Whether access is interactive or API-based
- Authentication method and MFA enforcement point
Step 2: Define “must-have” MFA rules
CISO-friendly baseline:
- MFA required for all third-party interactive access
- Stronger requirements for privileged actions (admin consoles, production systems)
- Time-boxed access for high-risk sessions
- No shared accounts (or a plan to eliminate them)
Step 3: Close the technical gap
Depending on how the vendor connects:
- Enforce MFA via your IdP (preferred)
- Enforce MFA at a gateway/proxy when apps/tools can’t integrate
- Require MFA + device trust for privileged sessions
- Centralize logs so you can prove enforcement
Step 4: Contract + governance
Ensure contracts / third-party policies require:
- MFA usage and minimum factor types
- named accounts and audit logs
- notification requirements for compromised credentials
- review cadence
Audit evidence checklist (vendor access)
- Vendor access inventory (systems + methods + ownership)
- MFA enforcement proof (policy exports / screenshots)
- Sample access tests demonstrating MFA challenge
- Logs showing third-party sign-ins + outcomes
- Exception register for any non-MFA access paths, with approvals + review dates
- Annual review record (or more frequent for critical vendors)
Where Datawiza helps (without rewriting apps)
Datawiza Access Proxy enforces strong multi-factor authentication (MFA) in front of any web app—using either Datawiza MFA or your existing IdP—without rewriting the application.
When vendor access touches legacy web apps or portals that can’t support modern auth, Datawiza Access Proxy can enforce strong authentication in front of the app, allowing:
- consistent MFA enforcement
- centralized evidence (logs + policies)
- reduced reliance on app rewrites to meet governance goals
