Three of the five risks have improved. Weak signing algorithms dropped from 19.0% to 15.2% of detections — a 20% relative decline, the sharpest improvement in the study. Basic Authentication with raw credentials fell from 9.0% to 7.3%. Long-lived tokens eased slightly, from 21.0% to 19.2%.
These three have something in common: each map to a specific, well-publicized fix. Use a stronger algorithm. Migrate to OAuth2 or mTLS. Shorten your token lifetimes. None of that is a secret, and the data suggests teams that heard the advice actually acted on it.
That’s a genuine win worth taking seriously. It’s also, as it turns out, the easy part.
The two risk categories that got worse this year aren’t the ones with a tidy, well-known fix. They live in implementation details, and, not coincidentally, they’re the two with the most direct line to actual data exposure.
Sensitive data inside tokens climbed to 49.8% of all detections, up from 46.0% last year — already the largest risk category in the study, now touching essentially half of everything we measured. That number deserves more alarm than it might get on first read: a JWT isn’t encrypted by default. It’s typically just base64-encoded, which is not the same thing — anyone who can see the token can read what’s inside it; no exploit required. A JWT doesn’t need to be “hacked” to leak data. It just needs to pass through an ordinary place in a modern stack: a log line capturing request headers, browser storage on a shared machine, a support ticket where a developer pastes a request for debugging. If the token carries a name, an email, an account number, every one of those mundane, everyday paths becomes a potential exposure event.
Expired-token access jumped from 5.0% to 8.5% — a 70% relative increase, the sharpest move of any category we track, in either direction. This one is arguably more alarming precisely because it’s the more mechanical risk to get right. Deciding what counts as “sensitive” involves judgment. Enforcing that a token stops working after its exp claim has passed does not. When it fails anyway, it’s usually because expiration was checked in one place — a central auth service — and never independently re-verified everywhere else the token gets used. Every other assumption a security team makes about tokens rests on expiration being the backstop. When that backstop doesn’t hold, everything built on top of it gets quietly weaker too.
We can’t say with certainty why either number moved the way it did — a mix of factors is plausible, including genuine changes in practice, improvements in our own detection, and shifts in which organizations were measured each year. What we can say is that the direction, for both, is the wrong one, two years running.
The Finding That Changes the Story
Here’s what we didn’t expect going in: authentication risk doesn’t usually show up alone.
We went endpoint by endpoint and asked a specific question — how often do these five risks appear together, on the same API, at the same time? The answer: 13,016 of the 32,725 endpoints we analyzed, nearly 40%, carried more than one authentication risk simultaneously. Not an edge case. Not occasional. Roughly two out of every five.
Picture what that looks like in practice. An endpoint that embeds sensitive data inside its tokens — a risk present in essentially half of all detections — sitting on the same endpoint as an expired-token gap that lets access continue indefinitely, a risk that grew 70% this year. We can’t say how often that exact pairing occurs; our data tells us endpoints carry multiple risks, not which specific risks pair together most often. But it’s exactly the kind of compounding scenario nearly 40% of endpoints are positioned for — a token that doesn’t just leak once, but keeps leaking, because nothing in the system ever cuts it off.
At the extreme end, it’s worse than pairing. The single riskiest endpoint we found carried all five risk types at once: sensitive data in the token, a weak signing algorithm, an excessively long lifetime, Basic Authentication, and continued access after expiry. Endpoints like that usually aren’t the result of five separate, unrelated mistakes. More often, they’re a single legacy or lightly-used endpoint that never got touched when the rest of the environment moved to better practices — quietly running on old assumptions while everything around it improved.
That’s the pattern that should reframe how this whole report gets read. If these risks were scattered at random, an endpoint like that would be a statistical fluke. Instead, the pattern repeats across nearly 40% of everything we measured. That’s not scattered. That’s systemic — and it means the standard response to finding one authentication issue, patching it and closing the ticket, is very likely leaving a second or third issue sitting untouched on the exact same endpoint.
What This Means for How We Approach Authentication
Here’s the uncomfortable pattern sitting underneath all of the numbers above: the risks that improved this year are the ones that are easy to check. The risks that got worse are the ones that are hard to check. That’s not a coincidence — it’s a fairly accurate description of how security improvement actually happens inside most organizations.
“Did we pick a strong signing algorithm” is a yes-or-no question a scanner can answer in seconds. “What data did we decide to put inside this token, and did anyone revisit that decision when a new field got added eighteen months later” is not. “Are we still using Basic Auth” shows up on nearly every audit checklist in the industry. “Does every service that validates this token independently re-check its expiration or does one of them just trust the gateway” usually doesn’t, because answering it requires understanding how a system actually behaves, not just which protocol it uses.
We think that’s the real story in this year’s data. The industry has gotten reasonably good at fixing the authentication problems that are legible — the ones a checklist can catch, the ones a single well-publicized recommendation can meaningfully move. It hasn’t gotten meaningfully better at the problems that require understanding how a system was actually built, which is exactly the category the two worsening risks, and the clustering pattern connecting them, fall into. A scanner can tell you a token is signed with a weak algorithm. It’s much worse at telling you that the same token is also carrying a customer’s date of birth.
If there’s one thing worth taking from this report, it’s this: the next time your team finds one authentication issue on an endpoint, the right instinct isn’t relief that you caught it. It’s to ask what else is sitting there next to it — because in nearly 40% of the cases we looked at, the answer was something.
Get the Full Report
This post covers the headline findings. The full 2026 Token & Authentication Risk Report includes the complete year-over-year breakdown across all five categories, the reasoning behind each shift, and specific, practical recommendations for where security and engineering teams should focus first.
Download the 2026 Token & Authentication Risk Report →
Try Imperva for Free
Protect your business for 30 days on Imperva.
Start Now