The MCP 12-Month Deprecation Window, formalized as SEP-2577 in the protocol’s 2026-07-28 specification release, sets a 12-month minimum between deprecation and earliest possible removal — and three long-standing capabilities were marked deprecated on release day.
Quick take
SEP-2577 guarantees a 12-month minimum between deprecation and earliest possible removal, starting from the 2026-07-28 release.
Roots, Sampling, and Logging are already deprecated and will keep working for the next year, per the specification.
The stateless architecture change removes the
Mcp-Session-Idheader, so servers relying on session identifiers need code changes regardless of the deprecation clock.Security responsibility shifts from the protocol to the implementer, so a 12-month SDK migration clock does not by itself cover a separate security-review backlog.
Roots, Sampling, and Logging are deprecated in favor of tool parameters, direct LLM provider APIs, and OpenTelemetry respectively, and the specification states these methods will continue working for the next year.
What the 2026-07-28 Release Actually Changed
Governance sits with the Agentic AI Foundation, a Linux Foundation body that took stewardship of MCP in December 2025 to keep the specification vendor neutral.
The release eliminates the initialize/initialized handshake and the Mcp-Session-Id header, moving MCP from a stateful, sticky-routing model to a fully stateless one that can run behind standard load balancers on existing Kubernetes tooling.
Adoption is already broad enough that the migration matters: more than 10,000 active public MCP servers and over 97 million monthly SDK downloads run across Python and TypeScript, and the Stacklok State of MCP in Software 2026 report found 41 percent of surveyed software organizations already running MCP in limited or broad production.
Caitie McCaffrey, a Microsoft software engineer and core MCP maintainer, explained why the old model didn’t scale.
Historically, running MCP at scale required sticky routing or shared state to maintain continuity across sessions. This made large-scale production deployments complex to implement and operate even when the capabilities being exposed were stateless.
Why the MCP 12-Month Deprecation Window Might Not Match Your Process
SEP-2577 requires new capabilities to ship as opt-in extensions first, which gives implementers a grace period before a change becomes mandatory — but that clock covers the protocol spec, not how long an enterprise’s own SDK-upgrade and security-review cycle actually takes.
Building a production MCP server with OAuth 2.1 authorization, multi-tenancy, rate limiting, and audit logging typically takes four to ten weeks according to one implementation guide, and that build time competes directly against the same 12-month window an enterprise also needs for migrating off deprecated capabilities.
The stateless architecture shifts security responsibility toward the developer: Akamai’s security research team flagged three concrete cross-tenant threats tied to predictable tracking identifiers, including hijacking another user’s active workflow.
Backslash Security separately identified a handle-hijacking attack class, in which a portable handle visible to the model and passed through conversations can be replayed against the server by anyone who obtains the string.
Glama.ai’s research points to the sharpest trap for a security-review team: authentication at the identity-provider layer does not automatically translate to authorization at the tool layer.
Watch out
Passing an identity-provider authentication check does not mean a tool call is authorized — that gap is invisible to traditional network-based security gateways because it happens inside the LLM conversation itself.
SEP 2468 addresses one related gap by requiring validation of an issuer (iss) parameter in authorization responses, which defends against OAuth Mixup Attacks where a compromised MCP server could obtain a token issued for a different provider.
Microsoft’s own guidance to Agent Framework developers tells enterprises to carefully review and track every MCP server they add, prefer servers hosted by trusted providers over proxies, and log data shared with remote servers for auditing purposes.
Deprecated Capabilities and Their Replacements
Three capabilities move out under the new policy, and each replacement changes what a security review actually has to test next.
| Deprecated capability | Replacement | Status under SEP-2577 |
|---|---|---|
| Roots | Tool parameters | Continues working for the next year per the specification |
| Sampling | Direct LLM provider APIs | Continues working for the next year per the specification |
| Logging | OpenTelemetry | Continues working for the next year per the specification |
What to Verify Before You Commit
The 12-month window covers the protocol’s own removal timeline, not the parallel work an enterprise still has to complete on its own schedule.
- Confirm which of your production MCP servers still send or expect an
Mcp-Session-Idheader, since that plumbing needs rework under the stateless architecture regardless of the deprecation clock. - Check whether any integration relies on Roots, Sampling, or Logging, and schedule the move to tool parameters, direct LLM provider APIs, or OpenTelemetry inside the next year.
- Verify that authorization responses validate the
issparameter, since SEP 2468 exists specifically to close the OAuth Mixup Attack path. - Confirm your security review tests tool-layer authorization separately from identity-provider authentication, given that the two are not automatically linked under the stateless spec.
- Ask whether your production server build — OAuth 2.1, multi-tenancy, rate limiting, audit logging — fits inside your slice of the 12-month window, using the four-to-ten-week build estimate as a planning floor, not a ceiling.
The specification doesn’t say how long a typical enterprise security review takes, so whether the MCP 12-Month Deprecation Window is enough depends entirely on how long your own review and SDK-upgrade cycle runs against that fixed clock.
Before committing to a migration timeline, map every deprecated-capability dependency against the 12-month clock and confirm your security team can complete an issuer-validation and tool-layer authorization review inside whatever time remains after SDK migration work.
Google Cloud’s own migration deadline offers a preview of what a compressed enterprise timeline looks like: it pushed customers toward its Agent Registry ahead of a July 30 Cloud API Registry shutdown, well inside MCP’s own grace period.