Learning outcomes
- Record exact protocol, profile, extension, and implementation status for every trust boundary.
- Distinguish final standards, best current practices, drafts, obsolete revisions, and vendor behavior.
- Design a measured migration with discovery, compatibility, rollback, and removal gates.
- Test that deprecated versions cannot return through hidden listeners or fallback paths.
Operating objective
Every security protocol use has a named owner, exact standard or profile, enabled versions, extensions, algorithms, peer population, implementation version, and removal date for obsolete behavior. Operators can show which traffic still depends on a deprecated path and can prove that the path is gone after migration.
Status terms matter. An RFC can be Standards Track, Best Current Practice, Informational, Experimental, or obsolete. An external specification can be a working draft, candidate recommendation, final specification, dated protocol revision, or vendor profile. A newer number does not automatically replace every deployment profile. Record the document date and status, not only the protocol family name.
For example, RFC 9846 is the July 2026 TLS 1.3 specification and obsoletes RFC 8446. RFC 9700 is OAuth 2.0 Security Best Current Practice and updates the security posture around existing OAuth specifications. The current MCP versioning model uses dated protocol revisions negotiated by clients and servers.
Signals and evidence
Collect evidence at each listener, client, issuer, proxy, and resource server:
- Negotiated protocol version, profile, extension, and algorithm.
- Peer and application owner, route, client type, and implementation version.
- Requests that use deprecated grants, token forms, endpoints, certificate algorithms, or fallback behavior.
- Failed negotiations after a warning or enforcement change.
- Configuration inventory and effective runtime configuration.
- Standard status, publication date, superseding document, and security rationale.
- Migration exception, owner, expiry, traffic volume, and last observed use.
Do not log tokens, credentials, or unnecessary user data. Use counters and bounded identifiers. Validate telemetry against packet, trace, or conformance evidence because a library can report a family name while using an unsafe profile.
Response and recovery
- Define the target protocol profile and the exact behavior to remove. Include versions, algorithms, grants, endpoints, and fallbacks.
- Inventory every consumer and hidden path. Include old mobile clients, automation, disaster-recovery environments, secondary listeners, and direct origins.
- Add safe target support before disabling the old path. Verify interoperability and security checks with conformance and negative tests.
- Measure use. Notify internal owners through the approved change process. Give each temporary exception an owner and expiry.
- Disable the old behavior in a bounded stage. Monitor negotiation failures, authorization failures, and unsafe fallback. Roll back only to the documented temporary control, not to an open-ended compatibility mode.
- Remove old code, configuration, trust anchors, credentials, tests that assert legacy success, and documentation. Add a negative test that proves the old path stays disabled.
- Re-scan after disaster-recovery tests and major upgrades. A restored configuration can reintroduce removed behavior.
Design tradeoffs and residual risk
Long compatibility periods reduce immediate client breakage and increase exposure, complexity, and downgrade opportunity. Fast removal improves the security baseline but can break unmanaged consumers. Telemetry-led migration makes the tradeoff visible.
Middleboxes and proxies can hide the real peer protocol. A modern external TLS connection can terminate before an obsolete internal connection. An OAuth client can use a current library while still selecting a deprecated grant. Measure every boundary.
Draft specifications can be necessary for interoperability. Pin the exact dated revision, isolate the feature, track incompatible changes, and state that the behavior is not final. Never describe a draft feature as a stable guarantee.
Pomerium boundary
Pomerium supports protocols and features according to its deployed version and configuration. Operators own upgrades, client and upstream compatibility, protocol policy, exception expiry, and removal evidence. Pomerium cannot remove an obsolete protocol used directly between an upstream application and another client outside its route.
Exercise
Choose one protocol family in production. Build a matrix of every boundary, exact version or dated revision, implementation, negotiated behavior, owner, traffic, target state, exception, and removal test. Use runtime evidence to find at least one path that configuration inventory alone does not show.
Run a staged deprecation. First warn and measure, then block a test population, then remove the behavior. Verify that the old path fails on the public listener, internal listener, direct origin, disaster-recovery environment, and after rollback testing.
Evaluation checklist
- Does the inventory name exact versions, profiles, extensions, and standard status?
- Can telemetry identify every remaining consumer without recording credentials?
- Does each exception have an owner, reason, expiry, and compensating control?
- Is rollback bounded and unable to become permanent compatibility mode?
- Do negative tests prove that deprecated behavior cannot return through another path?
Next learning unit
Security Assurance and Evidence
Distinguish a control claim, verification, validation, assurance argument, and the evidence that supports each conclusion.
