Two directories federated after an acquisition: an account made in the weaker one reaches your systems - how do you bound that edge?

## What the trust edge actually does A federation trust edge means your systems accept identities authenticated by a directory you do not run. After an acquisition that edge is usually stood up quickly, because engineers on both sides need each other's systems on day one and nobody wants to re-onboard several thousand people. What gets built is typically the cheapest thing that works: the far directory's groups are mapped onto your access groups so that people arrive with roughly the entitlements they had, and the edge is declared done. Eighteen months later, two of everything is still running: two directories, two joiner-mover-leaver processes, two device-management stacks. And the edge is now load-bearing - a grant issued on their side is honoured on yours. ## Why the model does not save you here This is the leaf case that catches people who have internalised 'we check every request'. Walk it through: an account exists in the acquired directory. It authenticates there. An assertion arrives naming that subject. Your policy engine evaluates identity, device and context, finds them all satisfied, and allows the request. Nothing is spoofed and nothing is bypassed - **the assertion is truthful**, and the enforcement is correct. The weakness is not in the decision, it is in who gets to create and keep the subject. You have effectively outsourced part of your identity lifecycle to an organisation whose process quality you did not choose. If their leaver process takes three weeks and yours takes two hours, your access removal time for those people is three weeks, whatever your own runbook says. If their contractor onboarding is a form and an email, that is your onboarding standard for those identities too. ## Bounding it without cutting it The naive answer is to sever the federation. It is also the answer that gets reversed by someone senior within a day, because the integration is what the acquisition was bought for. The workable moves keep the edge and shrink what crosses it: - **Refuse group-for-group equivalence.** Accept the far identity as an authenticated subject, then grant it explicitly on your side to the specific resources it needs. Group mapping is what silently imports their access model into yours; explicit grants make the surface countable. - **Time-box everything that crosses.** Cross-directory grants should expire and require renewal, so an identity nobody has thought about since the transition loses reach on its own. This is the only mechanism that survives an under-staffed review cycle. - **Require a claim you control for sensitive systems.** For your crown-jewel applications, demand a step-up or a device posture claim issued by enforcement you operate. In practice that means the person must be on a device your side manages, which is a deliberate barrier and a deliberate cost. - **Exclude a small set of systems entirely.** Some things - payroll, the source of truth for customer data, anything that can grant further access - should simply not be reachable from the far directory until the merge lands. - **Measure their deprovisioning latency.** Sample leavers from the acquired estate and time how long their access to your systems survives. That single number is the honest expression of the residual, and it is far more persuasive to a budget holder than an architecture diagram. ## The part that is not technical Every one of those moves is work someone must fund, and each creates friction for people who are already unhappy about being acquired. Explicit grants mean somebody enumerates them. Time-boxing means a renewal burden and, occasionally, a job that breaks overnight. Requiring your own device claim means issuing hardware or extending management to a fleet you did not budget for. The interim exposure - the gap between today and the merged directory - is real and someone senior has to accept it in writing, with a date and an owner attached to the consolidation. A candidate who lists the technical controls but never mentions the merge deadline has described half the answer; the trust edge is a temporary structure that becomes permanent unless someone owns removing it. ## What a strong answer sounds like Name the mechanism (the edge honours identities governed by another organisation's lifecycle), explain why per-request authorisation does not catch it (the assertion is genuine), give three or four bounding moves with their costs, and finish with the measurement that makes the case for the merge. Resist the urge to describe how an account is compromised in the first place - that is not what is being asked, and the interesting part is that it barely matters: the edge honours a real account however it ended up in the wrong hands.