# Securing Apollo Federation Subgraphs: Context and Best Practices

**URL:** <https://community.apollographql.com/t/securing-apollo-federation-subgraphs-context-and-best-practices/9646>\
**Category:** API Design, Strategy & Governance\
**Tags:** federation\
**Created:** [January 14, 2026, 8:27pm UTC](https://community.apollographql.com/t/securing-apollo-federation-subgraphs-context-and-best-practices/9646 "2026-01-14T20:27:21Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![DavidWalter](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/davidwalter/32/5573_2.png) [@DavidWalter](https://community.apollographql.com/u/DavidWalter)\
**Post date:** [January 14, 2026, 8:27pm UTC](https://community.apollographql.com/t/securing-apollo-federation-subgraphs-context-and-best-practices/9646/1 "2026-01-14T20:27:21Z")

</div>

A reminder for teams running Apollo Federation: your subgraphs should only be accessible through the router.

This architectural boundary is what enables centralized auth, demand control, and operation safelisting. Without it, those protections don’t apply.

Key security practices for Federation deployments:

- Keep subgraphs internal
- Authentication and authorization at the router
- Demand control and persisted queries
- Observability and monitoring

[Review the best practices here](https://www.apollographql.com/blog/securing-apollo-federation-subgraphs-context-and-best-practices).