SOV 9. How do you federate identity without importing a dependency you did not intend?

Identity sits above everything else in this pillar. Whoever operates the identity provider decides who can authenticate, and therefore who reaches the data that the rest of these questions carefully placed and encrypted.

Federation is the right architecture and the standard practice: one directory, one lifecycle, one place to disable an account. The question is not whether to federate but what the resulting chain looks like, and whether anybody has looked at it.

Best practices

• SOV 9.1 Establish who operates your identity control plane
• SOV 9.2 Keep identity inside the boundary where the tier requires it
• SOV 9.3 Design the recovery path, which depends on identity
• SOV 9.4 Include workload identity, not only human identity

---

SOV 9.1 Establish who operates your identity control plane

Risk if not established: High

Trace the authentication chain from the person to the data and note who operates each link. For most organizations the chain runs from a corporate directory through a federation to the platform’s identity service, and each link is a party in the sense SOV 6 means.

The consequential link is usually the upstream directory rather than the platform. If that directory is operated by a provider outside the intended boundary, then the authority deciding who may authenticate sits there, regardless of where the workload runs.

This is not automatically a problem. Federating to an existing corporate directory is normal and avoids a second identity estate, which has its own risks. It is a dependency to name rather than a defect to remove.

Include what the upstream can do beyond authentication. An identity provider that can create accounts, alter group membership or reset credentials can grant access as well as verify it, and the chain is as strong as the weakest authority in it.

On STACKIT. STACKIT IdP is the platform identity service, and it supports federation to an upstream provider through generic OIDC and SAML 2.0 , with SCIM for provisioning.

Those two protocols are the important part for this question. Because the federation is expressed through open standards rather than a fixed list of providers, the upstream can be any conforming identity provider, including one you operate yourself or one within your intended boundary. The documented guides for Microsoft Entra ID and Google Workspace are conveniences for the common cases rather than the boundary of what is possible.

That distinction is what makes this a genuine architectural choice. Federating to a widely used corporate directory is a legitimate decision with a dependency attached; the standards-based path means the decision is available to be made differently where the tier requires it.

Tradeoffs. Operational Excellence. A separate identity estate for sovereign workloads means two directories, two lifecycles and two places to disable an account, which is a real risk of its own.

Verify. Draw your authentication chain from person to data. Who operates each link, and under which jurisdiction?

---

SOV 9.2 Keep identity inside the boundary where the tier requires it

Risk if not established: Medium

Where the tier makes the upstream dependency unacceptable, the alternatives are ordered by how much they cost rather than by how sovereign they are.

Federate to a provider inside the boundary, which keeps the federation architecture and changes the upstream. This is the cheapest option where such a directory exists or can exist.

Use the platform’s identity service directly for the sovereign workload, which removes the upstream entirely and creates a second identity estate to operate.

Operate your own identity provider inside the boundary, which gives full control and full operational burden including its availability, its patching and its own disaster recovery.

Scope the decision to the workload rather than the organization. A Tier 1 workload can have its own identity arrangement while everything else federates normally, which is SOV 1.3 applied to identity, and it confines the cost to where the requirement is.

On STACKIT. All three are available because the federation is standards-based. STACKIT IdP can be the upstream itself rather than a downstream, which is the middle option and the one that removes the external dependency without adding an identity provider to operate.

Whichever is chosen, the access model on the platform side is the same one SEC 5 describes, and the sovereignty decision here is about the authentication source rather than about authorization.

Tradeoffs. Operational Excellence and Reliability, substantially. Separate identity estates fragment the account lifecycle, which is where offboarding failures come from. Self-operated identity providers are critical infrastructure with the availability requirements to match.

Verify. For your Tier 1 workload, which directory authenticates its users? Was that a decision or the organizational default?

---

SOV 9.3 Design the recovery path, which depends on identity

Risk if not established: High

Identity is the dependency that turns other outages into unrecoverable ones. If authenticating requires a system that is unavailable, nobody can log in to fix anything, including the identity system.

The circular case is the one to design for: the federation is down, so administrators cannot authenticate, so nobody can reconfigure the federation. A break-glass path that does not depend on the federation is what breaks the circle, and it has to be created before it is needed.

That path is a deliberate exception with the properties SEC 5.3 and SOV 5.3 describe: strong credentials held securely, use that is conspicuous rather than merely logged, and periodic testing so that it works when it is needed.

Test it on a cadence. A break-glass credential that has expired, that nobody can locate, or that grants insufficient access is discovered during the incident it exists for.

Include the sovereignty question in the recovery path itself. An emergency path that routes through a provider outside the boundary is a boundary crossing at the worst moment, and it is the kind of exception that assessments find.

On STACKIT. Where federation is configured, the platform-native path is the fallback that does not depend on the upstream, and knowing whether that path exists and who holds it is the thing to establish rather than to assume.

The wider dependency question is REL 5: an identity provider is a dependency whose failure mode is total, and it deserves the same treatment as any other critical dependency rather than being assumed available.

Tradeoffs. Security. A break-glass path is a standing privileged credential, which is a risk in itself. It is a smaller risk than being unable to recover, and it is why the compensating controls matter.

Verify. If your identity provider were unavailable, who could still authenticate to fix it? When was that last tested?

---

SOV 9.4 Include workload identity, not only human identity

Risk if not established: Medium

Most access to data is made by workloads rather than by people, and workload identity is frequently outside the identity architecture entirely.

A service authenticating with a long-lived credential in a configuration file is an identity with no lifecycle, no expiry and no review. It survives the departure of the person who created it and it appears in no access review, which makes it the most durable form of access in the estate.

The improvement is short-lived credentials issued to a verified workload identity rather than static secrets distributed to it. That removes the credential from configuration, gives it an expiry, and makes the identity revocable.

Include workload identities in access review. They accumulate faster than human ones and they are never offboarded, which is SEC 5.4 and the reason unused ones persist for years.

The sovereignty relevance is the same as for human identity: whoever issues and validates the workload’s credential decides which workloads may act, and that authority is part of the chain in SOV 6.1.

On STACKIT. Service accounts are the platform mechanism for non-human identity, with documented authentication flows and key management .

Service account federation is the more interesting mechanism for this question, because it allows a workload to authenticate using an identity it already has rather than a distributed key. Where that applies, it removes the long-lived credential from the design entirely, which is the outcome this practice is after.

Tradeoffs. Operational Excellence. Short-lived credentials require the workload to handle renewal and to fail correctly when it cannot, which is application design rather than configuration.

Verify. How many long-lived credentials does your workload hold? For each, when was it created, who created it, and when does it expire?

---

Related

• SEC 4 Identity, which this supplies the authentication source for
• SOV 5.1 Access enumeration, which identity decides the membership of
• SOV 6 Jurisdictional chain, which the identity provider belongs to
• SEC 9 Secrets, which workload credentials are
• REL 5 Resilient interactions, which an identity provider is a critical dependency for