Third-party accounts create risk because supplier access often outlives the contract, the project, or the operational need. Under NIS2, that is a governance failure, not a minor administration issue. Teams need lifecycle controls for delegation, review, and revocation so external access does not become permanent by accident.
Why Third-Party Accounts Create NIS2 Compliance Risk
Third-party accounts are a compliance problem because supplier access often sits outside the organization’s normal joiner-mover-leaver discipline. Under the NIS2 Directive, that means access governance, not just technical control, becomes part of the risk posture. External users, service accounts, and delegated administrative access can remain active after a contract ends, a project closes, or a vendor relationship changes.
The practical issue is visibility. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives notes that 92% of organisations expose NHIs to third parties, which shows how quickly external access becomes a supply chain issue. NIS2 does not require perfection, but it does expect organisations to prove they can control access across the full lifecycle. In practice, many teams discover third-party exposure only during an audit, incident review, or contract renewal, rather than through routine access governance.
How It Works in Practice
Third-party risk rises when external accounts are treated as exceptions instead of governed identities. Security teams should map every supplier account to an owner, business purpose, and expiry condition, then tie that record to contract terms and access reviews. The control objective is simple: no third-party identity should exist without a current business justification.
For NIS2 readiness, the strongest operating pattern is to combine identity lifecycle controls with technical guardrails. That usually means:
- time-bound access approvals for vendors and contractors
- regular recertification of active third-party accounts
- automatic revocation when the engagement ends or the ticket closes
- separate treatment of human vendor users and machine credentials such as API keys or service accounts
- logging that shows who approved access, why it was granted, and when it was removed
Standards guidance supports this approach. NIST Cybersecurity Framework 2.0 emphasises access governance and continuous oversight, while the OWASP Non-Human Identity Top 10 highlights the risk of overprivileged and orphaned machine identities. For organisations with mature supplier ecosystems, NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a useful reference for applying lifecycle discipline to external access.
These controls tend to break down in federated environments where contractors use shared workspaces, indirect sub-suppliers, or unmanaged service accounts because ownership and revocation authority become ambiguous.
Common Variations and Edge Cases
Tighter third-party access control often increases onboarding friction and review overhead, so organisations must balance resilience against supplier speed. That tradeoff is real, especially where vendors need rapid access to production systems or shared operational tooling.
There is no universal standard for this yet, but current guidance suggests treating different third-party patterns differently. A short-term consultant, a strategic outsourcer, and an automated supplier integration do not need the same approval path. The safest approach is to classify access by risk, not by job title alone.
Two edge cases matter most. First, delegated administrator accounts can look internal even when they are effectively third-party identities, which makes them easy to miss in reviews. Second, machine-to-machine access from suppliers is often more dangerous than human access because it persists quietly and is rarely challenged. That is why NIS2 programs should align identity governance with contractual offboarding, secrets rotation, and periodic evidence collection. Where organisations fail, it is usually because the identity survives the vendor relationship, not because the original approval was wrong.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Third-party access governance is central to NIS2 compliance and supplier risk. | |
| NIST CSF 2.0 | PR.AC-1 | Supports managing access rights and permissions for external users. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Orphaned or overprivileged non-human identities often include third-party accounts. |
| NIST AI RMF | Governance and accountability help manage third-party access decisions and risk. |
Establish accountable oversight for external identities, with documented risk decisions and review triggers.
