Before the Model Context Protocol's July 28 release, rolling out MCP to a hundred engineers meant a hundred separate OAuth consent screens - one per person, per server. Multiply across a dozen connectors and IT had no single place to see, let alone revoke, what was connected. That problem is now solved, partially.
The MCP 2026-07-28 specification is the largest revision of the Model Context Protocol since its launch, reaching into transport, extensions, authorization, and tool schemas at once. Two changes matter most for teams: the protocol goes stateless, and Enterprise-Managed Authorization (EMA) graduates to stable. They're related, but they solve different problems - and understanding which one helps you this week matters.
What going stateless actually means for your infrastructure
The headline change is a stateless protocol core: no initialize handshake, no protocol-level sessions, so MCP servers finally run behind ordinary load balancers and on serverless platforms.
That sounds like plumbing, and it is - but the previous design created real operational costs. Earlier MCP transports began with an initialize and initialized exchange that would start a session. A server could assign an Mcp-Session-Id header, and every subsequent request had to find the state associated with that session. In practice this meant that autoscaling infrastructure had to preserve active sessions, deployments had to drain or migrate them, and losing an active instance could force clients to reconnect or lead to broken sessions.
Stateless requests change the model entirely. Every request now carries its own identity and capability information inline. That's a single, well-defined control point - and it's one a standard API gateway can enforce.
The trade-off is honest: this stateless model increases request payload sizes because client capabilities and session parameters must be transmitted with each call. However, it enables standard production features: full JSON Schema 2020-12 validation, cache-control hints (ttlMs and cacheScope), W3C Trace Context propagation for OpenTelemetry, and a modular extensions framework.
For teams running MCP servers in cloud-native environments, the practical upside is direct. If you provisioned sticky sessions, session stores, or oversized always-on instances purely to satisfy the old protocol, you can now simplify and often cut cost.
Enterprise-Managed Authorization: what it does, and the gap it leaves
MCP spread through enterprises bottom-up, one connector at a time, with authorization left as an afterthought. The original model is per-user, per-server OAuth: every employee clicks through a consent screen for every server. That's the right default for a consumer wiring up a personal integration. Inside a company it's a mess, and a security gap nobody owns.
Enterprise-Managed Authorization reached stable status June 18, 2026, replacing per-user OAuth consent screens with a zero-touch IdP-delegated flow. Okta is the first supported identity provider; Anthropic, Visual Studio Code, and nine MCP servers ship support at launch.
The developer experience target is authorize once, inherit everywhere. Sign in through Okta (or future IdPs) once per session or per policy interval, and every EMA-enabled MCP server in the catalog inherits that trust without separate OAuth dances per vendor.
Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support enterprise-managed auth at launch, with Slack coming soon.
GitHub Copilot in VS Code runs on the same MCP layer, so Copilot agent mode with MCP tools goes through the same enterprise auth flow.
That's a real list of tools real engineering and product teams use. If your org is already on Okta - or on Entra ID, which VS Code supports as well - and your organization is already on Microsoft's identity stack, Entra is supported today.
The catch nobody in the launch coverage says clearly: EMA decides the connection, and through scopes the coarse set of actions possible at issuance. What it can't do is make a runtime, context-aware decision about a specific call. The spec is explicit that the IdP never sees the MCP traffic. That runtime decision - per-action authorization - is the layer EMA leaves entirely to you, and it lives in the data path.
In plain terms: EMA stops the wrong person from connecting to your Linear MCP server. It does not stop an authorized agent from closing every open issue at 2 a.m. if the scopes allow it. Per-action runtime governance is still your problem to build.
Beagle in action#engineering-tools, Slack, rolling out MCP to a 60-person teamThe deprecation clock is running - but not urgently
Existing servers do not break - nothing breaks on July 28 - but teams that adopted the experimental 2025 Tasks API must migrate, and everyone should plan SDK upgrades within the deprecation windows.
| What's deprecated | Still works until | Action needed |
|---|---|---|
| HTTP+SSE transport | At least July 2027 | Plan migration to stateless HTTP; no rush |
initialize/initialized handshake |
Removed in 2026-07-28 | Upgrade SDK; new servers build stateless-native |
| Roots, Sampling, Logging | 12+ months runway | Don't adopt in new implementations |
| Dynamic Client Registration (DCR) | Works, but deprecated | Migrate to Client ID Metadata Documents |
Upgrade SDKs deliberately, starting with new servers - build them stateless-native from day one - and internally owned servers, leaving vendor-supplied servers to their vendors' timelines.
The practical migration sequence: if you're behind a gateway or load balancer, test the stateless path and confirm your routing doesn't depend on anything the protocol no longer provides. If you ship to enterprise customers, evaluate Enterprise-Managed Authorization and Okta's Cross App Access now - it addresses the consent-prompt friction that's slowed enterprise MCP rollouts.
A teammate like Beagle can help teams track where MCP connections currently live - surfacing which channels have active integrations and flagging ones running on personal OAuth accounts before a security review does it for you.
MCP enterprise authorization: common questions
What is the MCP 2026-07-28 specification?
It is the largest revision of the Model Context Protocol since launch and delivers on the 2026 roadmap: a stateless core that scales on ordinary HTTP infrastructure, extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension, authorization that aligns more closely with OAuth and OpenID Connect deployments, and a formal deprecation policy so the protocol can evolve without breaking what you've built.
Will our existing MCP servers break when we upgrade?
No. Beta SDKs for Python, TypeScript, Go, and C# shipped June 29, 2026 so teams can test the new revision now, and the MCP maintainers are explicit that nothing already running breaks on July 28 - adoption is opt-in. The legacy HTTP+SSE transport has a twelve-month offramp before removal.
Does Enterprise-Managed Authorization mean we don't need to worry about agent permissions?
Not quite. EMA solves access - it controls which users can connect to which MCP servers via your IdP. What it isn't: a replacement for OAuth 2.1, or a runtime policy engine for what an agent does once it's connected. You still need to define and enforce what actions agents are permitted to take after they connect.
Which identity providers and tools support EMA today?
Okta is the first to ship support at the MCP spec level, via Cross App Access (XAA). VS Code independently supports Entra ID and Auth0 on top of that. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are live at launch, with Slack listed as coming soon.
Should we migrate to the stateless core right now?
Only if you're building something new or already hitting infrastructure pain. Do not panic-migrate. Nothing forces a release-day cutover. Dual-mode support means old and new coexist. The clearest reason to move fast is if you're paying for sticky session infrastructure that the stateless core would let you eliminate.