Working paper
Sovereignty Without Fragmentation
How an Identity Fabric governs across autonomous organizations, countries, and institutions
Public release — Version 1.0
Sovereignty Without Fragmentation
How an Identity Fabric Governs Across Autonomous Organizations, Countries, and Institutions
EmpowerID — July 2026
Public release — Version 1.0
Centralize the governance model—not every identity.
Abstract
Some organizations are enterprises in the legal sense but federations in operational reality. A banking group may be accountable for common controls while its member institutions retain separate data, administrators, regulators, and operating models. An intergovernmental network may coordinate cross-border work without acquiring administrative control over each participant’s national identity systems. A multi-country industrial or defense group may require consolidated assurance while country operations remain subject to distinct legal, security, employment, and accreditation boundaries.
These organizations face a false architectural choice. One central identity tenant promises consistency but can erode sovereignty, create concentration risk, and force sensitive identity data across boundaries. Independent local systems preserve autonomy but fragment policy, evidence, lifecycle, and group-wide accountability. Custom aggregation can bridge the gap, but it often becomes a permanent integration program whose semantics and controls drift over time.
This paper proposes a third model: a federated Identity Fabric organized around autonomous trust domains and a shared governance plane.
Each domain retains authoritative identity data, local administration, credentials, enforcement, connected systems, and re-identification authority. The federation defines a common control vocabulary, policy and risk baselines, delegation rules, evidence obligations, and lifecycle for participation. Governance can flow down as versioned controls; minimized evidence can flow up; authorized queries can reach down without indiscriminate replication; and delegated authority can cross boundaries only under an explicit mandate.
The result is neither one tenant nor a collection of unrelated installations. It is one governance model operating across many accountable domains:
Local truth. Shared controls. Distributed enforcement. Evidenced federation.
This is also a practical modernization strategy. Institutions can preserve existing identity investments and adopt the fabric incrementally as a governance spine. Over the next 24 months, the same architecture can extend from workforce IGA to workloads, partner identities, AI agents, and long-running Missions—without requiring the federation to surrender local authority to a central runtime.
The narrow architectural claim is:
For participating domains and governed flows, common controls can be agreed or authored at federation level, enforced within the accountable local domain, and evidenced with explicit provenance—without requiring full central replication of the underlying identity estate.
That does not eliminate legal, semantic, or operational complexity. It gives federated organizations a coherent way to govern it.
Intellectual provenance, confidentiality, and scope
This paper is an EmpowerID synthesis built on established identity, federation, authorization, zero-trust, privacy, and distributed-systems principles.
KuppingerCole’s Identity Fabric work provides an important market foundation: identity capabilities should compose across heterogeneous environments rather than force every organization into a single monolithic control point. Open standards—including SAML, OpenID Connect, OAuth, SCIM, the OpenID AuthZEN Authorization API, and the Shared Signals Framework—provide parts of the interoperability substrate. NIST Zero Trust Architecture reinforces the principle that trust should not be inferred from network location or static possession alone and that policy decisions require enforceable control points.
The extension to agentic work is informed by KuppingerCole’s AIdentity framing and by Karl McGuinness’s public work on Mission-Bound Authorization: identity and tokens do not, by themselves, represent the durable purpose, authority ceiling, and lifecycle of long-running delegated work.
EmpowerID’s contribution is the composition presented here: the Federation Charter, the federated governance plane, the four governed flows, and the integration of local identity truth, shared policy, distributed enforcement, minimized evidence, reversible operations, and agentic authority on one Identity Fabric. These are EmpowerID formulations of the architecture; they do not imply that every underlying mechanism is novel or exclusive to EmpowerID.
For clarity, the principal intellectual provenance is summarized below. This is an attribution record, not a legal opinion about novelty or ownership.
| Idea or foundation used in this paper | Principal provenance credited here |
|---|---|
| Identity Fabric as a composable identity architecture | KuppingerCole and the broader identity-architecture community |
| Zero trust, resource-centric policy, and enforceable control points | NIST Zero Trust Architecture and the wider zero-trust community |
| Identity federation, delegated access, provisioning, authorization exchange, and shared security signals | SAML, OpenID, OAuth, SCIM, AuthZEN, SSF/CAEP, and their standards communities |
| Mission as durable, purpose-bound authority distinct from tokens and sessions | Karl McGuinness’s Mission-Bound Authorization body of work |
| Federation Charter, federated governance plane, four governed flows, and the EmpowerID composition described here | EmpowerID synthesis |
The scenarios in this paper are deliberately composite. They are derived from recurring architecture requirements across regulated financial groups, intergovernmental operational networks, multi-country industrial and defense organizations, acquisitive enterprises, and partner ecosystems. They do not identify a customer, confirm a commercial relationship, reproduce a specific deployment, or imply endorsement by any organization. Names, country combinations, internal systems, deployment dimensions, and distinctive program terminology have intentionally been omitted.
References to laws and regulatory frameworks describe architectural relevance, not legal conclusions. Applicability must be assessed by each organization’s legal, privacy, security, labor, supervisory, and contracting authorities.
Executive summary
Federated organizations are accountable across boundaries they cannot simply erase.
The center may be responsible for group risk, common control objectives, certification, emergency coordination, or consolidated reporting. The participating domains may still retain:
- separate legal accountability;
- independent administrators and operating teams;
- country- or institution-specific identity systems;
- local regulators, works councils, security accreditations, or secrecy obligations;
- distinct data-residency and disclosure rules;
- local credentials and connected applications;
- the authority to decide who may access their resources;
- the right—or obligation—to leave or change operating arrangements.
This is not the same problem as administering subsidiaries inside one corporate tenant. The unit of design is the autonomous trust domain: an institution, country operation, member organization, agency, partner, or regulated business unit with its own authoritative state and accountability boundary.
Three familiar architectures each solve only part of the problem:
| Architecture | What it optimizes | Structural cost |
|---|---|---|
| Central shared tenant | Uniform experience, central operation, consolidated data | Local sovereignty becomes configuration inside another party’s administrative domain; concentration and exit concerns increase |
| Independent local platforms | Autonomy, local control, data locality | Policy, identity semantics, certification, evidence, and lifecycle fragment across the federation |
| Custom aggregation layer | Central reporting over existing systems | The federation owns permanent integration glue, mapping drift, inconsistent control semantics, and uncertain completeness |
A federated Identity Fabric changes the unit of consistency. It does not require every identity record, credential, decision, or application to live centrally. It centralizes—or jointly governs—the control model:
- A Federation Charter defines mandatory, negotiable, and local authority.
- A shared control vocabulary makes policies and evidence comparable across domains.
- Local enforcement keeps decisions close to local identities, resources, credentials, and legal accountability.
- Minimized federation evidence supports oversight without assuming that all raw identity data should move upward.
- Governed delegation allows the center or another domain to act only through an explicit, scoped, time-bound mandate.
- Participation and exit are lifecycle states. Joining, suspension, transition, and departure are designed into the architecture.
The model can be expressed through four flows:
Governance flows down.
Evidence flows up.
Authorized questions reach down.
Delegated authority crosses boundaries under explicit mandate.The strategic result is governance without forced centralization.
Autonomy without assurance becomes fragmentation. Centralization without consent becomes overreach. A federation must preserve both control and legitimate boundaries.
1. The false choice: central control or local sovereignty
1.1 Why federations are different
A conventional enterprise hierarchy assumes that the parent organization can standardize systems, name authoritative administrators, and ultimately impose one operating model. That assumption may be commercially inconvenient, but it is usually legally and organizationally available.
A federation is different. The center’s authority is bounded.
The federation may arise from:
- a group of independently licensed or regulated institutions;
- a treaty, statute, consortium agreement, or shared operational mandate;
- a corporate group whose country entities face distinct security and legal constraints;
- acquisitions that retain local operating independence;
- a franchise, partner, or supply-chain network;
- a shared-service arrangement in which operation and legal accountability are separated.
The center may define common control outcomes while lacking unilateral authority over every local identity, entitlement, credential, application, or disclosure. A member may be required to meet the federation’s standard while remaining responsible for how the standard is implemented locally.
That distinction creates the architecture requirement:
Common accountability must be possible without pretending that every domain has become one organization.
1.2 Why one central tenant is not automatically the answer
A central tenant can simplify administration, but tenancy is not the same thing as governance.
Moving every identity and control into one administrative domain can create new questions:
- Which organization becomes the data controller or accountable operator for each use?
- Which administrators can see or act across domains?
- Can a shared control-plane compromise affect multiple members?
- Can a local institution enforce national, sectoral, or contractual restrictions independently?
- What happens when a member must suspend participation or change service provider?
- Can the organization demonstrate a tested exit without rebuilding its identity estate?
- Does the central platform preserve local legal authority, or merely simulate it with role scoping?
Multi-tenant SaaS, dedicated hosted environments, and centralized on-premises platforms can each be appropriate. The point is not that a particular deployment style is inherently noncompliant. The point is that federated organizations should choose centralization intentionally rather than treating it as the default definition of consistency.
1.3 Why disconnected local systems are also insufficient
Local systems preserve local control, but independence alone does not create federation.
Without a shared layer, each domain may develop different meanings for:
- identity type and lifecycle status;
- organization, role, capability, and entitlement;
- risk and segregation-of-duties policy;
- certification completion and exception;
- operator authority and emergency access;
- evidence, timestamp, outcome, and uncertainty;
- suspension, termination, and remediation.
A central warehouse can collect reports while still failing to establish that the reports mean the same thing. It may show what members sent without showing whether a member failed to send, whether a local policy was actually active, or whether a reported decision was enforced.
The missing ingredient is not another aggregation pipeline. It is a shared governance contract.
2. Three models of federation
Federated governance is not one authority pattern. Three models appear repeatedly, and a real organization may use all three for different control domains.
2.1 Hierarchical federation
The center has recognized authority to mandate baseline controls. Local domains retain operational and administrative autonomy within those boundaries.
Examples include a corporate group with country operations, a regulated group with common risk obligations, or a holding organization that defines mandatory security and certification policy.
| Property | Hierarchical federation |
|---|---|
| Baseline policy | Centrally mandated and versioned |
| Local override | Permitted only inside defined guardrails |
| Enforcement | Normally local |
| Evidence | Local production with federation-level reporting or verification |
| Emergency authority | Defined by group policy and local mandate |
The central risk is overreach: treating group authority as unlimited. The local risk is quiet nonconformance: retaining the appearance of federation while disabling common controls.
2.2 Cooperative federation
Members are sovereign peers or autonomous participants. Common controls exist because members ratify a shared charter, not because one member owns the others.
Examples include intergovernmental networks, sector consortia, joint programs, and some institutional alliances.
| Property | Cooperative federation |
|---|---|
| Baseline policy | Jointly agreed or adopted through federation governance |
| Local override | Determined by charter and member reservations |
| Enforcement | Local, under member accountability |
| Evidence | Shared according to agreed disclosure and assurance rules |
| Emergency authority | Activated only through a pre-agreed mechanism |
The federation must preserve consent and provenance. A central coordinator can validate membership or a shared Mission without becoming a universal administrator for every member domain.
2.3 Delegated federation
One domain permits another domain, the center, or an operating partner to act for a defined purpose and duration.
The delegation may cover:
- running a certification campaign;
- responding to a shared incident;
- administering a narrow service;
- resolving a cross-domain identity or entitlement exception;
- operating software while infrastructure and legal accountability remain local;
- executing a Mission involving resources from several domains.
Delegation is not ownership. The acting party should receive only the authority necessary for the defined operation, and the local domain should retain evidence of what occurred under its mandate.
2.4 Federation modes can coexist
A financial group may mandate a minimum risk policy, cooperate with members on data-sharing rules, and use delegated authority for emergency response. A multi-country industrial organization may impose global control objectives while local domains retain final authority over nationally restricted systems. A public-sector network may cooperate by default and activate narrow delegated authority for a jointly approved operation.
The architecture must therefore answer two questions for every control:
- Who has the authority to define or approve this rule?
- Which domain has the authority and capability to enforce it?
Those answers belong in the Federation Charter.
3. The Federation Charter
The Federation Charter is the durable governance object that defines how autonomous domains participate in one control system.
It may be backed by corporate policy, contract, statute, treaty, operating agreement, delegated mandate, or a combination. Its legal form varies. Its architectural function is consistent: translate the federation’s authority model into explicit, versioned, machine-governable rules.
3.1 What the charter defines
A complete charter addresses at least eight areas.
Authority
- Who may establish mandatory controls?
- Which policies require member ratification?
- Which controls are advisory, negotiable, or local?
- Who may approve exceptions, and for how long?
Semantics
- What common identities, relationships, capabilities, actions, resources, and outcomes mean.
- How local roles and entitlements map to the federation vocabulary.
- Which identifiers are authoritative and in which domain.
Data
- Which data may be copied upward, queried locally, or never leave the domain.
- Required minimization, pseudonymization, retention, and access controls.
- Who may re-identify a federated reference and under what authority.
Policy and enforcement
- Which baseline policies must be enforced locally.
- Which local extensions are permitted.
- How policy versions, effective dates, supersession, and emergency changes are handled.
Delegation and operations
- When another domain, central function, or delivery partner may act locally.
- Scope, duration, approval, credential, and evidence requirements.
- Separation between infrastructure hosting, software operation, policy authorship, and legal accountability.
Evidence and assurance
- What each domain must report or make queryable.
- How integrity, completeness, freshness, and uncertainty are represented.
- Which evidence is locally retained, centrally mirrored, or independently verifiable.
Lifecycle
- Admission, trust establishment, suspension, remediation, resumption, and termination.
- What happens to delegated authority, shared identifiers, policy, evidence, and outstanding work when a member leaves.
Change and dispute
- How the charter evolves.
- How members test new policy versions.
- How conflicts between federation policy and local law or authority are surfaced and resolved.
3.2 The charter is more than documentation
A PDF that describes governance is necessary but insufficient. The operative portions of the charter should be represented in versioned artifacts that systems can apply:
- signed policy and risk packs;
- approved schemas and mappings;
- trust and delegation profiles;
- data-sharing contracts;
- evidence requirements;
- member and service-placement records;
- exception and reservation records;
- lifecycle and exit states.
Human-readable policy and machine-enforced policy must share lineage. Otherwise, the federation will eventually operate under rules that no longer match what its governance bodies approved.
3.3 Local exceptions must remain visible
Federations require flexibility, but invisible local override destroys shared assurance.
A local domain may need to:
- apply a stricter national rule;
- defer a control until a system is upgraded;
- substitute an equivalent control;
- exclude a classified or legally restricted environment;
- impose additional approval or evidence requirements.
The charter should make those differences explicit and time-bounded. The center does not need every local detail, but it must be able to distinguish:
- conforming;
- conforming through an approved equivalent control;
- operating under a documented exception;
- not reporting;
- unknown.
Unknown is not compliant, and silence is not evidence.
4. The federated Identity Fabric
4.1 The autonomous trust domain
The local domain is the primary unit of deployment and accountability. It may be an institution, country operation, agency, subsidiary, partner, or protected environment.
Depending on the operating model, it can retain:
- authoritative identity and relationship data;
- local accounts, entitlements, and resource catalogs;
- local policy enforcement points and decision services;
- local connectors, workflows, and execution paths;
- local credentials, keys, and secrets;
- local administrators and approval authorities;
- local evidence, reconciliation, and re-identification capability.
Not every capability must be physically local. What matters is that logical ownership, authority, data boundaries, and operating accountability are explicit.
4.2 The federated governance plane
The shared plane contains what benefits from federation-wide consistency:
- federation membership and trust metadata;
- common identity, capability, action, and evidence vocabulary;
- versioned baseline policies and risk models;
- certification and campaign coordination;
- cross-domain segregation-of-duties rules;
- minimized correlation or resolution services;
- evidence indexes, checkpoints, and assurance status;
- consolidated risk and governance analytics;
- approved delegation and operator profiles.
It need not contain every identity record, entitlement, credential, or raw event.
4.3 The reference architecture
flowchart TB
subgraph FGP["Federated Governance Plane"]
CH["Federation Charter<br/>membership · authority · lifecycle"]
CV["Common vocabulary<br/>policy · risk · action · evidence"]
CO["Coordination<br/>campaigns · assurance · analytics"]
FR["Federation evidence index<br/>checkpoints · gaps · provenance"]
end
subgraph A["Autonomous Domain A"]
AT["Local identity and relationship truth"]
AP["Local decision and enforcement"]
AX["Local execution and credentials"]
AE["Local evidence and reconciliation"]
end
subgraph B["Autonomous Domain B"]
BT["Local identity and relationship truth"]
BP["Local decision and enforcement"]
BX["Local execution and credentials"]
BE["Local evidence and reconciliation"]
end
CH --> A
CH --> B
CV --> AP
CV --> BP
CO --> A
CO --> B
AE --> FR
BE --> FR
A <-->|"authorized query or delegated action"| BFigure 1 — The federated governance plane. Common authority and control semantics coordinate autonomous domains; local truth, enforcement, credentials, and evidence remain locally accountable.
4.4 Placement and operation are separate decisions
Four questions should be answered independently for each service:
- Who owns the authoritative data?
- Who defines or approves the policy?
- Where is the decision or action enforced?
- Who operates the technology?
A service may be hosted locally and operated by a central team. It may be hosted by a dedicated provider while keys and policy authority remain with the institution. Policy may be authored centrally and evaluated locally. Evidence may be written locally and selectively mirrored upward.
Separating these questions prevents a common mistake: assuming that “managed” means “centralized” or that “locally hosted” means “locally governed.”
4.5 Reversibility must be designed and tested
Single-tenancy, portable deployment artifacts, documented interfaces, data export, and customer-controlled keys can reduce exit friction. They do not make an operating model automatically reversible.
A credible exit plan also addresses:
- identity and configuration export;
- keys, secrets, and trust anchors;
- policy and mapping artifacts;
- evidence retention and verification;
- connector and network dependencies;
- monitoring, backup, recovery, and operational knowledge;
- open work, reconciliations, and delegated authority;
- transition assistance and contractual obligations;
- testing under realistic continuity requirements.
The architecture is therefore designed for portability and testable exit, not “zero lock-in” or “fully reversible.”
5. Four governed flows
5.1 Governance flows down
The federation distributes common control intent to participating domains as versioned, attributable artifacts.
Depending on the federation model, a control can be:
- mandatory under central authority;
- ratified by participating members;
- a minimum baseline that local domains may strengthen;
- a recommended profile;
- activated only for a shared Mission or emergency condition.
Local enforcement should report which version became effective, which approved variations apply, and whether the domain could apply the control successfully. Distribution alone is not enforcement.
5.2 Evidence flows up
The federation needs assurance without indiscriminate replication.
Upward evidence can include:
- policy-effective status and version;
- certification completion and exception state;
- control outcomes and risk findings;
- minimized capability or SoD projections;
- signed decision or execution records where appropriate;
- evidence checkpoints and sequence status;
- freshness, provenance, and uncertainty.
Evidence should reveal enough to establish the agreed control objective while respecting data minimization and disclosure boundaries.
5.3 Authorized questions reach down
Some questions cannot be answered safely or accurately from a central copy.
The federation can route an authorized query to the domain that owns the truth:
- Does this local subject still hold a particular capability?
- Has this certification item been completed?
- Does a local identity correspond to an approved federation reference?
- Is a local policy version currently effective?
- Did a specified governed action occur, fail, or remain uncertain?
The local domain evaluates the requester, purpose, scope, and disclosure policy before returning a minimized answer. Query-down preserves freshness and local control, but it requires availability, common semantics, and clear handling of unavailable or non-participating domains.
5.4 Delegated authority crosses boundaries under mandate
Cross-domain action is the most consequential flow.
A center, peer domain, or operating partner should not act locally merely because it belongs to the federation. It needs an authority chain defining:
- the accountable authority source;
- the approved purpose or Mission;
- the eligible operator, service, or agent;
- permitted actions and resource scope;
- duration, limits, and required approvals;
- credential and execution boundaries;
- evidence and notification requirements;
- revocation, suspension, and termination conditions.
Local enforcement remains decisive. The acting party may propose or request an action; the local domain controls whether that action becomes an effect on its resources.
This is where federated governance and Governed Execution meet.
6. Data minimization without semantic blindness
6.1 Local truth, federation references
A federation often needs to correlate risk or activity across domains without creating a universal central identity repository.
Useful patterns include:
- domain-issued opaque references;
- purpose-specific pseudonymous correlation identifiers;
- minimized capability projections;
- local re-identification after a finding;
- authorized query-down for sensitive detail;
- aggregated or thresholded reporting where individual detail is unnecessary.
The architecture must remain legally and technically honest. Under the GDPR, pseudonymized data remains personal data when additional information can reconnect it to an identifiable person. Pseudonymization reduces risk; it does not create automatic anonymity.
The correct claim is:
The federation minimizes and purpose-bounds shared data, while retaining local control over authoritative detail and re-identification where the operating model allows.
6.2 Copy-up and query-down are policy choices
Two complementary models should be selectable by data type and purpose.
| Model | Best suited for | Principal trade-off |
|---|---|---|
| Copy-up | Aggregated reporting, durable evidence, shared risk indicators, asynchronous assurance | Central retention increases disclosure, lifecycle, and consistency responsibilities |
| Query-down | Sensitive or fast-changing local state, restricted detail, locally controlled re-identification | Depends on local availability, federation semantics, and authorization at query time |
Most mature federations will use both. A central dashboard may retain an assurance state and evidence reference while retrieving sensitive detail only when an authorized investigation requires it.
6.3 Sovereignty is more than data residency
Keeping data in a country or institution is not, by itself, sovereignty.
The domain must also understand:
- who can administer the service;
- which policy can change its behavior;
- where credentials and keys are controlled;
- which telemetry and support data leave the boundary;
- who can suspend, export, or delete data;
- how software updates are authorized;
- whether another domain can trigger local effects;
- how the domain exits or changes operator.
Data location is one control. Sovereignty is the combined governance of authority, administration, disclosure, execution, and lifecycle.
6.4 Locality does not create compliance automatically
Single-tenancy, pseudonymization, local enforcement, and controlled egress can support privacy, secrecy, security, labor, and outsourcing objectives. They do not determine legal compliance on their own.
For example:
- pseudonymized employee data may still be personal data;
- works-council rights may apply even when central users see minimized data;
- banking secrecy may protect customer-relationship information rather than every employee identity record;
- defense, export-control, or national-security restrictions may depend on nationality, classification, program, or destination—not only hosting location;
- a tested exit plan requires technical, operational, and contractual preparation.
The fabric provides enforceable choices and evidence. The accountable organization determines which choices its obligations require.
7. Evidence: integrity is not completeness
7.1 Four assurance questions
Federated oversight must answer four different questions:
- Integrity: Is the evidence authentic and unchanged within the properties of the mechanism used?
- Custody and causality: Can the evidence connect policy, decision, execution, and observed outcome?
- Completeness: Can the federation detect a missing expected report or sequence rather than interpreting silence as conformance?
- Effective state: Can the domain attest which policy and configuration were actually active?
These properties should not be collapsed into the word proof.
7.2 What evidence can establish
| Evidence | Can support | Does not automatically prove |
|---|---|---|
| Signed local record | Producer, integrity, time, referenced facts within the signature’s trust model | Independent truth of every asserted fact |
| Policy decision record | What the decision point returned for the represented request | That the exact request was later enforced or dispatched |
| Execution record | What a governed executor attempted or dispatched | That the target committed the intended business state |
| Target acknowledgement | That the target received or responded to a request | Final outcome of asynchronous processing |
| Reconciliation observation | State observed at a later point | Every intermediate event or permanent correctness |
| Sequence checkpoint | Missing or reordered expected records within the checkpoint design | Completeness for events never required to enter that sequence |
| Configuration attestation | Measured state under the attestation scope | Absence of all local bypasses or undisclosed systems |
This aligns federated assurance with the effect discipline described in From Authority to Effect: authorization, dispatch, acknowledgement, and confirmed business outcome are distinct facts.
7.3 Silence must have a state
A federation-level campaign or control should distinguish:
- complete;
- complete with approved exception;
- in progress;
- failed;
- overdue;
- member suspended;
- domain unavailable;
- report missing;
- unknown.
“No violation received” is not the same as “control passed.”
Completeness mechanisms can use expected membership, monotonic sequences, signed checkpoints, deadlines, and reconciliation. Until those mechanisms are deployed and demonstrated across the participating fleet, the architecture should say designed to surface attributed gaps, not complete by construction.
7.4 Operator actions belong in the chain
Federations often separate hosting, operation, governance, and legal accountability. Central teams and delivery partners may possess significant technical access even when they do not own policy authority.
Operator activity should therefore be governed like any other consequential action:
- authenticated operator and workload identity;
- approved service and maintenance purpose;
- domain and resource scope;
- time-bound authority;
- separation of duties and approval where required;
- action and configuration evidence;
- local visibility and revocation.
The operator should not disappear behind the word managed.
8. Three composite scenarios
The following scenarios are composites. They illustrate recurring architecture patterns and do not identify actual organizations or deployments.
8.1 Federated financial group: the cross-entity mover
A manager moves from a member institution into the central organization while temporarily retaining an approval responsibility at the original institution.
The local and central roles are individually legitimate. Together they create a cross-entity segregation-of-duties concern.
A federated fabric can address the scenario as follows:
- The original institution and the center retain their own authoritative identity and entitlement data.
- A purpose-specific federation reference allows the risk process to recognize that the two local identities concern the same person, subject to the agreed data-sharing model.
- Each domain maps local entitlements to a common capability vocabulary—for example, payment initiation and payment approval—without necessarily exporting the complete entitlement catalog.
- The federation-level SoD model identifies the prohibited capability combination.
- The finding returns to the accountable local domain for re-identification, adjudication, and enforcement.
- Local decision and execution services remove or suspend the conflicting authority under the applicable policy.
- Minimized evidence reports the finding, decision, remediation state, and relevant policy version to group oversight.
The group obtains a coherent control outcome without treating every member’s identity estate as centrally owned.
8.2 Intergovernmental operational network: shared Mission, national authority
Several sovereign participants form a temporary operational team. Personnel and systems remain governed by their national domains. A coordinating body is accountable for the shared undertaking but is not a universal administrator for the participants.
The Federation Charter defines:
- which member-issued identities and qualifications are accepted;
- how a shared Mission is approved;
- what resource and action classes each member exposes;
- which facts may be shared centrally;
- when national approval remains mandatory;
- how emergency suspension and termination operate;
- what evidence is returned to the coordinating body and retained locally.
A participant assigned to the Mission receives only the federation authority required for that undertaking. When the Mission requests access to a national resource, the national domain resolves current authority and applies local policy. The coordinator can see whether the agreed operation is authorized, denied, pending, unavailable, or complete without receiving unrestricted administrative access to the national identity system.
If conditions change, a member can suspend its contribution or revoke delegated authority without pretending the entire federation has ceased to exist. The Mission lifecycle, local authority, and shared evidence remain connected but distinct.
This pattern is especially important where cooperation is required but central ownership would be legally or politically impossible.
8.3 Multi-country industrial and defense group: group assurance, country enforcement
A global organization operates country-specific identity governance environments because local entities face different security accreditation, employment, contracting, data, and program restrictions.
The group still needs to establish that:
- common joiner, mover, and leaver controls operate;
- privileged and sensitive capabilities are governed consistently;
- group-wide SoD and certification objectives are met;
- administrators and operating partners act under bounded authority;
- exceptions and local reservations are visible;
- acquisitions and new country operations can join progressively.
The federation defines common capability and control semantics. Country domains map local roles and systems to that vocabulary, enforce policy locally, and report minimized assurance evidence. A country may strengthen a control or withhold restricted detail while still reporting an attributable status under the charter.
The architecture avoids two bad outcomes: forcing every country into one global tenant regardless of local constraints, or accepting incomparable country reports that cannot support group accountability.
8.4 One pattern, different authority
The three scenarios use similar technology but different legitimacy models:
| Scenario | Source of federation authority | Local decision owner |
|---|---|---|
| Financial group | Group governance, regulatory structure, member arrangements | Institution and group according to control domain |
| Intergovernmental network | Joint charter, member consent, shared Mission | Sovereign member for national resources |
| Multi-country enterprise | Corporate authority bounded by local law and accreditation | Country or protected domain within group policy |
Architecture should preserve those differences rather than hiding them behind a generic “super-admin.”
9. Modernize without forcing re-platforming
9.1 Coexistence is a target architecture
Federated organizations often already have substantial identity investments. Replacing every local platform before establishing shared governance can take years and may be impossible for protected or independently accountable domains.
An Identity Fabric can begin as a governance spine around existing systems.
Three adoption modes support that progression:
| Mode | Existing experience | Fabric role |
|---|---|---|
| Spine-only | Local portals, IGA systems, service desks, and workflows remain | Common resolution, policy, federation, execution, or evidence services are adopted selectively |
| Hybrid | Existing and EmpowerID experiences coexist | Both converge on shared identity, policy, integration, and evidence primitives |
| Full fabric experience | EmpowerID provides the primary governance interfaces | The interfaces use the same services and contracts available to external systems |
The front door is not the architecture. The durable value is the common governance model underneath it.
9.2 A phased federation journey
Phase 1 — Define domains and authority
- Identify autonomous trust domains.
- Establish the Federation Charter and governance modes.
- Define mandatory, ratified, and local controls.
- Record data, disclosure, delegation, and exit boundaries.
Phase 2 — Create semantic interoperability
- Define common identity, capability, action, risk, and evidence vocabulary.
- Map selected local roles and entitlements.
- Establish authoritative identifiers and lifecycle states.
- Make unknown and exception states explicit.
Phase 3 — Connect and observe
- Connect local identity and entitlement sources.
- Produce minimized assurance views.
- Measure mapping quality, freshness, and coverage.
- Do not infer conformance from absent data.
Phase 4 — Coordinate governance
- Distribute versioned policies or ratified profiles.
- Coordinate certification and risk campaigns.
- Introduce approved local variations and exception lifecycle.
- Establish evidence integrity and operator visibility.
Phase 5 — Add completeness and delegated action
- Define expected reporting sequences and checkpoints.
- Surface attributed gaps.
- Introduce scoped cross-domain delegation and local enforcement.
- Test suspension, resumption, and exit.
Phase 6 — Extend to workloads and agents
- Register non-human actors and accountable owners.
- Bind long-running work to Missions.
- Apply shared signals and action-time policy.
- Require consequential effects to cross governed local execution boundaries.
9.3 Migration should move in rings
A practical rollout starts with a small number of representative domains:
- one mature self-operating domain;
- one thinly staffed managed domain;
- one domain with unusually strict data or policy constraints;
- the central or coordinating governance function.
The pilot should test semantics and authority, not only software installation. A platform can be technically connected while the federation remains ungovernable because members interpret roles, risk, completion, or delegation differently.
Expansion proceeds in waves after mappings, policy distribution, evidence, operating responsibility, and exit procedures are demonstrated.
10. From workforce federation to agentic federation
10.1 Agents amplify the federation problem
AI agents can operate across tools, organizations, clouds, and partner runtimes. Their cognition may occur in a platform the resource-owning domain does not control. Their work may continue after the initiating human disconnects, and their exact actions may be generated after the Mission begins.
This resembles the federation problem at machine speed:
- identity originates in one domain;
- purpose and accountability may originate in another;
- policy belongs to the resource-owning domain;
- execution occurs through a local connector or service;
- evidence must satisfy both local and federation oversight;
- authority can change while the work is running.
10.2 Foreign cognition, local authority
The strategic pattern is:
Reason where appropriate. Keep consequential authority and execution accountable to the resource-owning domain.
A remote or partner agent may propose an action. The local domain determines whether the agent identity, Mission, delegation, current signals, operation, target, and parameters are permitted. Reusable local credentials need not enter the remote runtime. Governed Execution controls the final transition into a local effect.
This allows federations to use external intelligence without treating an external runtime as a sovereign authority over enterprise systems.
10.3 Mission extends the Federation Charter into work
The Federation Charter defines the standing rules of participation. A Mission defines the bounded authority for a particular undertaking:
- accountable owner and authority source;
- participating domains and actors;
- purpose, resources, actions, and limits;
- delegation and child-agent rules;
- approvals, checkpoints, and evidence;
- suspension, expiry, and termination.
The Charter governs the federation. The Mission governs the journey. Governed Execution controls consequential steps.
10.4 Signals must change authority, not merely create alerts
Shared signals can communicate that an identity, credential, device, delegation, agent, or Mission has changed state. The receiving domain still decides what the signal means under local and federation policy.
The desired outcome is not simply a central alert. It is a change in effective authority before the next governed action reaches the resource.
This connects the architecture to the two preceding EmpowerID papers:
- Authority in Motion describes EmpowerID’s application of Agentic Identity Fabric principles and continuously current authority.
- From Authority to Effect defines Governed Execution at the consequential boundary.
- Sovereignty Without Fragmentation shows how those controls operate across autonomous domains without erasing local accountability.
11. The next 24 months: a practical agenda
The architecture is near-term, but not every property will mature at the same rate. The following agenda is directional and not a contractual product roadmap.
| Horizon | Architectural focus | Federation outcome |
|---|---|---|
| Foundation | Connect local identity estates; define domains and mappings; coordinate selected policy, risk, and certification; preserve local enforcement and evidence | Shared governance begins without forcing immediate platform replacement |
| 0–12 months | Formalize Federation Charter artifacts; improve versioned policy distribution; introduce minimized federation resolution; strengthen evidence provenance, operator governance, and attributed reporting gaps | Move from consolidated reporting to governed federation |
| 12–24 months | Expand cross-domain delegation, Mission lifecycle, shared signals, workload and agent federation, portable evidence profiles, governed local execution, and tested operator transition | Govern people and agents across platforms while retaining local authority over consequential effects |
Five areas require sustained attention.
11.1 Semantic interoperability
Protocols can transport identifiers and decisions. They cannot guarantee that two domains mean the same thing by approver, privileged, complete, revoked, or effect confirmed. Federations need governed vocabularies, mapping ownership, versioning, and tests.
11.2 Evidence portability
Evidence should become easier to verify across products and organizations without overstating what a signature proves. Common schemas for decision, dispatch, outcome, checkpoint, and uncertainty can reduce bespoke audit integration.
11.3 Continuous authority
Identity, entitlement, credential, risk, Mission, and business signals should be able to narrow or suspend authority across participating domains according to the charter—while preserving local decision rights.
11.4 Operator and supply-chain governance
Managed services, software supply chains, central operations, and support access need the same identity, delegation, policy, and evidence discipline as business users. “Vendor access” is not an authority model.
11.5 Federated agent governance
Agent discovery, ownership, Mission binding, delegated authority, action-time authorization, credential non-custody, and Governed Execution must become portable across runtimes without assuming universal trust in the agent platform.
12. Evaluating federated identity platforms
Buyers and governance bodies should ask questions that reveal whether a platform is truly federated or merely centrally hosted.
- What is the autonomous trust domain? Can the architecture represent separate legal, administrative, data, and enforcement accountability?
- What is centralized? Distinguish governance, policy authorship, identity data, credentials, execution, evidence, and operations.
- Who can mandate policy? Can the model represent hierarchical, cooperative, and delegated authority rather than assuming one universal administrator?
- How are common semantics governed? Who owns mappings, versions, exceptions, and the meaning of completion or risk?
- Where are decisions enforced? Can resource-owning domains retain the last decision and execution boundary?
- What data crosses the boundary? Is it raw, minimized, pseudonymized, aggregated, or queried on demand—and is its legal status described honestly?
- Can the federation detect silence? How does it distinguish a compliant member from a missing, unavailable, overdue, or unknown member?
- What does the evidence prove? Separate integrity, policy decision, dispatch, target acknowledgement, reconciliation, and completeness.
- How does another domain act locally? Require explicit, scoped, time-bound delegation and local evidence—not shared super-admin credentials.
- How are operators governed? Central IT, partners, and vendors should have attributable, bounded authority.
- Can local domains strengthen or vary controls? Are variations visible, versioned, approved, and time-bounded?
- Can existing IGA platforms coexist? Federation should not require every domain to re-platform before governance begins.
- What is the exit model? Test data, configuration, keys, policy, evidence, operations, and transition—not only a contractual export clause.
- How are workloads and agents included? The model should preserve accountable authority across non-human actors and external runtimes.
- What is available now? Require a deployment-specific statement distinguishing generally available, demonstrated, pilot, scoped delivery, and architectural direction.
The decisive demonstration is not a central dashboard showing imported records. It is a governed federation event:
Change a shared control. Show which domains accepted, varied, rejected, or failed to report it. Enforce it locally. Trace a resulting decision or action. Then demonstrate how the domain can suspend participation or change operator without losing its authoritative identity and evidence.
13. EmpowerID Identity Fabric
EmpowerID Identity Fabric is designed to provide a shared governance spine across people, non-human identities, AI agents, applications, entitlements, policies, delegations, connectors, execution, and evidence.
For federated organizations, the platform’s role is not to erase local boundaries. It is to make those boundaries governable together:
- local and federation-level identity and relationship context;
- common capability, policy, risk, and evidence semantics;
- fine-grained authorization and local enforcement;
- data collection and orchestration across heterogeneous systems;
- versioned governance and delegated authority;
- workforce, workload, partner, and agent lifecycle;
- evidence and operator visibility across governed paths;
- flexible self-operated, centrally operated, partner-managed, and dedicated-hosted patterns.
Specific feature availability and deployment topology depend on product version and solution scope. Federation-wide completeness, cross-domain correlation, portable evidence, and advanced agentic controls should be evaluated through a deployment-specific maturity and evidence profile.
The commercial promise is straightforward:
One governance model. Many autonomous domains. No forced choice between control and legitimate sovereignty.
14. Conclusion
Federated organizations cannot centralize away the boundaries that make them federations.
Member institutions, sovereign participants, country operations, protected business units, partners, and acquired companies may all need to retain authoritative identity data, local enforcement, administrative control, and accountability. The federation still needs common policy, coordinated lifecycle, cross-domain risk management, trusted delegation, and defensible assurance.
The answer is not one tenant by default, and it is not permanent fragmentation.
A federated Identity Fabric establishes a shared governance plane over autonomous trust domains. The Federation Charter defines authority and participation. Common semantics make controls comparable. Governance flows down. Evidence flows up. Authorized questions reach down. Delegated authority crosses boundaries under explicit mandate. Local domains retain the last accountable control over their identities, credentials, resources, and consequential effects.
This is modern IGA expressed at federation scale—and the foundation for governing workloads and AI agents across the same boundaries.
Governance can roll up. Sovereignty does not have to disappear.
About EmpowerID
EmpowerID provides an Identity Fabric for governing people, non-human identities, AI agents, access, delegated authority, enterprise integration, and consequential execution. The platform brings identity governance, fine-grained authorization, orchestration, signals, and evidence into a shared control plane designed to coexist with existing enterprise systems.
To discuss the architecture or request a federated-governance workshop, visit www.empowerid.com.
References and further reading
EmpowerID companion papers
- EmpowerID, Authority in Motion: An EmpowerID Identity Fabric Perspective on People, AI Agents, and Governed Work, July 2026.
- EmpowerID, From Authority to Effect: Why AI Agents Need Governed Execution—not Just Authentication, Policy, or Tool Gateways, July 2026.
Intellectual foundations and standards
- KuppingerCole, Identity Fabric Reference Architecture.
- KuppingerCole, AIdentity — The Crucial Link Between AI and Identity.
- Karl McGuinness, Mission Handbook.
- NIST, SP 800-207: Zero Trust Architecture, August 2020.
- OpenID Foundation, Authorization API 1.0 Final Specification, AuthZEN Working Group, January 2026.
- OpenID Foundation, OpenID Shared Signals Framework 1.0 Final Specification, September 2025.
- OpenID Foundation, OpenID Continuous Access Evaluation Profile 1.0 Final Specification, September 2025.
- IETF, RFC 8693: OAuth 2.0 Token Exchange, January 2020.
- IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, January 2025.
- IETF, RFC 7644: System for Cross-domain Identity Management — Protocol, September 2015.
Regulatory orientation
- European Union, Regulation (EU) 2016/679 — General Data Protection Regulation, including the treatment of pseudonymized personal data.
- European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act, including ICT third-party risk and exit planning.
- European Banking Authority, Guidelines on Outsourcing Arrangements, EBA/GL/2019/02.
Publication and claims notice
This paper describes a reference architecture and product direction. Feature availability, deployment scope, assurance properties, and standards conformance vary by product version and implementation. The 24-month agenda is directional and is not a contractual commitment. References to standards indicate architectural alignment or intended interoperability and do not imply certification unless explicitly stated in a current EmpowerID conformance claim.
The composite scenarios do not identify or describe a specific customer. Regulatory references are for architectural orientation and are not legal advice. Third-party names and marks belong to their respective owners.
© 2026 EmpowerID. All rights reserved.
