The 40% Problem: How the Thales Stack Closes the Gap Between API Discovery and Data Protection

Introduction

If you asked most security teams whether their APIs are protected, they'd point to a gateway, a WAF rule set, or a newly deployed API security tool and say yes. Then Imperva, part of Thales, analyzed 32,725 live API endpoints across more than a thousand customer environments, and the answer got a lot less comfortable. Nearly 40 percent of those endpoints carried multiple authentication risks at once, not a single misconfiguration but several stacked together. Roughly half of all detections had sensitive data sitting inside the token itself, a figure that's gotten worse year over year, not better. One endpoint carried all five tracked risk types at once: sensitive data embedded in the token, a weak signing algorithm, an excessively long lifetime, basic authentication with raw credentials, and continued access after the token had technically expired.

That last example is worth sitting with. It's a real, live endpoint, found in a real customer environment, already protected by whatever tools that organization had in place. This is the uncomfortable truth about API security in 2026: most organizations have a tool that discovers and monitors their APIs, but far fewer protect the sensitive data actually moving through them, and fewer still have properly locked down the cryptographic keys that issue and sign the tokens in the first place. That gap, between knowing an API exists and protecting what flows through it, is exactly what the Thales stack, delivered in the UK through Cybergen, is built to close.

What Is API Security?

API security is the practice of discovering, assessing, and protecting the interfaces that connect your applications, partners, and data, covering everything from finding undocumented shadow APIs to stopping runtime attacks and protecting the sensitive data those APIs carry. It's distinct from traditional web application security because APIs are typically consumed by other systems rather than a browser, so the attack patterns, and the defenses needed, look different.

Why APIs Became the Front Door

APIs now carry the majority of internet traffic for most modern organizations, connecting mobile apps, partner integrations, microservices, and increasingly AI and LLM applications to the data behind them. That growth has outpaced most security programs' ability to track it. Shadow APIs, endpoints never formally documented, reviewed, or added to an inventory, are common in almost every environment of meaningful size, often created by a developer solving a short-term problem and never decommissioned. Every one is also, by definition, outside your existing gateway policies and outside the visibility of whatever tooling you already run, which is why shadow API detection has become its own line item in most evaluations.

Attackers have noticed. Business logic abuse, where an attacker uses an API exactly as it was designed but for a purpose it was never meant to serve (scraping pricing data at scale, enumerating user accounts, abusing a discount code endpoint), has become one of the fastest-growing categories of API attack, precisely because it doesn't look like a traditional exploit. A WAF built to catch SQL injection and cross-site scripting has little to say about a request that is technically well-formed and hits a legitimate endpoint the way a real user would, just thousands of times a minute. This is also why the conversation has shifted toward machine identities and the credentials those systems use to talk to each other, which is where the risk report's findings become especially relevant.

The Blind Spot Most API Security Tools Share

Here's where most API security programs quietly stop short. A modern API security platform will discover your APIs, including the shadow ones, assess them against the OWASP API Security Top 10, and apply runtime protection against attacks and bot-driven abuse. That's genuinely valuable, and it's the layer most vendors compete hardest to sell. But discovering an API and scoring its risk doesn't change what happens to the data once a request is authenticated and let through. If a token carries embedded PII, if a payload contains unmasked financial data, if a signing key is weak enough to forge, the best discovery and monitoring tool in the world will still let that data move through in the clear.

This is precisely the gap the 39.8 percent statistic exposes. Multiple, overlapping authentication risks were sitting in production, in environments that in many cases already had monitoring in place. Visibility told those teams a problem existed; it didn't fix the token, mask the data, or replace the weak signing key. That takes a different layer of protection, and it's the layer most API security conversations skip.

Layer One: Discover and Protect the API Itself

The starting point is still necessary, even if it isn't sufficient alone. Imperva API Security, part of the Thales portfolio since the 2023 acquisition, continuously discovers and monitors APIs across cloud, on-premise, and hybrid environments, including shadow APIs that never made it into anyone's inventory.

It assesses every discovered API against the OWASP API Security Top 10, flagging design weaknesses and configuration drift, and at runtime protects against API-specific attacks and business logic abuse, working alongside Imperva's Advanced Bot Protection to catch high-volume, technically legitimate abuse that traditional WAF rules miss entirely. It integrates with the API gateways organizations already run, including Kong, Mulesoft, Azure API Management, Apigee, and F5, with both agent-based and agentless deployment options.

This layer answers "what APIs do we have, and are they behaving the way they should." It's the foundation, not, on its own, an answer to what happens to the data those APIs are moving.

Two: Protect the Data Flowing Through the API

This is where CipherTrust earns its place, specifically CipherTrust Data Protection Gateway, a purpose-built answer to the exact problem the token report surfaced. It sits in front of RESTful web services and microservices and applies encryption, tokenization, and masking directly to JSON payloads and fields, with no code changes ever required from development teams. Security administrators define which fields get protected, how (encryption, tokenization, static or dynamic masking, or full redaction), and who can see unmasked values, all managed centrally through CipherTrust Manager rather than scattered across application code.

Applied to the scenario Imperva's report describes, this is the layer that matters most. A token with sensitive data embedded inside it stops being a liability the moment that data is tokenized or masked before it ever reaches the token in readable form. An attacker who intercepts or forges a token gets a placeholder, not a customer's PII or a financial record. This is also the layer that makes API security relevant to compliance teams, not just SOC analysts, since tokenization and format-preserving encryption are exactly the controls regulators look for when asking how sensitive data is protected in transit and in use, not just at rest.

Layer Three: Protect the Keys and Identities Behind the Tokens

The third layer addresses the root cause behind weak signing algorithms and forgeable tokens: the cryptographic keys used to issue and sign them. Thales Luna hardware security modules generate, store, and use signing and encryption keys inside dedicated, tamper-resistant hardware rather than application memory or configuration files, closing off a common path to a forged token. Alongside key protection, SafeNet Trusted Access provides adaptive, risk-based authentication for the developers, administrators, and platform engineers managing the API estate itself, whose own credentials are just as attractive a target as any API token.

Put together, this layer answers a question the other two can't: not just "is this token valid" but "was it ever possible to forge in the first place."

Machine Identities: The Hidden Attack Surface Behind Every API Token

Every API token, service account, and signing key is, functionally, an identity, just not a human one. Analysts call this category machine identity, or non-human identity, and it's growing far faster than the human workforce it sits alongside, since every microservice, CI/CD pipeline, and third-party integration typically needs its own token or key. Most identity programs were built around people, with strong onboarding, offboarding, and review processes. Machine identities rarely get the same discipline: a service account created for a six-week project often outlives the project by years, and a signing key generated for a proof of concept has a habit of ending up in production.

This is exactly the population the Imperva risk report describes. Excessively long token lifespans and tokens that kept granting access after expiry are both symptoms of machine identities that were never properly retired or rotated. Treating API security as a machine identity problem, not just an endpoint problem, is what connects Layer One's discovery work to Layer Three's key management: you can't govern the lifecycle of a machine identity you haven't discovered, and you can't secure a token whose signing key was never protected in the first place.

Why One Layer Alone Isn't Enough

Go back to the endpoint that carried all five risk types at once. An API discovery and runtime protection tool could flag it as high risk, but couldn't, on its own, mask the sensitive data, strengthen the signing algorithm, or move key management into hardware. Each fix lives in a different layer, and an organization running only one layer is, by definition, solving only part of a problem that shows up as compounding, not isolated, risk.

This is the case for treating API security as a three-layer problem rather than a single product category. Discovery without data protection leaves sensitive data exposed the moment a token is compromised. Data protection without key management leaves the door open to forged tokens. And key management without API visibility means protecting keys for endpoints you don't know exist. The Thales stack treats these as one coordinated architecture, not three separate vendor relationships.

Where AI Fits Into the Picture

The same three-layer thinking is extending into the newest category of API risk: AI and LLM application interfaces. Imperva AI Application Security, part of the same portfolio, addresses threats specific to generative AI applications, including prompt injection, system prompt leakage, sensitive data exposure through model outputs, and resource abuse that runs up compute costs through excessive requests. Traditional WAFs largely can't see these threats because the requests involved are, technically, using the model as intended. As organizations expose more LLM functionality through APIs, the same discovery, data protection, and key management logic applies, just with a newer set of endpoints.

Why This Matters Beyond the SOC

For a CISO, the value isn't just technical, it's what it lets you say in a board or audit conversation. Regulatory frameworks including GDPR, PCI DSS, DORA, and NIS2 expect organizations to demonstrate protection of sensitive data specifically, not just awareness that an API exists and is monitored. Showing that sensitive fields are tokenized before they leave an API, that signing keys live in certified hardware, and that discovery is continuous rather than a point-in-time audit gives you a defensible answer that a dashboard of endpoints alone does not.

Why Global Organizations Work With Cybergen for the Thales Stack

Cybergen is a Thales partner, which means global organizations bringing this stack together, API Security, CipherTrust, and the identity and key management layer beneath it, get it implemented by a team that already treats detection, data protection, and compliance as one connected problem, not three separate purchases. Cybergen's own portfolio spans 24x7x365 managed detection and response, penetration testing, and compliance consulting across ISO 27001, Cyber Essentials, NIS2, and DORA, so the Thales stack isn't dropped in as an isolated tool. It's deployed alongside the monitoring and compliance work that turns API discovery and data protection into evidence your board and regulators can use.

Getting Started

If your organization has API discovery and monitoring in place but hasn't looked specifically at what's happening to the data inside your tokens and payloads, that's the conversation worth having next. Cybergen can walk through what a token and data audit would surface against your own API estate and map out how CipherTrust and Thales's key management slot in around the tools you already run, without ripping out what's working.

The 39.8 percent statistic isn't a reason to panic. It's a reason to check which layer of the stack you're covering, and which one is still open.

Frequently Asked Questions

What is API security, and how is it different from a web application firewall?

API security covers discovery, risk assessment, and runtime protection of APIs specifically, including business logic abuse and shadow API detection. A traditional WAF catches known attack patterns like SQL injection and cross-site scripting, but generally can't detect abuse of an API's own legitimate functionality, one of the fastest-growing categories of API attack.

What is CipherTrust Data Protection Gateway, and how does it protect APIs?

It sits in front of REST APIs and microservices and applies encryption, tokenization, or masking to sensitive fields in JSON payloads, with no application code changes. Policies are managed centrally, so security teams can update how sensitive data is handled without involving developers.

How do hardware security modules relate to API token security?

HSMs like Thales Luna generate and store the cryptographic keys used to sign and issue tokens and certificates inside dedicated, tamper-resistant hardware, closing off a common path to weak or forged tokens that arises when signing keys sit in application memory or config files instead.

Is this relevant to AI and LLM applications, or only traditional APIs?

Both. As organizations expose more generative AI functionality through APIs, the same discovery, data exposure, and authentication risks apply, alongside AI-specific threats like prompt injection and system prompt leakage, which Imperva AI Application Security is built to address.

How do UK organizations get access to the Thales API security stack?

Cybergen is a Thales partner and can help UK organizations bring Imperva API Security, CipherTrust, and Thales's identity and key management products together as a coordinated deployment, alongside Cybergen's own managed detection and compliance services.

How can organizations protect API tokens from being stolen or forged?

Address all three layers together: discover every endpoint that issues or accepts a token, mask the sensitive data embedded inside it, and protect the signing keys in certified hardware rather than application code. Shortening token lifespans and enforcing expiry properly, two risks named in Imperva's research, also shrink the window an attacker has to use a stolen token.

Ready to strengthen your security posture? Contact us today for more information on protecting your business.