Federation is the ability to share situational awareness data between separate TAK server instances — each maintaining independent control of their own users, groups, and security policies. It is the mechanism that enables multi-agency operations, coalition partnerships, and cross-organizational collaboration without requiring everyone to be on the same server or the same network.
For organizations running TAK at scale, federation is often the most operationally important capability after basic blue force tracking. It determines whether your tactical picture stops at your organizational boundary or extends to every partner, agency, and unit in the fight.
What Is TAK Federation?
At its core, TAK federation is a server-to-server connection that allows two TAK servers to exchange Cursor on Target (CoT) data. When two servers are federated, users on Server A can see positions, markers, chat messages, and other CoT events from users on Server B — and vice versa — according to rules defined by each server's administrators.
The key distinction between federation and simply putting everyone on the same server is data sovereignty. Each organization retains:
- Independent user management: Each org controls who has access, what roles they hold, and how they authenticate
- Separate security policies: Each org enforces its own encryption, MFA, audit, and compliance requirements
- Selective data sharing: Administrators choose exactly which TAK groups and data types are shared through the federation
- Unilateral termination: Either party can disconnect the federation at any time without affecting the other's internal operations
Types of Federation
Sit(x) to Sit(x) Federation
The simplest federation scenario: two organizations both running Sit(x) establish a federation link through the web admin dashboard. Because both sides use the same platform, the connection process is streamlined and fully managed through the UI.
- Federation requests are initiated and approved through the Sit(x) web dashboard
- Administrators on each side select which TAK groups to share
- Policy controls including time bounds can be applied to limit the federation window
- All federation activity is logged in the audit trail
- No manual certificate exchange or configuration file editing required
Sit(x) to GOTS TAK Server Federation
Many organizations need to federate with partners who run the Government Off-The-Shelf (GOTS) TAK Server — the free, self-hosted TAK server distributed by the TAK Product Center. Sit(x) supports direct federation with GOTS TAK Server instances using the TAK federation protocol (Federation v2 over TLS).
This is a critical capability for organizations that have adopted Sit(x) as their managed platform but need to collaborate with DoD units, other agencies, or partners that operate their own GOTS TAK Server infrastructure. The federation bridge handles protocol translation between the two platforms, ensuring seamless CoT data exchange.
What this means in practice:
- Bidirectional CoT data flow: Position reports, markers, chat messages, and other CoT events pass between Sit(x) and GOTS TAK Server in both directions
- TLS-secured connections: All federation traffic is encrypted using mutual TLS authentication between servers
- Protocol compatibility: Sit(x) speaks the GOTS TAK Server federation protocol natively — no third-party middleware or manual conversion required
- Group-level control: Administrators define which TAK groups are exposed to the federation, keeping internal groups private
- No changes required on the GOTS side: The GOTS TAK Server administrator configures the federation as they would with any other TAK server — Sit(x) appears as a standard federation peer
Multi-Server Federation (Hub and Spoke)
For large-scale operations involving multiple organizations, Sit(x) supports hub-and-spoke federation topologies. A central Sit(x) instance can maintain simultaneous federation links with multiple partner servers — whether those partners run Sit(x) or GOTS TAK Server — creating a unified operational picture without requiring every pair of organizations to establish direct connections.
Federation Use Cases
Multi-Agency Event Security
During major events like the Super Bowl, multiple law enforcement agencies need a shared operational picture. Federation allows each agency to maintain its own TAK server and internal data while selectively sharing positions and tactical updates with the joint operations center. When the event ends, federation links are deactivated and each agency returns to independent operations.
Mutual Aid Response
When a natural disaster or critical incident requires mutual aid from neighboring jurisdictions, federation enables rapid collaboration. Rather than creating accounts on a shared server — which requires time, trust agreements, and security review — agencies can federate their existing TAK deployments and begin sharing data in minutes.
Military-Civilian Coordination
DoD units running GOTS TAK Server frequently need to coordinate with civilian agencies running Sit(x) during domestic operations, training exercises, or disaster response. Sit(x)'s GOTS federation capability bridges this gap without requiring either side to change their platform or compromise their security posture.
Contractor-Government Operations
Defense contractors and security firms working alongside government agencies can federate their Sit(x) instance with the government's TAK infrastructure. The government retains full control of its own data, while contractors gain the operational picture they need to perform their mission — with clear audit trails showing exactly what data was shared.
Coalition and Partner Nation Operations
International operations require data sharing across national boundaries with varying security requirements. Federation provides the control layer that makes this possible: each nation operates its own TAK environment, and federation policies define precisely what data flows across the boundary.
Federation Policy Controls
Effective federation requires more than just a network connection — it requires policy controls that let administrators define exactly what is shared, with whom, and for how long. Sit(x) provides several layers of control:
| Control | Description | Why It Matters |
|---|---|---|
| Group selection | Choose specific TAK groups to share through the federation | Keeps internal groups, training data, and sensitive operations private |
| Time bounds | Set start and end times for the federation window | Ensures event-based federations automatically expire without manual intervention |
| Direction control | Configure one-way or bidirectional data flow | Allows read-only partnerships where one side observes but doesn't transmit |
| Approval workflow | Federation requests require explicit admin approval on both sides | No organization can be federated without their administrator's consent |
| Audit logging | All federation events — connections, data transfers, disconnections — are logged | Supports compliance requirements and post-operation review |
| Instant termination | Either administrator can disconnect the federation immediately | Provides an emergency kill switch if a security concern arises |
Federation vs. Shared Server: When to Use Which
Not every multi-organization scenario requires federation. Here's how to think about the decision:
| Scenario | Recommendation | Rationale |
|---|---|---|
| Permanent team, single org | Shared server | No need for data separation — one org, one server, simplest approach |
| Multiple divisions, same parent org | Single Sit(x) with multi-org | Sit(x) supports isolated organizations on the same platform with separate admin controls |
| Two agencies, recurring joint operations | Federation | Each agency needs independent control but regular collaboration |
| Event-based multi-agency coordination | Time-bound federation | Collaboration is temporary — auto-expiring federation prevents stale connections |
| DoD unit coordinating with civilian agency | GOTS TAK Server federation | Different security domains and platforms — federation bridges the gap |
| International coalition | Federation with restricted groups | Maximum data sovereignty with selective sharing at the group level |
How Sit(x) Federation Works Under the Hood
For organizations evaluating TAK platforms, understanding the technical architecture helps assess interoperability and reliability:
- Connection establishment: Federation links are established over TLS with mutual certificate authentication between servers. This ensures both endpoints are verified before any data flows.
- Protocol negotiation: Sit(x) supports the TAK Federation v2 protocol, which uses Protocol Buffers (protobuf) for efficient, structured data serialization. This is the same protocol used by GOTS TAK Server, ensuring native compatibility.
- Data routing: Once connected, CoT events from shared groups are routed to the federated partner. Events from non-shared groups are never transmitted — the filtering happens at the server level before data leaves your environment.
- Resilient connections: Federation links include automatic reconnection logic. If a network disruption occurs, the servers automatically re-establish the connection when connectivity is restored.
- Event translation: When federating between Sit(x) and GOTS TAK Server, the federation gateway translates between internal representations and the standard CoT/protobuf format, ensuring lossless data exchange.
Getting Started with Federation
Sit(x) to Sit(x)
- Navigate to the Federations section in the Sit(x) web admin dashboard
- Create a new federation request specifying the partner organization's Sit(x) instance
- Select the TAK groups you want to share and set any time bounds
- The partner organization's administrator receives the request and approves it, selecting their own groups to share
- Data begins flowing immediately upon mutual approval
Sit(x) to GOTS TAK Server
- Coordinate with the GOTS TAK Server administrator to exchange TLS certificates for mutual authentication
- Configure the federation connection in the Sit(x) admin dashboard with the GOTS server's address and port
- The GOTS TAK Server administrator configures the corresponding federation entry on their side
- Once both sides are configured, the TLS connection is established and CoT data begins flowing according to group policies
- Monitor the federation status and data flow through the Sit(x) dashboard
Frequently Asked Questions
Can Sit(x) federate with GOTS TAK Server?
Yes. Sit(x) supports direct federation with GOTS TAK Server using the standard TAK Federation v2 protocol over TLS. The GOTS TAK Server treats Sit(x) as a standard federation peer — no special configuration is needed on the GOTS side beyond normal federation setup.
Does federation require both organizations to be on the same platform?
No. Sit(x) can federate with other Sit(x) instances and with GOTS TAK Server instances. The TAK federation protocol is a standard that enables interoperability across different TAK server implementations.
What data types are shared through federation?
Federation shares Cursor on Target (CoT) data, which includes position reports (blue force tracking), map markers, chat messages, and other CoT events. Data sharing is filtered at the group level — only events from groups explicitly selected for federation are transmitted to the partner.
Can I federate with multiple organizations simultaneously?
Yes. Sit(x) supports simultaneous federation links with multiple partners. Each federation connection has independent group selections and policy controls, so you can share different data with different partners.
What happens if the network connection drops during an active federation?
Federation links include automatic reconnection logic. When connectivity is restored, the servers re-establish the TLS connection and resume data exchange. Events that occurred during the disconnection on either side are not retroactively synced — federation is a real-time data flow, not a data replication mechanism.
Is federated data stored on both servers?
CoT events received through federation are treated like any other CoT event on the receiving server — they are processed and distributed to users in the appropriate groups. Each server's data retention and storage policies apply independently to their own data, including data received through federation.
Can I set up a read-only federation?
Yes. Federation direction controls allow you to configure one-way data flow. This is useful for scenarios where one organization needs to observe another's operational picture without sharing their own data — for example, a headquarters monitoring field operations.