The External Identity Challenge

Think of your identity program as having once been a castle with high walls — all employees inside, all systems behind the gate. Then came the expansion. Third‑party vendors, partners, suppliers, even customers themselves started interacting directly with your cloud assets, APIs, and data stores. What used to be “outsiders” outside the gate are now part of the daily traffic flow.

Recent research backs this up. A Thales blog post noted that in many large enterprises, non‑employee external identities now make up almost half of all users touching corporate networks, endpoints, or cloud services¹.  These are contractors, partner accounts, shared portals, sometimes even IoT devices belonging to vendors. The point is: external identity isn’t an edge case. It’s central — it’s everywhere — and often under‑governed.

Managing external identities brings a set of layered risks that many IAM programs discover only after something goes wrong.

Firstly, there is the issue of inconsistent assurance. Not all external identities are equal in terms of how they are managed. Some partners run sophisticated IAM with MFA, device hygiene, log monitoring; others barely have secure passwords. Yet, in many organizations, all external identities are treated more or less the same once federated or given access.

Then there’s lifecycle risk. External identities often don’t flow through the same “joiner‑mover‑leaver” processes you use internally. Offboarding external users, revoking access when relationships end, expire of temporary contractor permissions — all of these are often manual, inconsistent, or ignored entirely.

Federation is another double‑edged sword. It promises fewer credentials to manage, more seamless experience for external users, and better trust propagation. But federation misconfigurations, lax assurance of partner IdPs, or insufficient checks on what attributes are shared — these can become dangerous cracks in your security fabric². 

Finally, there’s compliance and audit risk. As regulations like NIS2 and other supply chain security laws evolve, you’ll be held responsible not just for what you control—but what your external entities do. If a partner’s credential is compromised and your systems suffer, you’ll need to show you did everything reasonable to govern that access.

So if these risks are real and getting harder to ignore, why are so many organizations still struggling?

A lot of it comes down to legacy mindset. Many IAM programs were built when “users” meant employees, contractors employed directly by the company, or maybe partners with tightly controlled access. The idea of “external identity” as a broad category wasn’t baked into the architecture, tooling, or policies.

Also, tool sprawl and standards mismatch make it hard. External users may need different flows, different identity proofing, different authentication strength. But your IAM stack might treat them the same, or worse — lump them in with internal users when that’s inappropriate.

On top of that, data about what external identities do is often missing. Usage logs, device posture, which applications those users really need access to — that information either isn’t collected, isn’t surfaced, or isn’t trusted enough to drive policy. Without that visibility, governance is reactive.

If you want external identity to stop being a risk vector, you need to build controls that treat them not as “outsiders,” but as partners in your IAM program — with governance, rigor, and clarity.

Start with defining classes of external identity. Not all non‑employees should or need the same level of access or assurance. Define what a “partner,” “vendor,” “contractor,” “supplier,” etc. means in your environment. For each class, define minimum standards: how they authenticate, how you federate with them (if at all), what attributes they must provide, what device or environment assurances they need.

Next, integrate those external identity classes into your access‑lifecycle processes. That means onboarding, periodic review (or certification) of their access, clear responsibility for approval, defined expiration or renewal of their access, and offboarding when the relationship ends. Don’t rely on someone remembering; build systems to remind and enforce.

Federation should be designed carefully. It’s powerful, but only if you carefully vet partner IdPs, limit what attributes they share, ensure strong assertion validation, and support revocation of federated trust. The documentation from Google’s guidelines around federating external IdPs for Google Cloud is a good reference for practices around mapping identities, limiting authority, and ensuring secure assertion handling.³ 

Finally, auditability and contracts matter. When you bring on a partner, vendor, or external identity, your contracts should include IAM obligations: identity proofing, credential hygiene, incident notification, and revocation clauses. Regular audits of partner identity compliance (or at least self‑attestation) help ensure that policies you assume are being followed actually are.

Thales put out a recent blog where they described B2B IAM as “noodle soup” — messy, varied, and hard to standardize. They reported that external identities now represent nearly half of all identities interacting with enterprise systems in many organizations.⁴  They call out that while many enterprises support federation or third‑party access, few are consistent about how external identities are managed, how to classify their risk, or how to enforce lifecycle controls. The metaphor fits: many ingredients in the soup, many flavors, many things going on — and if even one flavor is off, the whole bowl gets soggy.

External identities used to feel like someone else’s problem. But now, they are everyone’s problem. You might not “employ” the person on the other end, or manage their devices, or pay their certification costs. But their access touches your systems, your brand, your liability, your audits. That means governance matters as much (or more) than for internal users. Treat external identities not as guests, but as partners bound by contract, policy, and process. Because in a borderless enterprise, the walls are gone — the only trust that holds is the trust you build and enforce. Huh..you would think someon created a product that did just that…anyway…I digress.