Which external callers cannot be moved onto a cloud platform's outside-issuer federation, and what do you do for them instead?

## What federation requires to be possible at all It is easy to write a target like "no stored platform credentials anywhere" and much harder to say which callers that sentence actually covers. External identity trust needs three conditions to hold simultaneously: 1. **Something signs for the caller.** There must be an issuer that will produce an assertion this caller can present. Federation registers trust in an issuer; with no issuer there is nothing to point a registration at. 2. **The exchange can happen when the caller needs to act.** The caller must be able to reach its issuer for a signature and reach the platform to trade it for a credential, at that moment. 3. **You are willing to register that issuer.** A registration says anything this issuer signs, matching this condition, becomes this identity here. If you would not sign off on that sentence, the mechanism working is beside the point. Each failing condition names a class of caller. ## The three classes that cannot move **No verifiable issuer.** A purchased appliance, a legacy system, an embedded device, a hand-run script on an operator's machine: these present a fixed value because that is all they can present. Nothing produces an assertion on their behalf, so there is nothing to register. This is the largest class in most estates and the one people forget when they promise a number. **No reachability at the moment of the call.** A batch that runs disconnected, a process in an isolated network segment, a bootstrap step that runs before any identity infrastructure is up. Federation is a *runtime* exchange, and a credential obtained well ahead of time is short-lived by design, so pre-fetching does not rescue the case. The limitation here is timing and topology, not cryptography. **An issuer you do not operate.** A partner's system can federate perfectly well — the obstacle is that accepting their issuer makes their identity administration part of your access decision. Mechanically fine, organisationally a decision, and it should be taken deliberately rather than because it was easy to configure. | Class | What is missing | Usual first move | |---|---|---| | Appliance, legacy system, hand-run script | An issuer to register | Put a component you operate in front of it | | Disconnected or air-gapped run | The exchange at run time | Invert the direction, or split connected and offline phases | | Partner-operated system | Your willingness to register their issuer | Treat it as a delegation decision, not a configuration | ## The move that solves most of them: a boundary you operate The pattern worth reaching for is not a better place to store the leftover credential. It is to stop letting the unfederatable caller talk to the platform at all. Put a small component you operate between them: the caller authenticates to it however it can, and that component — which does have a verifiable identity — federates onward for the work it is allowed to do. This buys three things: - The credential problem collapses to one hop you control rather than one per caller. - The narrow grant lives on your component, so the appliance's access is defined by what your component will do on its behalf, not by what the platform identity can reach. - Removing access is a change in one place. It costs you a component to run and a new availability dependency, which is why it is worth it for a broad grant and usually not for a trivially narrow one. For the disconnected case the equivalent move is to change direction: have a connected component fetch or push on the offline job's behalf, or split the run into a connected phase that moves data and an offline phase that computes. If neither is possible, the job keeps a stored credential and that is a legitimate, reasoned outcome. ## The honest target Eliminating stored credentials is the wrong goal statement because it is usually achieved by stopping the count. A defensible target looks like: - Every machine caller that *can* federate does, and that is the default for anything newly built. - The remainder is inventoried, each entry with a named owner, the narrowest grant that works, and a written reason it cannot federate. - Each reason is re-examined when the caller changes, because "the appliance cannot" often becomes "the appliance was replaced and nobody revisited it". An interviewer asking this is checking whether you can distinguish a mechanism's limits from its marketing. The candidate who says every caller can federate has not run the migration; the one who names the three classes, proposes the front-door component, and admits to an inventory of exceptions has.