The IAM Stack's Real Vulnerability Is a SHOULD, Not a MUST

I didn't buy the numbers. Five CVSS 9.1-plus criticals in three weeks across a single identity stack. CVE identifiers stamped 2026. A claim that monthly CVE volume doubled from 5,045 to 10,740 — against a baseline that has never cleared roughly 4,500 in a month, ever. I ran the arithmetic twice on the back of an envelope. It does not survive a spreadsheet. But strip the inflation and something correct is still standing underneath. It's the same thing I've been shouting about in crypto for two years. The federated identity layer — Keycloak, OAuth2 Proxy, Better Auth, Budibase, Frontegg, Citrix NetScaler, AD FS — treats the assertions handed to it as ground truth rather than as claims that require verification. Token arrives. Header arrives. Email-verified flag arrives. Trust is granted. No questions asked. That's not a vendor bug. That's an architecture decision. And it is the exact decision that got a long list of DeFi protocols drained in 2021 and 2022, and the decision being rebuilt right now inside every AI agent framework on the market. Map the seven subjects and you get four shapes, not seven. Open-source components — Keycloak, Better Auth, OAuth2 Proxy. Commercial identity SaaS — Frontegg. Enterprise gateway — Citrix NetScaler. Directory service — AD FS. Low-code built-in — Budibase. The common thread matters more than the taxonomy: authentication is an embedded capability, not a product. Nobody sells "authentication." They sell a checkbox living inside something else — a gateway, a BaaS, a low-code builder. That structural fact explains almost every failure in the disclosure set. Look at where the breakage clusters. At least five of the eight issues reduce to one of two things: defaults too permissive, or a validation step simply omitted. Frontegg shipped without signature and issuer verification — CVSS 9.8, the kind of number that should end a vendor's quarter. Better Auth accepted the IdP's email-verification state at face value. Budibase admitted a user to a pending-invitation state on nothing but a matching email string. OAuth2 Proxy trusted the X-Forwarded-Uri header from a trusted proxy IP. That last one is the one that should keep you awake. A reverse proxy is supposed to be the boundary. If its trust model is broken, everything behind it is decorative. And here's the uncomfortable pattern: vendors make validation an optional switch to keep integration frictionless. So security strength becomes a function of the integrator's competence, not the product's guarantee. The more "out of the box" the identity integration, the more likely a critical check was traded away for a demo. Three defect classes recur. Missing audience or recipient binding. Missing issuer and signature enforcement. Missing three-way cross-validation between assertion, local resource, and local user state. Every one of these is cheap to fix in code and expensive to fix in culture, because the fix adds a failure mode during onboarding. The upstream cause isn't a vendor, though. It's the spec. SAML's AudienceRestriction and OAuth's aud, state, and nonce are described with SHOULD, not MUST. That language was chosen because MUST breaks backwards compatibility and vendor roadmaps. The result is an industry default state of "compliant but fragile." I've audited enough of these integrations to know the phrase is not an exaggeration. Then there's the open-source vacuum. Four of the eight issues landed in community-maintained components. Keycloak is the de facto open-source IdP standard, and its patch cadence depends on volunteers. Free is the most expensive license you will ever sign. Real TCO equals zero, plus patch tracking, plus configuration audit, plus incident response. Nobody puts that line in the procurement deck. Now move this into crypto, because that's where the real money is about to get hurt. Token delegation — OAuth Token Exchange, the on-behalf-of flow — is historically the densest vulnerability zone in the entire spec family. And agent middleware is nothing but token delegation at scale. I have first-hand data here. My 2025 sentiment agent, fifty thousand of my own capital, executed at half-second latency and printed a hundred and eighty thousand in two weeks. Then a dump hit and it misread the signal. I had to close a twenty percent drawdown by hand. The model wasn't the problem. The problem was that the API key I handed it had no scope binding — full account, read, write, withdraw. Same failure class. Assertion decoupled from local context. The blockchain doesn't fix this. It just makes the bypass permanent and auditable after the fact. Everyone is blaming vendor implementations. Wrong layer. The spec sits upstream, and there is no IAM DSS — no PCI DSS analogue for identity. Payment cards got a mandatory baseline after enough breaches. Identity never did, and it carries more of your data. The commercial impact is also asymmetric, and nobody prices it correctly. Switching costs protect incumbents from churn but do nothing for new-logo acquisition. So a wave of criticals quietly consolidates the market toward Microsoft and Citrix, because "look, open source leaked again" is a marketing asset rather than a crisis. Third — and this is the part crypto doesn't want to hear. We are rebuilding the identical stack. Sign-in with Ethereum. Session keys. Account abstraction paymasters. Scoped delegation. And we are making the identical trade: ease over enforced defaults. Front-running isn't the biggest risk on your stack. An unscoped session key is, because it doesn't need a mempool to ruin you. Watch two signals. Whether IETF and OASIS flip audience, issuer, and state from SHOULD to MUST. And whether MCP agent auth gets a real baseline before it ships at scale, rather than after. Until then, do the boring work: scope every agent key, treat your proxy layer as a security boundary rather than an ops convenience, and prove your assertion binding in a test. Hopium is not a config default.