How to implement NIS2 access controls for supply chain security

Third-party involvement in breaches reached 48 per cent in 2026, up from 30 per cent the previous year – a 60 per cent increase that underscores the urgency of supply-chain access control, according to Verizon’s 2026 DBIR.

 

NIS2 Article 21 mandates appropriate and proportionate cyber-security risk-management measures. These measures explicitly include supply-chain security, access control policies, asset management and multi-factor authentication or continuous authentication where appropriate. The regulation requires measures tailored to your risk profile and asset sensitivity.

 

For supplier access, this translates into a specific obligation: identify which external users, systems, support accounts, APIs and integrations can reach critical assets, then govern them through documented supply-chain security, access control and privileged account policies. ENISA’s 2025 technical implementation guidance reinforces this by treating these policies as required topic-specific controls that must be enforced.

 

Supplier risk becomes an identity-control problem the moment a supplier has remote or privileged access. A vendor VPN account, a managed service provider’s administrative console access, or a cloud provider’s API token all create direct paths into your network and information systems. Without enforceable access controls, these paths become breach vectors.

 

Build a supplier access control record

 

The operational foundation for NIS2 supply-chain access control is a supplier access control record – a documented entry that links each supplier relationship to specific access rights, authentication requirements and audit evidence.

 

Create one record per supplier relationship. The record should capture:

• Supplier and owner: Supplier name and the internal business owner responsible for the relationship (for example, cloud support provider – IT operations)
• Access path: How the supplier connects – VPN, ZTNA, SaaS admin console, API, repository or remote support (for example, vendor VPN account)
• Identity type: Named user, shared account, service account or API token (for example, a named support engineer)
• Control mechanism: How access is restricted – MFA, privileged access management approval, time limits, IP restrictions or vault-based access (for example, MFA plus privileged session approval)
• Evidence: What proves the control is working – logs, access reviews, contract clauses or approval tickets (for example, quarterly review records)

 

This list demonstrates that supply-chain risk has been converted into enforceable access control and serves as the starting point for your supply-chain security policy. ENISA guidance expects that policy to govern relationships with direct suppliers and service providers and to identify supplier roles.

 

Apply least privilege, MFA and privileged credential controls

 

Critical supplier access must be restricted by business purpose, role, duration and asset sensitivity. Prioritise MFA or continuous authentication for remote access, privileged administration, production systems, VPN or ZTNA entry points, SaaS admin consoles, source-code repositories and systems containing sensitive data.

 

Practical controls to implement:

• Use named accounts instead of shared accounts – access should be traceable to a specific person or service account
• Apply role-based access control – restrict permissions to the minimum required for their business purpose
• Use just-in-time privileged access – approval workflows should grant elevated access for a defined duration only
• Log all supplier sessions – session recording and activity auditing are non-negotiable for privileged access
• Vault shared supplier credentials – store them in a centralised password manager with role-based access, audit trails and rotation policies
• Rotate API tokens and secrets regularly – implement automated secret scanning and rotation to reduce exposure windows
• Revoke access immediately upon contract termination, personnel change, or role change – deprovisioning delays are a common breach vector

The goal is appropriate and proportionate control. A vendor who accesses only non-sensitive, read-only data via a web portal needs less stringent controls than a managed security service provider with SSH access to production systems.

 

Passwork, an ISO 27001 certified password and secrets manager, enforces all these controls in a single ecosystem. It centralises shared vendor credentials, enforces least privilege through role-based vault access, logs all credential usage, rotates secrets automatically and retains full audit records for compliance reviews. This integrated approach eliminates fragmentation in managing supplier access.

 

Put access requirements into supplier contracts and reviews

 

Access controls fail when supplier contracts do not define responsibilities. ENISA guidance recommends that contracts include cyber-security requirements, incident notification duties, audit rights, vulnerability handling procedures, subcontracting disclosure and termination obligations.

 

Translate this into practical contract clauses:

• Suppliers must use named accounts and prohibit credential sharing
• Suppliers must enforce MFA for privileged or remote access
• Suppliers must notify the customer of security incidents without undue delay
• Suppliers must disclose any subcontractors that need access to customer systems or data
• Suppliers must support log retention and audit requests for compliance verification
• Suppliers must return or securely delete customer information at contract termination

For all suppliers, review access at least annually. For critical suppliers (those with privileged or remote access) review quarterly. Review immediately after an incident, contract change, role change or termination. Document each review with sign-offs from the business owner and the security team.

 

Common implementation challenges and how to address them: Suppliers resist named-account requirements: Explain that shared credentials violate audit trail requirements and create liability for both parties. If the supplier cannot provide named accounts, reduce the access level to match the risk tolerance of shared credentials.

 

Existing infrastructure predates MFA: Implement MFA in phases. Start with suppliers that have the highest privilege or access to the most sensitive systems. Use risk-based prioritisation: remote access, production systems and sensitive data are the highest priority.

 

Suppliers claim they cannot support quarterly access reviews: Quarterly reviews do not require a full audit. A simple review involves asking, “Are the same people still in the same roles? Has anything changed?” If nothing has changed, a sign-off takes minutes.

 

Deprovisioning takes weeks: Build deprovisioning timelines into the contract. For example, “Upon termination notice, supplier shall revoke all access within 48 hours.” Include this in the SLA and make it a contract compliance metric.

 

Conclusion

 

NIS2 supply-chain security is access control applied to external users. Map every supplier relationship to the systems and accounts they use. Enforce least privilege, MFA and privileged credential controls. Embed these obligations into contracts and conduct regular reviews. Keep evidence of approvals, controls, logs and reviews.

 

Start by auditing your current supplier access. Identify which suppliers have remote, privileged or sensitive-data access. For each, create a record, define controls and document the contract clause. If your team manages shared vendor passwords or privileged supplier credentials, Passwork provides an ISO 27001 certified ecosystem where you can organise access, enforce least privilege and retain audit evidence in one controlled environment.

---

Passwork is built for teams that need to govern shared credentials, enforce role-based access and retain audit trails for compliance. See how it works.