Temporary Vendor Access: Reducing Standing Privileges and Supporting NIS2 Obligations

Anatomy of a Shadow Admin

Identity security architectures must balance operational velocity with defensive isolation when provisioning third-party suppliers.

Illustrative scenario: an operator grants a vendor "five minutes" of emergency access for a firewall change. Two years later, the account remains provisioned with standing admin rights - that shadow-admin pattern is what supply-chain governance targets. Under Directive (EU) 2022/2555 (NIS2), essential and important entities must implement cybersecurity risk-management measures, including supply-chain security (Article 21(2)(d)) and documented access-control policies (Article 21(2)(i)).

NIS2 Article 21 and third-party supply chain scope

Management bodies approve and oversee the measures and can be held liable for the entity's infringements of Article 21 (Article 20).

Article 21(2)(d) requires security-related measures for supply chains and supplier relationships, while Article 21(2)(i) requires policies on access control. Article 21(2)(j) covers multi-factor authentication or continuous authentication solutions, depending on risk. Those measures address third-party access risk - they do not by themselves mandate eliminating every long-lived credential, but they do require governance over vendor and maintenance access.

What Article 21 asks of vendor access

1. Article 21(2)(d)

   Supply chain security

   Know which suppliers have a path into your systems, what they can reach, and how that access ends when the relationship changes.

2. Article 21(2)(i)

   Access control

   Document who approves vendor access, how long it lasts, and who reviews it afterward.

3. Article 21(2)(j)

   Multi-factor authentication

   Use MFA where appropriate. Where vendor admin risk is high, prefer phishing-resistant factors configured explicitly in your identity tenant—not inferred from generic token claims alone.

Shared vendor admin accounts and ad hoc logins often show up weakly in central identity telemetry, which makes supplier access hard to audit after the maintenance window ends. In a proposed reference architecture, route vendors through a single hosted login front door so every session is tied to an organization, ticket, and policy set before any brokered elevation.

A practical pattern is to route vendors through your customer-identity tenant (or federation) so organization metadata can bind scoped roles, ticket identifiers, and session lifetime limits before any brokered credential is issued.

The Shadow Admin Problem: Standing Privileges vs Action-Gated Delegation

External partners frequently accumulate standing administrative privileges that persist long after immediate integration tasks are finished. These persistent accounts constitute an expanding attack surface known as shadow administration, as dormant contractor credentials are a recurring theme in supply-chain incident analyses when access outlives the original task and nobody revokes it at window close.

Action-gated delegation ties each elevation to an approved ticket, enforces session ceilings, and aims to end brokered credentials when the work ends—subject to each credential type's termination mechanism (see below).

Standing vendor access vs action-gated delegation

Standing access

Action-gated delegation

• Standing access: ✕Admin rights stay on after the change window closes
  Action-gated delegation: ✓Rights exist only for the approved ticket and window
• Standing access: ✕Shared vendor accounts with no named owner
  Action-gated delegation: ✓Every session is tied to a named person and organization
• Standing access: ✕Removal depends on someone remembering
  Action-gated delegation: ✓Termination is automated where the platform supports it; otherwise requires explicit revoke and verification
• Standing access: ✕Audit shows a login, not the ticket behind it
  Action-gated delegation: ✓Audit links each elevation to its ticket and approver

The Supply Chain Trap Under NIS2

B2B integrations often ship with vendor admin accounts, shared break-glass users, and federation paths that outlive the contract. NIS2 supply-chain measures expect you to know who still has a path in, what they can reach, and how access is removed when the supplier relationship changes - without treating every vendor like a full-time employee on a workforce directory.

Enforcing phishing-resistant MFA and device telemetry

Multi-factor authentication is expected where appropriate under Article 21(2)(j); it does not prescribe FIDO2 for every vendor login.

For high-risk vendor admin contexts, configure explicit MFA policies (for example WebAuthn/FIDO2 passkeys) in the identity tenant rather than relying on a generic amr claim to prove phishing resistance. Post-Login Actions run during primary login and during refresh-token exchange; they can deny login, add claims, or call external APIs, but Auth0 still issues and signs tokens—Actions enrich or gate the flow, they do not replace token signing. Continuous step-up for sensitive API calls belongs in the application, API gateway, or access broker (for example step-up authentication or factor challenge on the route that mints cloud credentials).

Example login flow design:

1. Universal Login presents allowed factors per tenant MFA policy (passkey/WebAuthn first where configured).
2. On interactive login, a Post-Login Action validates organization, ticket metadata, and checks event.authentication.methods for a WebAuthn or passkey method (or your configured phishing-resistant methods). On refresh-token exchange, skip the factor re-check and instead verify the session is not revoked and still meets policy.
3. If policy requires a phishing-resistant factor and the interactive login used SMS or email OTP, the Action executes api.access.deny('Phishing-resistant authenticator required').
4. Documented fallback: named approver, time box, alternate break-glass tenant connection, and audit record—not a standing report-only mode that leaves access in place.

Operators monitor authentication logs for repeated factor downgrades, which indicate unmanaged contractor environments.

Connection toggles, licensing, and what federation disable does not do

Full enterprise workforce identity seats are often a poor fit for episodic vendor access: per-seat pricing can make dormant contractor records costly depending on your vendor contract. Many teams instead provision contractors in customer-identity tenants (for example Auth0 B2B Organizations) rather than workforce directories—if your licensing and connection model supports that pattern.

Enterprise teams use Connection enablement per partner organization to maintain control.

When a supplier contract lapses or an emergency incident occurs, administrators may disable the corresponding identity federation connection in the admin console. Disabling federation is not full offboarding: existing Auth0 sessions, outstanding refresh tokens, and already-issued access tokens can remain valid until they expire or are explicitly revoked (Auth0's default access-token lifetime for custom APIs is 24 h; lower it explicitly); downstream Vault leases and cloud session tokens are separate objects. SCIM deprovisioning may lag across applications. Plan session revocation, refresh-token revocation, and API-side deny lists in addition to flipping the connection.

Pitfalls we plan for

• Shared vendor admin accounts

  −Wrong: One login shared by the whole supplier team.

  +Right: Named accounts per person inside the supplier's organization.

• SMS codes for contractors

  −Wrong: SMS or push approvals on admin routes.

  +Right: Passkeys or FIDO2 for high-risk vendor sessions.

• Federation left on after the contract

  −Wrong: The partner connection stays enabled after the work ends.

  +Right: Disable the connection and revoke sessions/tokens; verify downstream credentials.

• An always-on bypass

  −Wrong: A permanent exception for emergencies.

  +Right: A break-glass path with a named approver, time box, and audit log.

Just-In-Time Access in Practice

The following proposed reference architecture describes an ephemeral access broker that validates session context before minting temporary credentials, with clear component boundaries and trust relationships for short-lived administrative access. It is a design pattern for review—not a statement that every control is a standard Zelto product deliverable unless contracted separately.

Ephemeral identity brokering

The pattern reduces reliance on long-lived cloud infrastructure credentials by coupling Auth0 Post-Login Actions (at login and token refresh) with a HashiCorp Vault cluster. External contractors sign in through the hosted login experience, where identity and ticket claims undergo inspection. Authentication, authorization, secret issuance, and delivery are separate steps:

1. Hosted login (authentication): The contractor signs in; Auth0 issues tokens. Organization and ticket claims are attached via Actions or metadata.
2. Action validation (authorization): A Post-Login Action validates the ticket, MFA policy compliance, and allowed scopes before any secret is requested. This runs on login/refresh—not on every downstream API call.
3. Vault authentication (authentication to Vault): The broker calls Vault's AppRole login endpoint and receives a Vault token scoped to the maintenance role—not the cloud credential itself.
4. Secrets engine read (issuance): With that Vault token, the broker calls the appropriate secrets engine (for example AWS or database) to generate a lease-bound credential.
5. Delivery: The broker returns the short-lived credential to the contractor portal or client; revocation is a separate operational step when the window ends.

HashiCorp Vault can mint dynamic, time-bound credentials (for example AWS STS session credentials or database users) with lease TTL tuned to your change window.

Expiry vs revocation: AWS STS temporary credentials expire at the time AWS enforces in the credential; that does not require a successful Vault revoke call. Vault revokes dynamic secrets automatically when the lease TTL expires, and you can revoke earlier with vault lease revoke. Either revocation can fail (backend outage, missing permissions), so designs need failed-revocation handling and verification at the target system. For STS-based credentials, revoking the Vault lease does not invalidate them. To cut access before expiry, revoke the role's active sessions (an aws:TokenIssueTime deny policy) and confirm that calls with the old credentials are denied. For iam_user and database credentials, retry lease revoke or delete the user, access key, or database role directly at the target. Ending the contractor portal session or revoking Auth0 refresh tokens does not by itself prove downstream cloud credentials stopped working.

The broker passes issued credentials to the client; when the maintenance window ends, operators should revoke Vault leases, revoke Auth0 sessions/tokens where applicable, and verify at the cloud provider or database.

For broader context on structural role isolation and boundary controls across your environment, see Implementing Segregation of Duties and Least Privilege with Access Reviews.

Cryptographic proofs and token invalidation at the API

Access tokens issued to third parties should stay short-lived. Auth0 Actions can add custom claims to tokens Auth0 signs; resource servers validate issuer, audience, and lifetime. A Redis (or similar) revocation cache only protects APIs that check it on every request—document that enforcement explicitly in the broker and each resource API.

Emergency suspension updates that cache so cooperating services deny bearer tokens after propagation (latency depends on topology). APIs that never consult the cache remain vulnerable until tokens expire.

Failed token enrichment in an Action should fail closed (call api.access.deny or let the Action error so the login fails) rather than issuing an unvalidated token.

Key design decisions

Architectural decisions require deliberate trade-offs between implementation complexity and blast radius reduction, including network-level boundary tunnels compared to protocol-level identity brokering.

Decision Matrix: Static VPNs vs Protocol JIT Brokering

Network-level access historically granted contractors broad network visibility via static VPN concentrators. Many teams now prefer protocol-level brokering, where trust evaluation occurs at the application and API boundary rather than the network subnet layer.

The table below compares access brokering trade-offs.

Protocol brokering limits contractor connectivity to explicit reverse-proxied endpoints, which narrows lateral movement compared with flat network access. If a contractor workstation is compromised, protocol-level brokering reduces the risk of broad subnet pivoting compared with a flat VPN tunnel.

Identity Federation vs External Directory Segregation

Organizations must decide between federating into partner identity providers or maintaining segregated contractor accounts inside an isolated customer identity pool. Federating into vendor IdPs delegates credential lifecycle management to the vendor, but limits device posture verification, while segregated customer identity directories allow the host enterprise to mandate hardware MFA policies.

We recommend maintaining an isolated customer directory tenant for external suppliers, as this approach gives the host organization direct control over authentication policies, password complexities, and multi-factor requirements without depending on the supplier's internal IT posture. For deeper architectural approaches to controlling external supplier lifecycles and birthright permissions, review Mastering Access Reviews.

Security and operations

Operational security procedures help keep runtime identity brokering resilient against active compromise through session attestation, abuse prevention, and tamper-evident audit trails—where those controls are deployed and integrated.

Continuous attestation and bot detection with fail-closed controls

Administrative interfaces must protect themselves against automated credential abuse and session theft. Auth0 Bot Detection and risk signals can inform login-time decisions; Post-Login Actions do not run continuously on every administrative click. Sensitive operations should re-check session freshness, step-up MFA, or broker policy in the application or API gateway, not only at initial login.

Where Adaptive MFA is licensed, Post-Login Actions can read risk-assessment signals (IP reputation, impossible travel, new device) from event.authentication.riskAssessment. If policy requires step-up and the user cannot complete a phishing-resistant factor, deny or route to break-glass. The Action logic can run fail-closed: if the third-party risk analysis API does not respond within an example 1200 millisecond timeout, the script executes api.access.deny('Security attestation unavailable').

For vendor API outages, use a documented break-glass path - named approver, time box, and audit log - rather than an always-on bypass, so default posture stays fail-closed.

Audit Logging, Rotation Triggers, and Incident Blast Radius Reduction

Incident response and regulatory expectations call for strong, tamper-evident audit logging of authentication, credential issuance, and privileged API use. In this reference design, authentication logs, Vault audit devices, and API access logs feed a centralized SIEM pipeline—subject to your deployment and retention policies.

• HashiCorp Vault audit logs record dynamic secret generation with correlated Auth0 session identifiers when you wire them that way.
• Resource APIs record administrative transactions alongside the external contractor organization claim.
• Example configuration: rotate AppRole secret IDs on a schedule aligned to your key-management policy.
• Example configuration: alert when brokered administrative sessions exceed two hours (set thresholds to match your SLA).

Centralized audit trails help investigators reconstruct movement during incidents and narrow scope when logging, revocation, and session boundaries work as designed.

A proposed reference architecture (Proposed engagement pattern)

A phased rollout can migrate legacy supplier accounts toward ephemeral brokering with explicit rollback triggers and minimal operational downtime. Treat the phases below as a reference implementation plan to adapt—not a guaranteed turnkey offering unless scoped in a statement of work.

Organizations can structure the transition across four phases:

1. Inventory vendor accounts: Conduct an identity inventory to discover all static vendor accounts across directories and cloud consoles.
2. Configure monitor mode: Configure the Auth0 tenant with Universal Login, Organizations metadata mapping, and log Action decisions without denying (monitor mode in your own Action logic) for identity telemetry only—monitor mode does not remove standing access elsewhere.
3. Pilot with trusted suppliers: Deploy HashiCorp Vault AppRoles and integrate Auth0 Post-Login Actions for a pilot group of trusted external maintenance suppliers.
4. Enforce and retire legacy access: Enforce mandatory fail-closed Actions on login for remaining contractors while disabling legacy VPN accounts and static passwords; verify revocation at each target system.

As an example rollback trigger, treat ticket validation failures above 5% of active sessions during a fifteen-minute window as a signal to pause enforcement (not as a substitute for credential containment). If triggered, operators can use an approved break-glass toggle (audited, time-limited) while engineering diagnoses upstream ticketing API latency—paired with explicit session and lease revocation if access was already minted.