How should teams handle third-party access when SSO is not available?

Use a governed access model with auditable sharing, least-privilege scope, and explicit revocation steps. If a vendor or contractor needs access to a non-SSO app, the organisation should avoid ad hoc password sharing and instead tie access to a managed workflow that records ownership, duration, and removal.

Why This Matters for Security Teams

When a third-party vendor or contractor needs access to an app that does not support SSO, the main risk is not the missing login convenience. It is the loss of identity assurance, central revocation, and consistent auditability. Teams often fall back to shared passwords, inbox-based handoffs, or “temporary” exceptions that become permanent. That pattern weakens least privilege and makes it harder to prove who accessed what, when, and under whose approval. Current guidance from the OWASP Non-Human Identity Top 10 aligns with treating credentials as governed assets, not shared convenience tokens.

NHIMG research shows how often secrets exposure becomes a real operational problem rather than a theoretical one. In The State of Secrets in AppSec, the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations report strong confidence in their secrets management. That gap matters for third-party access because non-SSO workflows frequently rely on long-lived credentials with weak ownership and no reliable offboarding path. In practice, many security teams encounter unauthorised persistence only after a contractor has already left or a vendor account has already been reused.

How It Works in Practice

The safer model is a managed third-party access workflow that makes identity, scope, duration, and removal explicit. For non-SSO apps, teams should assign a named owner, create a documented approval path, and issue access that is narrowly scoped to the task. Where possible, prefer individual accounts over shared ones, and keep access time-bound so it expires automatically or is reviewed at a fixed interval. That is especially important for secrets used by contractors, because access to a password vault is still access to production if the vault is not governed well.

Operationally, the process should include:

• Request approval tied to a business purpose and expiration date.
• Least-privilege access mapped to the smallest viable role or permission set.
• Separate credentials for each person or service, never shared passwords.
• JIT provisioning or manual issuance with a short TTL where automation is not available.
• Revocation steps that are tested, not assumed, including password reset, token removal, and account disablement.
• Audit logging that records who approved access, when it was granted, and when it was removed.

This approach is consistent with The 52 NHI breaches Report, which shows that identity and credential misuse often succeeds where ownership and rotation are unclear. It also aligns with the CISA Zero Trust Maturity Model, which reinforces continuous verification and explicit control of access paths, even when the application itself lacks modern federation. These controls tend to break down in legacy environments where vendor access is maintained through shared admin inboxes, local superuser accounts, or undocumented emergency credentials.

Common Variations and Edge Cases

Tighter third-party controls often increase onboarding overhead, requiring organisations to balance speed against auditability and revocation certainty. That tradeoff becomes sharper when the application is legacy, customer-facing, or used only during incident response. Current guidance suggests that exceptions can be allowed, but only with compensating controls and a short review cycle rather than open-ended access.

Some environments need a different pattern. If the app supports only local accounts, use unique credentials per vendor user and force periodic password resets until the platform can be modernised. If the app cannot log access events, add surrounding controls such as ticket-based approval, session recording at the jump host, or a PAM layer for checkout and return. For highly sensitive environments, organisations should treat vendor access like privileged access, not normal collaboration.

Where this guidance is weakest is in truly unmanaged SaaS or embedded systems that cannot support separate identities, logging, or revocation. In those cases, the practical answer is often to restrict access at the network, workflow, or data layer until the application can be brought under a governed identity model, because a credential that cannot be individually owned cannot be reliably deprovisioned.

Related resources from NHI Mgmt Group

• How should security teams handle standing access for third-party vendors?
• How should security teams handle third-party access that looks legitimate after a supplier breach?
• How should security teams handle third-party NHI access offboarding?
• How should security teams handle third-party NHI access that outlives the vendor relationship?