Zero-trust identity for a member and employer portal

The constraint

Hundreds of thousands of members and employers signed in through an authentication platform that had become the biggest risk on the estate. The threat that mattered was account takeover: a retiree's bank details changed by someone who isn't the retiree. The platform couldn't meet NIST 800-63 at the assurance level the risk called for, and it couldn't be patched into meeting it. Everything behind it, from benefit estimates to payment changes, assumed it worked.

The decision

Replace it with federated identity through an external provider that proves who a person is at IAL2 and signs them in at AAL2, and treat every service behind the front door as untrusted until it proves otherwise. Tokens are encrypted and signed, JWE and JWS over RSA and ECDSA. Keys and certificates rotate on a schedule nobody has to remember. Services talk to each other over mutual TLS with X.509 certificates, so a call carries proof of who made it. Personal data is encrypted at rest with controls an auditor can read without a translator.

What it cost

A migration of every identity with no cut-over weekend, because members don't stop needing their money. Months on the edges: biometric liveness, and the fraud and identity-assurance workflows that run when a session doesn't look like the person it claims to be. And many hours with security, risk and audit before the first line of code. That last part is the one I wouldn't trade.

What shipped

The legacy platform was decommissioned. Every member and employer identity moved over with no service disruption. Step-up authentication is there for the moments that warrant it.

What it showed

Zero trust is mostly a sequencing problem. The identity provider is the easy part. The long tail is every service that quietly assumed the session was honest. I see the same shape now in agent systems, where an agent carries a credential and nobody downstream can tell whose authority it's acting on.