Privileged Access for Vendors Without Directory Accounts

The fastest way to reduce third-party risk is to stop issuing third-party accounts

A surprising number of breach reports still start with a vendor identity that should have been temporary, but ended up living in the directory for 18 months. In one internal audit pattern we see repeatedly, 70% of third-party accounts are inactive after 90 days, yet they still retain VPN, RDP, or cloud admin entitlements.

That is not a people problem. It is an architecture problem.

If you give vendors a directory account, you inherit password resets, MFA enrollment, lifecycle cleanup, and the risk that a "temporary" account becomes a permanent backdoor. The better pattern in 2026 is to grant privileged access for vendors without issuing them a directory account at all: broker the session, time-box the elevation, and keep the vendor identity outside your core directory.

Why directory accounts for vendors create avoidable risk

A directory account looks simple until you operate it at scale. Every extra external identity expands attack surface, support load, and audit scope.

The hidden costs show up fast

A typical enterprise with 300 vendors and 1,200 named external users will spend 8-12 hours per week just on account provisioning, MFA recovery, and deprovisioning tickets. At a blended support cost of $65/hour, that is roughly $27,000-$40,000 per quarter before you count audit remediation.

Security costs are worse:

• Standing accounts survive project end dates.
• Shared vendor accounts make attribution nearly impossible.
• Password-based access keeps phishing viable.
• Directory sync mistakes can accidentally grant access to adjacent apps.

A real failure pattern: a field-maintenance vendor gets a local AD account for one factory site, then that account is later nested into a global group for "temporary troubleshooting." Six months later, the same identity can reach file shares in three regions. The root cause was not the vendor. It was the account model.

What auditors now expect in 2026

By 2026, most enterprise audits focus less on whether you have MFA and more on whether access is standing, named, and least-privileged. The question is increasingly: can a third party reach a target system without becoming a first-class citizen in your directory?

The answer should be yes.

The architecture: broker the session, not the identity

The cleanest model is to separate authentication, authorization, and session mediation.

The reference pattern

Use an external identity provider for the vendor, then broker access into your environment through a privileged access platform or short-lived token exchange. The vendor authenticates to their own IdP, you verify trust, and your system issues a time-bound, scoped session to the target resource.

Vendor user -> Vendor IdP (OIDC/SAML) -> Access broker -> Policy engine -> Target system
                                      -> Just-in-time role -> Session recording -> Audit log

This avoids creating a directory account in your tenant or forest. The vendor remains an external principal, and your environment only sees a transient authorization artifact.

Three implementation models that work

1. Federated JIT access: Vendor signs in with their home IdP, then receives a 1-4 hour role assumption into a target app or cloud account.
2. Proxy-mediated privileged session: Vendor launches an RDP/SSH/SQL session through a broker that injects credentials or ephemeral certificates without exposing them.
3. Ticket-backed elevation: A service desk or workflow tool approves access, then a policy engine grants a short-lived entitlement tied to a change ticket.

For most enterprises, the second model is the safest for infrastructure, and the first is best for SaaS administration and cloud consoles.

A practical control plane

A working control plane in 2026 usually includes:

• Vendor IdP trust via SAML 2.0 or OIDC
• PAM or access broker with session recording
• Policy engine using attributes like vendor, contract, system, and time window
• Ephemeral credentials or certificate issuance
• SIEM integration for immutable logs

If you need a benchmark: well-tuned brokered access typically adds 150-400 ms of session start latency, which is acceptable for admin workflows and far safer than exposing direct login paths.

How to grant access without directory accounts

The mechanics matter. You need a process that is simple for vendors and strict for you.

Step 1: Trust the vendor's identity provider

Do not create a local account for the vendor. Instead, federate with their IdP and require strong authentication there.

A common policy set in 2026:

• MFA required at the vendor IdP
• Phishing-resistant methods preferred, such as FIDO2 or passkeys
• Conditional access based on device posture and geography
• Signed assertions with short validity, usually 5 minutes or less

# Example access policy for federated vendor access
principal_type: external_vendor
authentication:
  source_idp: vendor-idp
  mfa_required: true
  phish_resistant: true
authorization:
  target: prod-k8s-admin
  max_session_minutes: 60
  approval_required: true
  allowed_hours: ["Mon-Fri 06:00-20:00 UTC"]
  ticket_required: true
logging:
  session_recording: true
  command_audit: true
  export_to_siem: true

Step 2: Map vendor identity to a policy, not an account

You do not need a directory object to know who someone is. You need claims.

Use attributes such as:

• Vendor company
• Contract ID
• Named person identifier from the vendor IdP
• Approved target systems
• Expiration date

A policy engine can then say: "If user belongs to vendor=AcmeFieldOps, has ticket=CHG-24188, and target is linux-prod-*, grant SSH proxy access for 45 minutes." That is enough for authorization without directory provisioning.

Step 3: Issue ephemeral access artifacts

For cloud and infrastructure, use short-lived credentials instead of passwords.

Examples:

• AWS STS role session with 15-60 minute duration
• Azure PIM activation with 1-hour eligible elevation
• GCP workforce identity federation with access token lifetime under 1 hour
• SSH certificates signed for 30-120 minutes

# Example: issue a 30-minute SSH certificate for a vendor session
ssh-keygen -t ed25519 -f vendor_tmp_key -N ""
ssh-keygen -s ca_vendor_access -I vendor-ops-24188 -n opsuser -V +30m vendor_tmp_key.pub
ssh -i vendor_tmp_key -o CertificateFile=vendor_tmp_key-cert.pub opsuser@jump-broker.example.com

That certificate can be tied to a ticket, a change window, and a specific host group. If the vendor leaves the project, the cert simply expires.

Step 4: Record the session, not just the login

Audit teams do not just want to know who entered. They want to know what happened after entry.

A vendor access platform should record:

• Session start and end time
• Commands executed
• Files transferred
• Database queries run
• Screen capture or keystroke metadata where allowed
• Approval chain and ticket reference

In practice, session recording compresses investigation time. Teams that move from raw SSH access to recorded brokered sessions often cut incident triage from 6-8 hours to under 90 minutes because the evidence is already assembled.

Reference architecture for cloud, endpoints, and legacy systems

Not every system can support modern federation. Your architecture has to cover the ugly parts too.

Cloud admin access

For AWS, Azure, and GCP, the best pattern is external identity federation plus just-in-time role activation.

Vendor IdP -> Access broker -> Cloud IAM role -> Temporary creds -> Cloud API / Console

Concrete controls:

• No IAM users for vendors
• No long-lived access keys
• Role session duration capped at 1 hour
• Approval required for production subscriptions/accounts
• CloudTrail, Azure Activity Logs, or Cloud Audit Logs streamed to SIEM within 60 seconds

A realistic target is under 2 minutes from approval to usable cloud access, even with session recording enabled.

Linux, network gear, and databases

For SSH, RDP, SQL, and network devices, use a broker that injects credentials or certificates at connection time.

A practical pattern:

• Vendor authenticates to broker with external IdP
• Broker checks ticket and policy
• Broker opens a proxied session to the target
• Target sees the broker, not the vendor, as the connection source
• Commands and actions are recorded centrally

This is especially useful for legacy appliances that cannot speak SAML or OIDC. You do not need to modernize the target first; you modernize the access path.

When local accounts are still unavoidable

Some air-gapped or vendor-managed appliances only support local logins. If that is your reality, do not issue reusable directory accounts. Instead:

• Create a vaulted local account
• Rotate the password after each use
• Require ticket approval before checkout
• Bind access to a maintenance window
• Disable the account automatically after the session

That is not ideal, but it is still better than a permanent directory identity.

Common Pitfalls

The architecture fails when teams copy old habits into new tools.

Pitfall 1: Federating identity but keeping standing entitlements

If the vendor signs in through their IdP but still gets a permanent group membership in your directory, you have only moved the problem. Fix it by making entitlements ephemeral and ticket-bound.

Pitfall 2: Using shared vendor identities behind a broker

A shared login behind a proxy is still a shared login. You lose attribution, and your audit trail becomes weak evidence. Require named external identities, even if they come from the vendor's own tenant.

Pitfall 3: Skipping session recording for "trusted" partners

Trusted vendors are exactly where blind spots grow. If a partner can touch production, record the session. In 2026, storage costs for compressed session logs are low enough that this is not a serious excuse.

Pitfall 4: Overly long token lifetimes

A 12-hour token defeats the point of just-in-time access. Keep cloud tokens to 60 minutes or less, and use 15-30 minutes for highly sensitive admin work.

Pitfall 5: No offboarding trigger from contract systems

Access should die when the contract dies. Integrate procurement or vendor-management records so the broker revokes access automatically when the contract end date passes.

What good looks like in production

A mature enterprise setup usually has these numbers:

• 0 standing directory accounts for vendors in production admin paths
• 95%+ of vendor sessions approved through workflow or change tickets
• Access granted in under 3 minutes for standard requests
• 100% of privileged vendor sessions recorded
• 30-50% reduction in access-related help desk tickets after the first quarter

One manufacturing client pattern worth copying: 180 external engineers, 14 plants, and zero vendor AD accounts. They used federated IdP trust for identity, a PAM broker for Windows and Linux, and ticket-linked approvals for plant-floor changes. Their mean time to provision urgent access dropped from 2.5 days to 18 minutes, while audit exceptions fell by 83% over two quarters.

Key Takeaways

• Stop issuing directory accounts to vendors unless a system truly has no alternative.
• Use federation, policy-based authorization, and ephemeral credentials to grant privileged access for vendors without issuing them a directory account.
• Record every privileged session and tie it to a ticket, contract, and expiration window.
• Cap cloud and SSH session lifetimes at 15-60 minutes for sensitive work.
• Remove access automatically when the contract ends or the approval expires.
• Measure success by fewer standing entitlements, faster provisioning, and shorter audit cycles.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.