Federal agencies have known about Encrypted Client Hello since major browsers began supporting it in 2023. Yet, Wyden's office just identified 350 federal web addresses still broadcasting which sensitive sites Americans visit, including the FBI's tip portal, the Veterans Crisis Line, and intelligence community recruitment pages. These aren't obscure technical services. They're high-value surveillance targets.
This isn't about missing technology. ECH is already deployed across millions of commercial websites. The problem is how agencies approach encryption upgrades: as optional security improvements rather than operational imperatives. Here's what keeps going wrong.
Why These Mistakes Keep Happening
Most agencies treat ECH like a nice-to-have feature rather than a zero trust requirement. The protocol hides the specific website name during the TLS handshake, which is crucial for preventing adversaries from profiling cleared personnel, identifying whistleblowers, or tracking crisis support seekers. But because the content itself is already encrypted under HTTPS, teams assume they've checked the encryption box.
This misses the point. Zero trust architecture under OMB M-22-09 requires assuming breach and limiting adversary movement. If you're letting network observers see that someone from a DoD IP address just connected to tips.fbi.gov, you've given away operational intelligence before the session even starts. The encrypted payload doesn't matter if the metadata tells the story.
Mistake 1: Assuming Your Cloud Provider Enabled ECH
Why it happens: Teams see "encryption in transit" in their cloud security documentation and assume modern protocols are active by default. You've verified TLS 1.2 or higher. The security checklist shows green.
Real consequence: The Veterans Crisis Line platform runs on AWS, which doesn't currently support ECH for the site according to Wyden's letter. Veterans seeking mental health support are potentially identifiable to anyone monitoring network traffic, which could prevent someone from reaching out during a crisis.
The fix: Test your public-facing sites using third-party network vantage points, not just from inside your agency network. Wyden's staff used external testing to identify which sites actually hide the destination hostname. If you're on AWS, Azure, or another major provider, explicitly verify ECH support with your technical account manager and check whether it requires configuration changes or service tier upgrades. Document the provider's current ECH roadmap in your System Security Plan under SC-8 (Transmission Confidentiality and Integrity).
Mistake 2: Treating ECH as a Provider Problem, Not a Configuration Problem
Why it happens: You're using Cloudflare or another provider that supports ECH. The capability exists in your infrastructure stack. Your team assumes it's automatically protecting traffic.
Real consequence: The FBI's tips.fbi.gov runs on Cloudflare, a provider that fully supports ECH, but the portal hasn't enabled it. Anyone trying to report criminal activity or provide intelligence tips is broadcasting that fact to network observers. The gap isn't technical capability; it's configuration management.
The fix: Audit every public-facing application to verify ECH is actually enabled, not just supported by the underlying platform. This belongs in your continuous monitoring plan under CA-7. For sites on Cloudflare, check your SSL/TLS settings in the dashboard. For other providers, review your CDN or load balancer configuration. If enabling ECH is as simple as changing a setting, there's no excuse for leaving it disabled. Update your configuration management baseline to include ECH status as a mandatory check.
Mistake 3: Ignoring Metadata Exposure in Your Zero Trust Planning
Why it happens: Your zero trust roadmap focuses on identity verification, micro-segmentation, and endpoint security. Those are the loud requirements in M-22-09. Encryption gets treated as table stakes, you have HTTPS, you're done.
Real consequence: Sites like hotline.oig.dhs.gov (DHS inspector general complaints), civilrights.justice.gov (Justice Department civil rights reporting), and apply.intelligencecareers.gov (intelligence community recruiting) are all on Wyden's list. Each one leaks operational intelligence through unprotected hostname visibility. You're meeting the encryption requirement while failing the "assume breach" principle. An adversary monitoring traffic now knows which of your employees are applying to IC positions, who's filing civil rights complaints, or who's contacting an inspector general.
The fix: Expand your zero trust assessment to include metadata protection explicitly. When you evaluate SC-8, don't just verify encryption exists, document what information remains visible to network observers. ECH should appear in your zero trust architecture documentation as a specific implementation of transmission confidentiality. If you're using CISA's Zero Trust Maturity Model, this belongs in the Network/Environment pillar under encrypted traffic analysis prevention.
Mistake 4: Waiting for Government-Wide Guidance Instead of Acting on Available Standards
Why it happens: Federal IT moves on policy, not just technology. Teams wait for CISA binding operational directives, OMB memoranda, or NIST updates before implementing new protocols. ECH hasn't appeared in a BOD yet, so it feels premature.
Real consequence: Major browsers have supported ECH since 2023. Millions of commercial websites already use it. While agencies wait for formal guidance, adversaries are collecting traffic analysis data on sensitive government interactions. The intelligence value of that metadata doesn't wait for policy cycles.
The fix: Treat ECH as an implementation of existing requirements, not a new requirement waiting for guidance. SC-8(1) already requires cryptographic protection against unauthorized disclosure during transmission. SC-13 requires FIPS-validated cryptography for federal systems. ECH is an available control that satisfies both. Document it as a compensating control if your current baseline doesn't explicitly call it out. If you're already implementing TLS 1.3 per NIST SP 800-52 Rev 2, adding ECH is a logical extension. Don't wait for Wyden's requested OMB requirement, by the time that policy arrives, you should already have ECH deployed.
Mistake 5: Overlooking ECH in Your Supply Chain Security Requirements
Why it happens: Your flow-down requirements to cloud providers focus on FedRAMP authorization, Impact Level certification, and FIPS 140-2 modules. ECH isn't a line item in your contract vehicles or security exhibits.
Real consequence: You're locked into multi-year agreements with providers that don't support ECH or require expensive tier upgrades to enable it. Your agency's sites remain exposed not because of technical barriers but because of procurement decisions made before ECH was on anyone's radar.
The fix: Update your cloud service provider security requirements to explicitly include ECH support. For new procurements, make it a mandatory capability in your statement of work. For existing contracts, work with your contracting officer to determine whether ECH can be added through a modification or whether it requires waiting for the next option period. If Wyden's request succeeds and OMB requires ECH support for federal cloud contracts, you'll already have the language ready. In the meantime, prioritize ECH-capable providers for new system deployments, especially for sites handling sensitive interactions like tips portals, crisis lines, or personnel security applications.
Prevention Checklist
- Test all public-facing sites from external networks to verify ECH actually hides destination hostnames
- Document provider ECH support status and required configuration steps in your SSP
- Add ECH verification to your continuous monitoring procedures under CA-7
- Update zero trust architecture documentation to include metadata protection requirements
- Review sites handling sensitive interactions (tips, complaints, crisis support, recruiting) first
- Revise cloud provider security requirements to mandate ECH support in future contracts
- Map ECH to existing control requirements (SC-8, SC-8(1), SC-13) rather than treating it as optional
- Establish configuration baselines that include ECH status as a mandatory parameter
- Brief leadership on metadata exposure risk using examples from Wyden's list
- Set a deadline for ECH deployment that doesn't wait for government-wide policy
The technology is here. The browsers support it. Commercial sites use it. If your federal websites are still broadcasting which sensitive services Americans access, you're not waiting on innovation, you're just not treating metadata protection as seriously as you treat payload encryption.
