Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.
The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.
Why TLS certificate lifespans are shrinking to 47 days
Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.
How to prepare for 47-day certificates: five things to do, in order
Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.
Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.
What Imperva is already doing: 90-day certificates and the R46 root
Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.
The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.
Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.
Frequently asked questions about 47-day certificates
When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.
How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.
Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.
What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.
Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.
Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.
What shipped: hybrid post-quantum TLS on every Cloud WAF site
Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.
The second leg: post-quantum TLS from Imperva to your origin
A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.
The honest scope: what hybrid key agreement covers
Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.
What to do about harvest now, decrypt later
Nothing, for the client leg. It is already on.
Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.
The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.
Harvest now, decrypt later: FAQ
What is a harvest now, decrypt later (HNDL) attack?
An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.
Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?
Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.
What is X25519MLKEM768?
It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.
What happens if a client or origin doesn’t support post-quantum TLS?
The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.
The 2026 edition of the the OWASP Top 10 for LLM Applications, published by the OWASP GenAI Security Project on August 3, 2026, is easy to skim past. No entry was dropped and no new category was introduced, so at a glance it can read as housekeeping. It is worth a closer look than that. Eight of the ten entries changed position, and one was renamed and widened in scope, which changes what it asks of the teams working against it.
When a framework adds or drops entries, it is usually telling you the threat surface itself has changed. This edition did something more specific. The categories held, but their order was substantially revised and one of them grew, which suggests the original naming was sound while the relative priority had drifted from what teams were meeting in production. Read the movements together and a pattern shows up.
The short version: the OWASP Top 10 for LLM Applications 2026 kept all ten categories but moved eight of them. Excessive Agency climbed from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. System Prompt Leakage was renamed Hidden Context Exposure and broadened to cover everything an application places in front of the model without the user seeing it.
What changed in the OWASP LLM Top 10 2026
The table below sets the 2026 order against the 2025 one, listed by 2026 rank.
2025 rank
Entry
2026 rank
Movement
LLM01
Prompt Injection
LLM01
No change
LLM02
Sensitive Information Disclosure
LLM02
No change
LLM06
Excessive Agency
LLM03
Up 3
LLM03
Supply Chain
LLM04
Down 1
LLM04
Data and Model Poisoning
LLM05
Down 1
LLM10
Unbounded Consumption
LLM06
Up 4
LLM09
Misinformation
LLM07
Up 2
LLM07
Hidden Context Exposure
LLM08
Down 1, renamed and widened from System Prompt Leakage
LLM08
Vector and Embedding Weaknesses
LLM09
Down 1
LLM05
Improper Output Handling
LLM10
Down 5
Prompt Injection and Sensitive Information Disclosure held first and second, which surprised nobody. Every other entry sits somewhere new, and the rest of this piece is about why the direction of those moves matters more than the individual rankings.
Excessive Agency and Unbounded Consumption: the climbers describe applications, not models
The two biggest climbers are the same kind of risk wearing different clothes. Excessive Agency is about what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach, how far one decision can travel before a human sees it. Unbounded Consumption is about what happens when that same application meets traffic engineered to abuse it, producing no malware and no traditional indicators, just an enormous bill. Neither is a property of the model. Both are properties of an application in production.
The biggest faller makes the same argument from the other end. Improper Output Handling dropped five places, and not because it stopped happening. It fell because it is the entry the industry already knew how to answer. Rendering untrusted output safely, refusing to execute what came back from an untrusted source, treating downstream consumers as a boundary: application security teams have been practicing that discipline for twenty years. The skill transferred. The novelty did not survive contact with people who already had the muscle.
Setting the renamed entry aside, the three entries that each slipped a place have something in common too. Supply Chain, Data and Model Poisoning, and Vector and Embedding Weaknesses are all risks you address before the application serves its first request, in procurement, in the training pipeline, in how the knowledge base was assembled and secured. They did not become less serious. They became less urgent relative to the things that only exist once the system is live.
Misinformation climbing two places fits once you ask who pays for it. A model that invents a refund policy is a quality problem in a lab and a liability problem in production, and a Canadian tribunal has already held Air Canada responsible for what its chatbot told a customer (Moffatt v. Air Canada, 2024). That entry did not move because models got worse. It moved because the consequences arrived.
Read together: the entries that climbed are the ones that only exist while the application is running. The entries that fell are handled before deployment, or handled by controls the industry already had.
From System Prompt Leakage to Hidden Context Exposure: the rename nobody is discussing
System Prompt Leakage became Hidden Context Exposure, and it is the most consequential edit in the document.
A system prompt is one specific thing: the instruction block sitting at the top of a conversation, defining the model’s role and its rules. Hidden context is everything else the application quietly places in front of the model without the user ever seeing it. Retrieved documents. Tool definitions. Prior turns held in memory. Configuration a developer assumed was private because no interface displays it.
The rename takes the entry from one field to an entire supply of runtime input, and it lands the same point the reordering makes. What the application feeds the model has become the attack surface. That is a materially bigger claim than the 2025 wording made, and any content or tooling still describing this entry as system prompt protection is now describing a fraction of it.
How to read an OWASP LLM Top 10 coverage claim, including ours
A reordering like this produces a wave of updated coverage claims, and some of them will describe protection across the whole list. Those claims are worth examining rather than accepting, and one question does most of the work: which control fires, inline, at runtime, for this specific entry?
Ask it of the entries that just fell. A poisoned model dependency arrives before a single request is served. At the moment of compromise there is no traffic to inspect, no prompt to score, no response to hold. Something does address that risk, but that something is a procurement process, a posture scan or a signed build pipeline. The same is true of a poorly governed vector store. These are real controls and they matter; they are simply not the same category of thing as a runtime control, and they usually sit with a different team and a different budget.
This is not a criticism of any product. It is the shape of the problem. Runtime protection covers runtime problems. When you meet a claim spanning all ten entries, the useful follow-up is to ask which of the ten are covered by inline enforcement, which by a scanner, which by a partner integration, and which by a policy document, and then to decide whether that composition is what you thought you were buying. A vendor who can answer that cleanly is telling you something about how they think. So is one who cannot.
Apply the same question to us. We would rather you did.
Where we stand against the 2026 order
Thales Imperva AI Application Security addresses five entries with runtime enforcement. In 2026 numbering, they are Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Unbounded Consumption (LLM06), Hidden Context Exposure (LLM08) and Improper Output Handling (LLM10).
Two of those five moved this year, and the moves cut in opposite directions. Unbounded Consumption climbed four places, which raises the profile of a control we already ship. Improper Output Handling fell five, which lowers the profile of another one we already ship. Reporting the first without the second would be the kind of selective reading this piece is arguing against.
Two of those five are also where our next work lands, and they are connected. Hidden Context Exposure now covers tool definitions, and Excessive Agency is the question of what an application is permitted to do once a model is driving it. We are adding tool call guardrails that check whether the specific tool being called is permitted, and the tool definitions themselves are what we look at next. Today we detect and monitor tool calls. Checking them against what is allowed is the step after that, and it is better to say so plainly than to let a coverage table imply it already exists.
The other five entries need different tools, and we would rather name them than imply otherwise. Supply Chain and Data and Model Poisoning are build-time and procurement problems. Vector and Embedding Weaknesses belongs with the data security controls sitting in front of the retrieval pipeline. Misinformation is evaluation and grounding work. Excessive Agency is the one to watch: it is the entry moving fastest toward runtime, it is where the agentic controls across this whole category are heading, and at number three it is now the highest-ranked risk that most security programs have no inline answer for at all.
The list caught up with agentic AI
In a recent piece we argued that the LLM Top 10 had been the warm-up, and that the frameworks describing agentic and MCP risk had already been published while most security programs were still resourcing against the first list. The 2026 edition is that argument told from inside the framework itself.
Excessive Agency at number three is an agentic risk sitting near the top of an LLM list. Hidden Context Exposure is the retrieval and tool layer being named as attack surface. Neither entry is about a model producing text. Both are about a system taking action on the strength of what it was fed. The list has started describing applications that act, which is the same shift the newer frameworks were built for.
A practical exercise for this quarter: take the four entries that moved most, and for each one write down which control in your own environment would fire while the attack was in progress, not after it appeared in a report. The gaps in that list are what the 2026 reordering is pointing at.
Thales’s Imperva AI Application Security is purpose-built runtime protection for AI applications, agents, and the ecosystems behind them, deployable in-app, at the Imperva edge, or via API, standalone or as part of Imperva’s unified application security platform. Our white paper, Beyond the LLM Top 10, maps the agentic and MCP threat surface against the published frameworks.
Frequently asked questions about the OWASP LLM Top 10 2026
What changed in the OWASP Top 10 for LLM Applications 2026?
The 2026 edition, published by the OWASP GenAI Security Project on August 3, 2026, added and removed no categories. Eight of the ten entries changed position: Excessive Agency rose from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. Prompt Injection (LLM01) and Sensitive Information Disclosure (LLM02) held their places, and System Prompt Leakage was renamed Hidden Context Exposure.
What is Hidden Context Exposure in the OWASP LLM Top 10?
Hidden Context Exposure (LLM08 in 2026) replaces System Prompt Leakage (LLM07 in 2025). It widens the entry from the system prompt alone to everything an application places in front of the model without the user seeing it: retrieved documents, tool definitions, prior turns held in memory and configuration a developer assumed was private.
Why did Excessive Agency move up to LLM03?
Excessive Agency describes what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach and how far one decision can travel before a human sees it. It climbed three places, from LLM06 to LLM03, as agentic applications that take actions moved into production.
Which OWASP LLM Top 10 risks can runtime protection address?
Runtime controls act on live traffic: prompts, responses and tool calls. Supply Chain and Data and Model Poisoning are build-time and procurement problems, Vector and Embedding Weaknesses belongs with data security controls in front of the retrieval pipeline, and Misinformation is evaluation and grounding work. When a vendor claims coverage of all ten entries, ask which are covered by inline enforcement, which by a scanner, which by a partner integration and which by a policy document.
Somewhere in your estate right now, a certificate is counting down to its expiry date. Today you probably know which one, because renewals still come around annually and someone owns the calendar. The industry is taking that comfort away: the CA/Browser Forum has voted to cut the maximum TLS certificate lifespan to 47 days by 2029, a decision we looked at in detail in our piece on shortened renewal periods. Renewals that happen once a year will soon happen every few weeks, and every manual touchpoint in that process becomes a potential outage. The math stops working.
The honest complication is that most enterprises do not live in a single-vendor world. You may run your own internal PKI. You may have standardized on a dedicated Certificate Lifecycle Management (CLM) platform. You may answer to compliance mandates that dictate exactly which Certificate Authority issues your certificates, and how. In those environments, visibility and control across every certificate matters as much as automating the renewals themselves. Until now, connecting those established workflows to Imperva meant manual effort, and manual effort is exactly what shrinking lifecycles no longer allow.
Today we are introducing the SSL Integration Center: an integration framework connecting Imperva Cloud WAF with leading Certificate Lifecycle Management platforms. It launches with its first supported integration, the DigiCert Trust Lifecycle Manager (TLM) Agent.
Your CLM stays in charge for certificate lifecycle management
The SSL Integration Center is not a new product or another console to learn. It is an integration framework, and the experience runs from the side you already live in: you configure the integration from within your CLM platform, and your CLM remains the place where certificates are managed. Once connected, two things happen from there. You can see all of your Imperva-managed domains and the SSL coverage status of each one, directly in your certificate workflow. And the complete certificate lifecycle cadence, issuance, renewal and deployment to Imperva, runs automatically under the policies your CLM already enforces. Imperva’s role is to integrate smoothly into the workflow you have, supplying application and SSL-coverage visibility and taking automated deployment off your hands. DigiCert is the first integration, and it sets the pattern for the CLM vendors that follow.
Thales-managed or customer-managed: your choice
Many organizations choose Thales-managed certificates because that removes the operational load of provisioning, renewal, monitoring and deployment in one move, and for them nothing changes. Others cannot adopt a fully managed approach: compliance requirements, PKI investments, established CLM platforms and governance policies often require a customer to keep control of their own certificate ecosystem. The Integration Center is built for that second group. You keep your CA, your CLM and your lifecycle processes, exactly where they run today, and Imperva plugs into them. Governance stays yours, and so does the console.
Starting with a leader: DigiCert Trust Lifecycle Manager
DigiCert TLM gives enterprises one place to discover, govern, automate and see certificates across cloud, hybrid and on-premises environments. It builds an organization-wide certificate inventory, enforces consistent cryptographic policy, and replaces surprise expirations with automated renewals. A useful way to think about the pairing: TLM is the system of record for your certificates, and the Integration Center is the delivery route into the applications Imperva protects.
With this integration, the DigiCert TLM Agent automates certificate issuance, renewal and deployment straight into Imperva. Under the hood, a post-enrollment script securely uploads the certificate chain and private key to Imperva through the Provisioning API, so a certificate governed in TLM arrives at your protected applications without anyone touching it. It runs on both Linux and Windows.
The value of that automation is documented. In a commissioned Total Economic Impact study, Forrester Consulting found organizations standardizing on DigiCert ONE, the platform behind Trust Lifecycle Manager, achieved 96% fewer outages from expired or misconfigured certificates, and a 312% return on investment over three years.
Source: The Total Economic Impact of DigiCert ONE (July 2025), a commissioned study conducted by Forrester Consulting on behalf of DigiCert. Results are based on a composite organization derived from customer interviews. Forrester does not endorse DigiCert or its offerings.
How the DigiCert TLM integration works
Govern in DigiCert TLM. Your certificate is issued and managed centrally, under the policies your organization already enforces.
Automate with the TLM Agent. A post-enrollment script runs on issuance or renewal and packages the certificate chain and private key.
Deploy through the Provisioning API. The script securely uploads the certificate to your Imperva cloud account and puts it to work protecting your applications. No manual upload. No missed renewal window.
What this means for your team
Continuous, compliant TLS protection. Issuance, renewal and deployment of custom certificates run without manual intervention, so your encryption stays current as lifecycles shrink.
Full bring-your-own-CA automation. If you use your own Certificate Authority and custom certificates, the entire lifecycle can now run end to end.
Fewer outages, less toil. Removing the manual steps removes the TLS outages that come from missed renewals, and frees your team from certificate babysitting.
Your Imperva estate, visible from your CLM. Once connected, your Imperva-managed domains and the SSL coverage status of each appear inside your certificate workflow, so DigiCert’s organisation-wide discovery and Imperva’s application coverage read as one picture, without switching consoles.
A certificate automation ecosystem that grows with you
Shorter certificate lifecycles are the new baseline, and they reward the organizations that automate. The SSL Integration Center makes that automation work on your terms: the CA you trust, the CLM platform you have standardized on, the compliance posture you are held to. It sits alongside Thales’s own SSL management capabilities, including certificate visibility, site coverage monitoring, notifications and real-time SSL health monitoring. DigiCert Trust Lifecycle Manager is the first integration and it will not be the last; each CLM vendor added becomes one more certificate workflow that arrives at your applications without a human in the renewal loop.
That certificate counting down in your estate? Under TLM and the Integration Center, its renewal has already happened by the time you would have thought to check.
It is also one thread in a wider fabric. Imperva integrates across the tools enterprises already run, from SIEM and ITSM platforms to API gateways, scanners and cloud providers, through the Imperva Technology Alliance Program. If your certificate stack is the workflow we meet today, the rest of your stack has a meeting point there too.
When the OWASP Top 10 for LLM Applications arrived, it did the industry a real service. It gave security teams a stable, vendor-neutral vocabulary for a threat surface that was moving too fast to describe. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling, unbounded consumption: five of those ten account for the bulk of what actually shows up in red-team exercises and public incidents.
Every framework earns its keep by naming what defenders are already fighting. Which is exactly why the next part matters: the next lists are not coming. They have already arrived. Most security programs simply have not caught up with them yet.
The three OWASP lists that now define AI security
Three published OWASP lists now cover the AI stack end to end. Together they are the checklist most security programs are not yet resourced against:
OWASP Top 10 for LLM Applications (2025) – the conversation layer. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption are the five that dominate real incidents.
OWASP Top 10 for Agentic Applications (2026) – the systems that act. Released 9 December 2025 by the OWASP GenAI Security Project. Ten risks, prefixed ASI, covering what happens when AI stops answering and starts doing.
OWASP MCP Top 10 (MCP01:2025-MCP10:2025) – the connective tissue. Currently in beta (Phase 3, beta release and pilot testing), covering the Model Context Protocol layer that wires assistants to real systems and data.
The OWASP agentic and MCP Top 10 lists are published. The budgets are not.
In December 2025, the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications (2026), covering the risks that appear when AI stops answering questions and starts taking actions: agent goal hijack (ASI01), tool misuse and exploitation (ASI02), identity and privilege abuse (ASI03), memory and context poisoning (ASI06), insecure inter-agent communication (ASI07) and rogue agents (ASI10).
Alongside it, OWASP’s MCP Top 10 project is codifying the risks of the Model Context Protocol, the standard that connects AI assistants to real systems and data. It is a young list, currently in beta – Phase 3, beta release and pilot testing, with entries carrying the MCP01:2025 through MCP10:2025 designation – and it is already one of the most useful documents in AI security, because it names the attack patterns defenders are meeting right now. Three of them deserve particular attention.
Command injection and execution (MCP05). An AI agent executes system commands built from untrusted input, without proper validation. An adversary who compromises the toolchain gets their work carried forward by the agent itself, with the agent’s legitimate permissions. The prompt was never touched. The model behaved exactly as designed. The compromise came in through the tools.
Tool poisoning (MCP03). The model is handed a list of tools it may call, and it trusts their definitions and their outputs. Poison either one and you have redirected the application’s behavior without a single suspicious token appearing in the conversation.
Insufficient authentication and authorization (MCP07). MCP servers, tools, and agents interacting without properly verifying identity or enforcing access controls. Who is allowed to call this tool? Which agent may delegate to which? In most environments today the answer is: whoever asks. That is not a vulnerability in a model. It is a missing identity layer for machines.
One more entry is worth a mention because it will sound familiar to anyone tracking shadow IT: shadow MCP servers (MCP09), the unapproved deployments running outside security governance, often on default credentials. The shadow AI problem now has an OWASP number. For the practical exposures behind these entries, see MCP Server Security: The Blind Spot in Your AI Stack.
None of these are theoretical. All of them get easier as organizations wire agents into more systems. And none of them have the household-name status that prompt injection now enjoys, which means the frameworks are ahead of most security programs’ resourcing. That is a new and uncomfortable position: the industry usually waits years for its threat lists. This time the lists arrived before the budgets.
History does not repeat, but it files tickets
We have watched this movie before. Monolithic applications got the OWASP Top 10. API-based applications got the API Security Top 10, because the attacks changed shape when the architecture did. AI applications and agents are the next architecture, and this time the pattern completed itself faster than ever: the LLM Top 10 for the conversation layer, the Agentic Top 10 for the systems that act, and the MCP Top 10 for the connective tissue between them.
So the catch-up question for security teams is no longer “what threats might emerge?” It is “which published OWASP entries is my program actually resourced against?” And the question for vendors sharpens the same way. Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”
The LLM Top 10 taught the industry to take AI threats seriously. The warm-up worked. The event has already started.
Frequently asked questions about the OWASP AI Top 10 lists
What is the OWASP LLM Top 10? The OWASP Top 10 for Large Language Model Applications is a vendor-neutral list of the ten most critical security risks in LLM-based applications, maintained by the OWASP GenAI Security Project. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption account for most of what shows up in red-team exercises and public incidents.
Is there an OWASP Top 10 for AI agents? Yes. The OWASP Top 10 for Agentic Applications (2026) was released on 9 December 2025. Its ten entries carry the ASI prefix and run from agent goal hijack (ASI01) to rogue agents (ASI10).
What is the OWASP MCP Top 10? A list codifying the security risks of the Model Context Protocol, the standard connecting AI assistants to real systems and data. Entries run MCP01:2025 to MCP10:2025 and include tool poisoning (MCP03), command injection and execution (MCP05), insufficient authentication and authorization (MCP07) and shadow MCP servers (MCP09). The project is in beta.
How many of the OWASP LLM Top 10 does Imperva address? Five out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption.
What should I ask an AI security vendor? Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”
Thales’s Imperva AI Application Security addresses five of the OWASP LLM Top 10 out of the box. We believe the industry’s next frameworks will be written about agents and toolchains. Thales announced the AI Security Fabric in December 2025, with an MCP security gateway and runtime access control for agentic AI interactions on the 2026 roadmap. Our white paper, Beyond the LLM Top 10, maps that terrain.
There is a moment every CISO is having right now, often without warning. A developer shows a working internal demo of an AI assistant trained on the company’s own documents. The product team is already planning a customer-facing version. The board has signed off on the budget. And somewhere in the middle of the meeting, a quiet question lands: what is securing this?
The honest answer, for most organizations today, is “nothing your existing stack was designed to do.”
This is not a critique of the security tools enterprises have spent years deploying. WAFs, EDRs, network firewalls, API gateways, identity platforms; these have evolved into a layered defense that genuinely works against the threats they were built for. But GenAI applications introduce a new attack surface that operates outside the boundary every one of those tools defends.
The problem is not that AI threats are more dangerous than traditional threats. The problem is that they are categorically different.
What is generative AI security?
Generative AI security is the practice of protecting LLM- and GenAI-powered applications at the AI interaction layer: the prompts going in, the model responses coming out, the conversation context in between, and the data and tools the model can reach. It is distinct from traditional application security because the attack payload is natural language, not a malformed request.
Why the old security playbook doesn’t cover generative AI?
Traditional security tools all share a common assumption: attacks come in the form of malformed inputs, malicious payloads, suspicious traffic patterns, or unauthorized access attempts. A WAF inspects HTTP headers, query strings, and request bodies for known patterns. An EDR watches for binaries behaving badly. An API gateway enforces schema and authentication.
An LLM-based application turns all of those assumptions on their head.
The payload in a prompt injection attack is grammatically correct English. The malicious code in a data leakage attack is a polite question. The denial of service pattern in an unbounded consumption attack is a perfectly legitimate looking conversation. The threats that matter to a GenAI application live at the level of the model’s logic, not at the level of the network or the HTTP request.
Even more critically, the security tools that protect the application surrounding the model have no visibility into what happens at the interface. The WAF sees the request to your AI endpoint. It does not see what the model does with that request. The API gateway authenticates the user. It does not understand whether the user is trying to convince the model to reveal its system prompt.
This is the gap that has emerged across enterprise security architectures over the last 18 months. It is not a minor blind spot. It is a category-level gap. Traditional security tools do not speak AI.
What AI-native security actually means?
When we talk about AI-native security at Imperva, we are not talking about adding AI features to a traditional security product. We are talking about a purpose-built control plane that understands prompts, model responses, conversation context, and usage patterns the way our WAF understands HTTP.
That distinction matters because AI security has to inspect the interaction itself. It has to understand what the user is asking for, how the model is likely to respond, whether sensitive data is being exposed, whether instructions are being manipulated, and whether usage patterns suggest abuse. This is inspection at the AI interaction layer rather than the network layer.
Thales’s Imperva AI Application Security is engineered specifically for the architecture of AI and agentic applications. It sits between your applications and the models they call, giving teams flexible deployment options rather than forcing a single architecture. Every input and every output is analyzed in real time, against multiple security guardrails, with adaptive risk scoring that distinguishes legitimate use from manipulation attempts.
Sensitive information disclosure through model outputs
System prompt leakage
Improper output handling
Unbounded consumption attacks that drive cost runaway and denial of service
And critically, it does not replace your existing WAAP. It extends it. AI Application Security plugs into the same unified Imperva platform that handles your WAF, API security, bot management, and DDoS protection. The same console, the same policy model, the same role-based access controls
The AI threat surface becomes one more dimension of the security posture your team already manages, rather than a new tool, a new vendor, and a new operational silo.
What generative AI security means for the next 12 months?
According to McKinsey’s State of AI survey (November 2025), 88% of organizations now use AI in at least one business function, up from 78% a year earlier. And in the 2026 Thales Data Threat Report, 61% of organizations named AI as their top data security risk, while the share carrying a dedicated AI security budget rose from 20% to 30%. As organizations move from simple chat experiences toward autonomous agents capable of taking actions, the need for AI-specific security controls becomes even more critical. The teams that get this right will not be the ones who deploy more security tools. They will be the ones who recognize that AI applications are a new class of asset and treat them with a control layer designed for what they actually are.
A WAF was the answer when applications moved from desktop to web. An API gateway was the answer when monoliths gave way to microservices. An AI Application Security layer is the answer for applications that no longer execute only predictable code, but interpret, generate, and increasingly act on language.
That is the new kind of security your AI deserves.
Frequently asked questions about generative AI security
What is the difference between AI security and generative AI security?
AI security is the broad category, covering everything from model theft to training-data poisoning. Generative AI security is the runtime subset: protecting live LLM and agentic applications from prompt injection, sensitive data disclosure, system prompt leakage, improper output handling and unbounded consumption.
Can a WAF stop prompt injection?
No. A WAF inspects HTTP headers, query strings and request bodies for known malicious patterns. A prompt injection payload is grammatically valid English inside a legitimate request, so it passes every WAF check. Stopping it requires inspection at the AI interaction layer, which is what an AI application security layer adds alongside the WAF.
Do I need to replace my existing security stack to secure AI?
No. AI application security extends the stack rather than replacing it. Imperva AI Application Security plugs into the same platform as the WAF, API security, bot management and DDoS protection, using the same console, policy model and role-based access controls.
Which OWASP LLM Top 10 risks does Imperva AI Application Security address?
Five of the ten out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling, and unbounded consumption.
Is generative AI security different for AI agents?
Yes. Agents take actions rather than only returning text, so a successful manipulation becomes an operational incident rather than a bad answer. See the companion post on agentic AI security below.
There is a question I have been hearing more and more from CISOs, compliance officers, and security architects over the past year. It does not start with “we had a breach” or “we failed an audit.” It starts with something that sounds almost philosophical:
“Are we quantum-safe?”
A year ago, that question came from the most forward-thinking 5% of our customer base. Today, it is coming from everyone. And that shift, from curiosity to urgency, tells you everything you need to know about where the security industry is headed.
Post-Quantum Cryptography is not a future problem anymore. It is a right now problem. And the customers asking us about it are not being paranoid. They are being smart.
What is post-quantum cryptography? Post-quantum cryptography (PQC) is a new generation of public-key algorithms designed to remain secure against attacks from both classical and large-scale quantum computers. Unlike RSA and elliptic-curve cryptography, which rely on math that a sufficiently powerful quantum computer can break, PQC algorithms are based on mathematical problems that are believed to be hard for quantum machines as well -protecting the data your organization encrypts today from being decrypted in the future.
The “Harvest Now, Decrypt Later” Threat Is Already in Motion
Let us be direct about the threat model, because it is one that does not get nearly enough attention in mainstream security conversations.
You do not need a quantum computer to exist today for your encrypted data to already be at risk.
Sophisticated nation-state adversaries are actively collecting encrypted TLS traffic right now, including your transactions, your authentication sessions, and your sensitive data in transit, with the explicit intention of decrypting it later once quantum computing reaches sufficient capability. This strategy has a name: “Harvest Now, Decrypt Later.” And it is not theoretical. It is happening.
The implication is sobering: the security decisions you make today about encryption determine the confidentiality of data that will still be sensitive in five, ten, or fifteen years. Healthcare records. Financial transactions. Government communications. Intellectual property. Any data with long-term value is already a target for harvesting.
Classical TLS, the encryption backbone of the modern internet, was not built to withstand quantum-scale attacks. The mathematical problems that make RSA and ECC hard to break today become tractable for sufficiently powerful quantum computers. When that threshold is crossed, the encryption protecting decades of harvested data becomes transparent.
This is not a hypothetical edge case. It is a strategic, long-horizon attack that demands a strategic, long-horizon defense.
Our Customers Are Already Asking. We Already Have the Answer.
Here is something I want to be transparent about, because I think it matters.
At Thales, we have been getting questions about PQC readiness from customers consistently and with increasing frequency. These are not fringe inquiries from academic researchers or early adopters chasing the next shiny thing. These are enterprise security teams, regulated industry customers in finance, healthcare, and defense, and compliance officers who are watching the regulatory horizon and doing the math.
They are thinking about it. And they deserve a vendor who is already ahead of it.
That is exactly why I am proud to share what we have built. Thales’ Imperva platform now supports hybrid TLS handshakes combining X25519 and MLKEM768, a pairing of classical elliptic curve cryptography with a quantum-safe Key Encapsulation Mechanism aligned directly with NIST PQC standards. This hybrid approach protects connections between clients and Imperva Points of Presence with both classical and quantum-safe algorithms running simultaneously, ensuring security regardless of which threat model materializes first.
And we did not just build the capability for customers. We completed the migration of all Imperva sites ourselves. We validated it in production before asking anyone else to trust it.
That is what proactive security looks like.
What Hybrid TLS Actually Looks Like in Practice
I know “hybrid TLS handshake” can sound abstract, so let me ground it in something concrete.
When a client connects to a Thales Imperva-protected application today, that TLS 1.3 session is authenticated using X25519MLKEM768, a combined algorithm that you can actually observe directly if you inspect the connection in Chrome’s security panel. You will see exactly what the screenshot above shows: “The connection to this site is encrypted and authenticated using TLS 1.3, X25519MLKEM768, and AES_128_GCM.”
That is not marketing language. That is your browser’s own security panel confirming quantum-safe encryption is active.
What this means practically:
A classical adversary cannot break the X25519 component
A quantum-capable adversary cannot break the MLKEM768 component
Both would need to be broken simultaneously, which represents an effectively impossible bar with current and near-future capabilities
The hybrid model is deliberate and important. Pure PQC algorithms, while mathematically quantum-resistant, are newer and have had significantly less real-world cryptanalysis time than their classical counterparts. The hybrid approach ensures we are not trading one risk for another. We are stacking defenses. This is defense-in-depth applied to cryptography itself.
Zero Performance Trade-off. No Traffic Impact. Full Protection.
Here is the objection I hear almost every time PQC comes up in a customer conversation: “That sounds computationally expensive. What does it do to latency?”
The answer, which genuinely surprises most people: nothing measurable.
Our PQC implementation introduces no performance trade-off and no traffic impact. This matters enormously because one of the most common reasons organizations delay critical security upgrades is the perceived performance cost. Security teams propose the upgrade. Engineering teams push back on latency. The initiative stalls.
With Thales’s PQC implementation, that objection is gone.
Quantum-safe encryption that slows your applications down is not a real solution. It is a compliance checkbox that creates new operational problems while solving a cryptographic one. We were not willing to ship that. The implementation delivers genuine quantum-safe security without the operational tax, and that is the only version of this capability worth deploying at enterprise scale.
The Compliance Horizon Is Closer Than You Think
If the threat model alone is not enough to create urgency in your organization, and for some organizations it is not, that is an honest reality, then the regulatory and compliance landscape should be.
Governments and standards bodies have moved decisively and fast:
NIST finalized its first PQC standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are no longer drafts. They are published standards.
The S. White House issued NSM-10 directing federal agencies to inventory cryptographic systems and prioritize PQC migration timelines
CNSA 2.0 mandates PQC adoption for national security systems with defined timelines
Financial services regulators in the EU and UK are actively publishing PQC readiness guidance for institutions
DORA and NIS2 in Europe are tightening cryptographic resilience requirements across critical infrastructure sectors
The direction is unambiguous. Regulated industries, including finance, defense, and healthcare, are going to face PQC compliance requirements. The organizations that begin migration now will meet those requirements ahead of schedule, with time to test, validate, and optimize. The ones that wait will be scrambling to meet deadlines under pressure.
Thales’s PQC support is directly aligned with enterprise and regulated sector expectations today. When your auditor, your regulator, or your enterprise customer asks whether your traffic is quantum-safe, the answer should already be yes.
This Is a Security Evolution, Not a Cryptographic Revolution
I want to address something directly, because the way PQC gets discussed in the media can make it sound like a complete overhaul that requires ripping out and replacing your entire security infrastructure overnight.
That framing is not helpful. And it is not accurate.
PQC is a security evolution. The underlying architecture of TLS, certificates, and encrypted communications does not change. The mathematical primitives powering key exchange and authentication do. For most organizations, particularly those working with a security partner like Imperva that has already done the migration work, the path forward is far more manageable than the “quantum apocalypse” narrative suggests.
The hybrid approach makes this especially true. You do not abandon classical cryptography overnight. You layer quantum-safe algorithms alongside proven ones, maintain backward compatibility where needed, and progressively increase quantum-safe coverage as the ecosystem matures and client-side support expands.
Supporting our customers to be PQC compliant at the start of the year was just one step in that evolution. It is a step we took proactively, before our customers needed to ask twice, because that is what it means to be a security partner rather than just a security vendor.
What You Should Do Right Now
If you are a CISO, a security architect, or a compliance officer reading this, here is where I would focus your energy:
Inventory your cryptographic exposure.
Understand which systems handle data with long-term sensitivity. Those are your highest-priority migration targets. Build cryptographic agility, the ability to swap algorithms without architectural overhaul, into your design principles going forward.
Ask your vendors the question.
“Are you quantum-safe?” is now a legitimate and necessary vendor evaluation criterion. Any security vendor without a PQC roadmap, let alone a GA capability in production, should be on notice.
Do not wait for regulatory mandates to force your hand.
The organizations that will navigate PQC transitions smoothly are the ones building the capability now. The ones scrambling to meet a 2027 or 2028 compliance deadline will pay for the delay in both cost and risk.
Understand why the hybrid model is the right posture.
Pure PQC is not the immediate goal for most enterprise environments. Hybrid classical plus quantum-safe is the right posture for 2026. Demand that from your vendors and your internal security teams.
Talk to Thales.
We have done this. Our sites are migrated, our customer sites are migrated. Our PoPs support hybrid TLS with MLKEM768 today. We can help you understand what your path looks like and what questions you should be asking across your vendor portfolio.
The Bottom Line
The harvest is already happening. The standards are finalized. The regulatory expectations are forming. And the technology to protect yourself, without performance trade-offs, without ripping out your stack, is available right now.
Our customers are asking about PQC readiness because they understand the stakes. They are thinking about long-horizon risk in a way that their boards and regulators are increasingly demanding. And they deserve a security partner who is not just thinking about it alongside them but has already built, tested, and deployed the answer.
Post-Quantum Cryptography is not a problem for the security teams of 2030. It is a problem for the security teams of today, being solved by the tools available today.
Thales is quantum-ready.
The question is: are you?
Thales Imperva’s Post-Quantum Cryptography support, hybrid TLS with X25519 plus MLKEM768 for Client to Imperva connections, reached General Availability at the start of 2026. To learn more about Imperva’s PQC readiness and what it means for your organization, contact us or explore our Cloud WAF capabilities.
Post-Quantum Cryptography FAQ
What is post-quantum cryptography (PQC)?
Post-quantum cryptography is a set of public-key algorithms designed to remain secure against attacks from large-scale quantum computers. It replaces or augments classical algorithms like RSA and elliptic-curve cryptography, whose underlying math a sufficiently powerful quantum computer could break.
What is a “harvest now, decrypt later” attack?
“Harvest now, decrypt later” is a strategy in which adversaries collect and store encrypted traffic today so they can decrypt it once quantum computers become powerful enough to break classical public-key cryptography. Any data that will still be sensitive in five to fifteen years—healthcare records, financial transactions, intellectual property—is already a target.
What is ML-KEM (FIPS 203)?
ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) is the NIST-standardized post-quantum key exchange specified in FIPS 203, published August 13, 2024. Imperva pairs ML-KEM-768 with the classical X25519 key exchange to form a hybrid TLS handshake—giving every connection both classical and quantum-safe protection.
Why pair a quantum-safe algorithm with a classical one (hybrid TLS)?
Pure PQC algorithms are mathematically quantum-resistant but have had far less real-world cryptanalysis than RSA or elliptic-curve cryptography. A hybrid handshake runs both classical and PQC key exchange together: an attacker would have to break both to compromise the session. It is defense-in-depth for cryptography itself, and it’s the recommended posture for 2026.
Is Imperva quantum-safe today?
Yes. Thales Imperva’s PQC support, hybrid TLS combining X25519 and ML-KEM-768 for client-to-Imperva connections, reached general availability at the start of 2026. All Imperva sites have already been migrated. For setup details and current handshake scenarios, see the Imperva PQC support documentation.
Login
