Guest accounts outlive the guest

Every company has a version of this story. A partner sends a consultant. Somebody opens them an account. The engagement ends — or, worse, the consultant leaves the partner halfway through it — and the account stays exactly where it was, entitled to everything it was entitled to on the first day.

The uncomfortable part is not that the account exists. It is that nobody at your company is in a position to know when it should stop existing. The one person who could tell you works somewhere else, and telling you is not their job.

Verifiable credentials do not make that problem smaller. They move it to the only organisation that can actually answer it. Here is the whole mechanism, using the scenario we keep coming back to: Alpha Trading Co needs Brandon Chen of ACME Advisory in a deal room, and Alpha has never met Brandon.

Two companies agree before anyone asks for anything

The agreement is between the two organisations and happens long before any individual needs access.

Nothing in that picture involves Brandon. Two security teams establish, once, that each will accept credentials the other issues — and that is the whole of it. It is closer to a correspondent banking relationship than to an account request: the expensive, careful part happens once, between institutions, and every individual afterwards is cheap.

Kira never contacts Brandon

Kira Patel, SVP Finance at Alpha, never emails Brandon and never asks anyone at ACME to confirm he works there.

Kira does not raise a ticket, does not ask IT to create anything, and does not ask ACME to vouch for Brandon in an email. She chooses the access she wants him to have and types his work address. The platform recognises the domain as one Alpha already trusts, and that is the entire internal half of the process.

Brandon proves it from a phone

Brandon proves who he is with something his employer already gave him, and his attributes travel with the proof.

Notice what did not happen. Nobody typed Brandon’s job title into a form at Alpha. Nobody emailed a spreadsheet of consultant names. Alpha did not invent a password for him and then reset it three weeks later. The attributes that decide what he can see — his title, his seniority, his department — arrive as assertions from the organisation that employs him, which is the only organisation with any standing to make them.

That matters beyond convenience. A self-asserted email address is not identity proofing, and an attribute someone typed by hand is stale from the moment it is saved. Both are things auditors ask about, and both are things most guest-account processes cannot answer well.

The part traditional IAM cannot do

The same two organisations, one state apart. Alpha finds out from the re-verification, not from a message somebody remembered to send.

This is the whole argument, and it is worth being precise about why it works. Alpha is not being told that Brandon has left. Alpha is asking ACME, on a schedule, whether the credential it accepted is still good — and one day the answer is no. The event that matters happens at ACME, in ACME’s own offboarding process, for ACME’s own reasons. Alpha inherits it.

Compare the two failure modes honestly:

The usual way. Brandon keeps his Alpha login for months. Kira has no idea he has gone. The quarterly access review is the first chance anyone has to notice, and it is a review of a list nobody has fresh information about. Every consultant departure is a small piece of hidden risk that ages quietly.
With an employer-issued credential. The status is re-checked against the issuer rather than remembered. When it changes, the guest identity and every entitlement derived from it go with it, and the sequence is written down for whoever asks later.

What this does not fix

Three honest limits, because a mechanism described only by its best day is not much use:

The partner has to issue credentials. This works between organisations that have both done the setup. A supplier with no identity provider worth the name is still a manual problem, and the trust has to be established before the first request, not during it.
Still employed is not the same as still on your deal. The credential tells you Brandon works at ACME. It does not tell you he should still be in your data room after the engagement ends. Scoping and end dates remain yours to set and enforce.
Revocation is as fast as your re-verification. "Continuous" means on a cycle, not telepathic. How much exposure sits between the revocation and your next check is a number you should know and should choose deliberately.

None of that undoes the change. The gap that closes here is the one nobody was ever in a position to close: the distance between a fact that lives inside your partner’s HR system and an entitlement that lives inside yours.