TAK Server Federation: How to Connect Servers Without Losing Control
You built a TAK server. Your neighbor built one too. Connecting them is the easy part. Deciding what crosses the wire, and living with what happens after, is the whole job.
Charles Laird runs North Carolina's First Responder Emerging Technologies Program. Mike Tigan spent 15 years at the FBI, including 11 as program manager for their ATAK system with 21,000 users, and now leads TAK operations at RTX BBN Technologies. Together they walk through TAK Server federation end to end: exchanging certificate authorities, setting hop counts, mapping groups in both directions, and then the harder conversation about who you trust and what you are accepting responsibility for when you turn the connection on.
The second half is a live FedHub walkthrough, including the certificate you must never delete, why the entire policy graph ships as one JSON file on every change, and why you should download a backup before you touch anything. Real lessons from Hurricane Helene, national security special events, and federating with federal partners run throughout.
What we cover
Interoperability by the dictionary definition: two systems talking in both directions, with each side keeping control of its own
Permissions first: the write-only, read-only, and read-write columns in the TAK Server admin view, and why groups are where federation actually starts
Exchanging ca.pem files to establish mutual trust, and uploading the other side as a federate certificate authority
Hop counts as time to live: what -1, 1, 2, 3, and 4 actually mean, and why the setting moved from global to per certificate authority
Why you should generate a separate federation certificate instead of reusing your main server cert
Creating the outgoing connection: endpoint, port 9001, the handshake, and why a live federation still moves zero data until you map groups
Federated group mapping as a filter, and the Hurricane Helene lesson of funneling every inbound group into one group and inheriting ADS-B feeds and unrelated deputies with no way to shut them off
The cyber argument: once data crosses your security boundary it is not your data, and the system owner writes the incident report
Interconnection security agreements, MOUs, and MOAs before long-term federations, plus EO 14028, NIST, and FISMA High for federal connections
Why you build federations ahead of time and leave them disabled, then treat turning one on like a comms check
The comms planning parallel: nobody puts every responder on one radio channel, and everyone seeing everything is not a plan for a large crisis response
Helene: TAK Server as the only application where state and local public safety connected directly with DoD units in the field, and sending road closure and drivability data even when the other side could not share location
FedHub as a one-to-many central node: filtering and rewriting traffic, port 9102, and keeping connections warm with no data flowing as a heartbeat
The FedHub gotcha that drops all your communication: deleting your own certificate, which hangs until reboot
Choosing allow groups over allow all messages, why disallowed groups gets confusing, and why anon will not work with V2 federation
No API, a full JSON policy graph pushed on every change that can exceed a megabyte, and why you download a backup constantly
Federating with federal partners: the written request process, no shared users, device policy requirements, and a US Capitol Police perspective from the floor
Just-in-time onboarding: making a widely distributed QR code write-only so volunteers can contribute without seeing responder locations
Reading the federation counters, and why stalled data is almost always a group name spelling or spacing mismatch
Feedback loops: why they should not happen between TAK Servers, why they do happen with non-TAK servers and mesh radios, and the FBI's TAK Server only policy