What happens when third-party access is managed without federated identity controls?

Without federated identity management, external users such as contractors, suppliers, and partners often become difficult to onboard and harder to control. That increases the chance of fragmented permissions, weak oversight, and compliance gaps. Federated identity gives security teams a cleaner way to streamline access for non-employees while keeping authentication and authorization under enterprise governance.

How third-party access breaks down without federated identity

When external access is handled locally in each application or team, the result is usually duplicated accounts, inconsistent onboarding, and uneven revocation. Contractors and suppliers may get the right access once, but the organisation loses a clean control plane for confirming who they are, what they can reach, and when their access should end.

The practical problem is not just convenience. Localised third-party accounts make it harder to apply one policy for authentication, authorization, session lifetime, and review. That creates drift across systems, especially when external access is temporary, cross-functional, or shared across multiple business units.

Onboarding becomes slower because each application may need a separate account, approval flow, and password or token setup.
Offboarding becomes unreliable because access revocation has to be repeated everywhere the third party was added.
Permissions accumulate unevenly because each team makes local decisions without a unified entitlement model.
Audit evidence becomes fragmented because no single identity source can show who had access across the full third-party footprint.

For third parties, federation shifts trust to a governed identity provider and a standard assertion path. That reduces duplicated credentials and makes access decisions easier to centralize, but only if the enterprise also defines clear role boundaries, expiry rules, and ownership for every external relationship. Federated access without governance still leaves you with an identity problem, just a more distributed one.

Why unmanaged third-party access creates security and compliance drift

Without federated controls, organisations often compensate with shared logins, manually issued passwords, or ad hoc exceptions. Those patterns weaken traceability and make it difficult to prove that access was granted for a valid business need and removed on time. NHIMG’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which is a strong indicator of how quickly external access can widen blast radius when governance is weak.

Third-party access also tends to stretch beyond the original use case. A supplier may start with a narrow support role, then inherit broader permissions through exceptions, temporary troubleshooting access, or environment overlap. Over time, those exceptions become standing access, and standing access is where review and revocation usually fail first.

Shared credentials reduce accountability because multiple people may use the same access path.
Manual account creation increases the chance of stale entitlements and missed deprovisioning.
Broad exception handling weakens least privilege and makes entitlement review less meaningful.
Missing federation can undermine compliance because access attestations are harder to reconstruct after the fact.

Federated identity does not remove the need for oversight, but it gives security and compliance teams a consistent way to trace external access back to an approved trust relationship. That consistency matters most where third parties operate across sensitive systems, regulated data, or multiple environments.

What good third-party access management looks like

A workable model starts with central identity governance, not just a technical sign-in method. External users should be associated with a sponsoring business owner, a defined role or purpose, and a bounded access period. Where possible, access should be issued through federation, with authentication performed by the external identity provider and authorization enforced by the enterprise.

Practitioners should pay attention to the lifecycle, because the lifecycle is where third-party risk usually accumulates. The most common failure is treating onboarding as the main task and offboarding as an afterthought. For third parties, the offboarding path needs to be just as explicit as the initial approval path.

Use one authoritative process for approving external access and recording the business justification.
Bind each third-party relationship to an owner who can confirm whether access is still needed.
Set expiry dates or review points so access does not become permanent by default.
Keep authentication and authorization separate from local application accounts wherever federation is available.
Review third-party permissions for scope creep, especially where support, integration, and admin access overlap.

When this model is in place, the organisation gains better visibility, cleaner revocation, and stronger auditability. If it is absent, the security team may still know that access exists, but not whether it is current, appropriate, or consistently enforced.

Risk and Threat Considerations

Third-party access without federated controls increases the chance that access will outlive its business purpose, remain poorly scoped, or be reused in ways that are hard to trace. That creates a practical exposure window for unauthorized access, credential misuse, and compliance failure, especially when suppliers, contractors, and partners touch sensitive systems.

Failure mechanism: Local accounts, shared credentials, and manual deprovisioning produce entitlement drift, so revocation is incomplete and permissions are harder to audit across multiple systems.

Impact: A stale or overbroad third-party account can persist after the relationship ends, creating preventable access risk, weak evidence for audits, and a larger blast radius if the account is abused.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	Third-party federation directly shapes how external users are authenticated and authorized.
Recommendation — Define and enforce centralized access controls for external users and their role boundaries.
NIST SP 800-63	IAL/AAL/FAL — Digital Identity Assurance	Federated third-party access depends on assurance in identity proofing, authentication, and federation trust.
Recommendation — Set assurance requirements for federated external identities before granting access.
CIS Controls v8	6 — Access Control Management	External access without federation creates account sprawl, weak revocation, and entitlement drift.
Recommendation — Inventory, review, and remove third-party access paths on a defined schedule.
DORA	ICT third-party risk management — ICT Third-Party Risk Management	Managed third-party access is a core operational resilience and vendor-risk issue for regulated entities.
Recommendation — Govern third-party access as part of ICT supplier oversight and resilience control.

Practitioner Guidance

What to prioritise: Focus first on the third-party relationships with the broadest access, the longest lifetime, or the weakest ownership. Those are the cases most likely to turn a convenience issue into a material control failure.

What to verify: Confirm that every external user has a named sponsor, an expiry or review date, and a revocation path that actually reaches every system where access was granted. If any of those three are missing, the access model is not yet governed.

Common mistake: Teams often treat federation as a login improvement rather than a lifecycle control. The real value comes when federation is paired with authoritative onboarding, periodic review, and consistent offboarding.

Practitioner takeaway: The key test is not whether a third party can sign in, but whether the organisation can prove who they are, limit what they can do, and remove access everywhere when the relationship ends.