There is a moment every security analyst knows well. It’s 2am, an alert fires, and you’re staring at a console trying to make sense of what just happened—fast. You need context, scope, and impact: What’s being targeted? Where is it coming from? Is it getting worse? What should we do next?

That moment is exactly what we built the Imperva AI Assistant to improve, starting with Cloud WAF (cWAF) investigations, where speed and clarity matter most.

Security teams are under pressure to investigate threats faster, with fewer resources

Modern application security environments generate a constant stream of signals across events, trends, attack patterns, and security posture. But turning that data into meaningful insight still takes effort. Analysts often move between dashboards, filter logs, and stitch together context across multiple tools to understand what’s happening.

At the same time, teams are expected to do more with less. A persistent skills gap and increasing alert volume mean even routine investigations can take longer than they should, slowing response times and adding pressure to already stretched teams.

The industry’s traditional response has been more dashboards, more saved reports, and more training. We think there’s a better answer: let your team ask the question in plain English and get a structured, security-relevant answer back immediately, grounded in Imperva platform data.

Introducing the AI Assistant.

What is an AI security assistant?
An AI security assistant is a natural-language tool that lets security teams investigate threats by asking questions in plain English, instead of building queries or navigating dashboards, and returns fast, ranked, security-relevant answers grounded in their own platform data. The Imperva AI Assistant brings this capability directly into the Imperva platform, starting with Cloud WAF investigations.

Protect with AI: Making security work faster, simpler, and more accessible

To address this, we’re bringing the power of AI directly into Thales’s Imperva platform.

It builds on AI ExplAIn, the one-click, plain-language explanations we introduced for Imperva Cloud WAF, extending that same clarity from individual blocked requests to full, cross-product investigations.

Our goal is simple: help security teams get answers faster, reduce manual effort, and improve day-to-day productivity.

What the AI Assistant does?

The AI Assistant is designed around three key goals:

Increase productivity
Instead of navigating dashboards or writing complex queries, users can simply ask a question and get an answer immediately.

Make AppSec more accessible
You don’t need deep expertise in Thales or Cloud WAF. The assistant uses natural language, making it easier for more team members to investigate and understand security data.

Support a wide range of use cases
Security questions don’t follow a fixed script. Our assistant can handle a variety of queries, from investigations to trend analysis, without requiring predefined workflows.

Instead of being limited to predefined dashboards or reports, teams can explore questions as they arise, using plain language to surface insights that would be impractical to design into a traditional UI. Because the assistant can draw on signals across the Imperva AppSec platform, it doesn’t just retrieve data – it connects it.

For example, an analyst might ask: “Was the IP that triggered a WAF block also behaving like automated traffic in the same session, and what changed compared to previous activity?”, and get a clear, unified answer in seconds, without having to pivot across tools or manually stitch the data together.

Security investigations, simplified with an AI security assistant
The AI Assistant is a natural-language experience built into the Imperva platform to help security teams investigate faster.
Instead of navigating dashboards or building filters, teams can simply ask:

• “What are the top attack source IPs over the last 48 hours?”
• “Which URLs are most targeted right now?”
• “What types of attacks were blocked on site XYZ.com?”
• “What changed between yesterday’s baseline and today’s spike?”
• “Are these patterns concentrated in a single source or distributed across multiple locations?”

The assistant responds with a concise, ranked answer, along with a Critical Finding that highlights the security -relevant insight, not just raw data. The assistant can also access all Imperva documentation, so teams can ask “How do I configure…? Or “Where can I find…?” to easily find the information they need.

A real-world investigation, simplified.

Imagine a security analyst investigating a sudden spike in application traffic.

Today, that process often involves switching between dashboards, filtering logs, and piecing together data from multiple sources to understand what’s happening.

With the AI Assistant, the workflow is much simpler.

The analyst can ask:

• “What’s driving the spike in traffic today?”
• “Are these requests coming from the same source or multiple locations?”
• “What has changed compared to yesterday’s baseline?”

Within seconds, the assistant provides a clear, summarized answer, highlighting key trends, identifying the most relevant signals, and surfacing a Critical Finding that explains what matters. Instead of manually connecting the dots, the analyst can quickly understand the situation, prioritize next steps, and respond faster.

Why this matters for security teams

When investigating potential threats, teams need more than confirmation that “something triggered.” They need fast, clear answers that help them understand what’s happening and what to do next.

• What’s the pattern? (Is activity concentrated, distributed, or repeating?)
• What’s the scope? (Which applications, URLs, geographies, or time windows are affected?)
• What’s the severity? (How significant is the signal, and how quickly is it evolving?)
• What’s the next best action? (Where should they focus, and what should they mitigate?)

The AI Assistant is designed to answer these questions directly, reducing investigation friction and helping teams move from data to insight, faster.

In practice, this means security teams can move from alert to understanding faster—without adding complexity or changing existing workflows.

Easy to get started

The AI Assistant is built directly into the Imperva AppSec platform, there’s nothing new to install or manage.

It’s available through the Ask AI experience and works within your existing environment, using the same data, workflows, and permissions you already rely on.

Because it’s permission-aware by design, users only see the data they’re authorized to access.

AI capabilities are always optional, customers can choose whether to enable or disable them at any time, ensuring full control over how AI is used in their environment.

Available today

The AI Assistant is currently available under controlled availability for a select group of customers. This phase allows us to refine quality, guardrails, and workflows based on real-world feedback before broader rollout.

Why it matters

AI in security has been discussed for years, often focused on detection and tuning. But the real pressure point has always been the moment of investigation, when teams need to quickly understand what’s happening and decide what to do next.

That’s where the AI Assistant is different. It focuses on turning security data into clear, actionable insight – faster. It doesn’t replace expertise, but it makes effective investigation workflows easier to access across the team.

When fewer people are bottlenecks for interpreting signals, response times improve, escalations reduce, and teams spend less time on repetitive analysis.

The impact is simple: faster decisions, fewer handoffs, and more time spent on the issues that matter most.

The bottom line

Security investigations get faster when teams can turn security data into explanations they trust. The Imperva AI Assistant is designed to shorten the path from alert to decision, starting with Cloud WAF, by helping analysts quickly pull the right data, spot what’s changed, and decide what to do next.

It starts with a question, and an answer you can defend.

Frequently asked questions about the AI security assistant

What is an AI security assistant?
An AI security assistant is a natural-language interface that lets security teams ask questions in plain English and get fast, ranked, security-relevant answers drawn from their own platform data, instead of manually building queries or pivoting across dashboards. The Imperva AI Assistant delivers this inside the Imperva platform, starting with Cloud WAF investigations.

How is the Imperva AI Assistant different from AI ExplAIn?
AI ExplAIn gives one-click, plain-language explanations of individual blocked requests in Cloud WAF. The AI Assistant goes further, answering open-ended investigation and trend questions across the Imperva AppSec platform and connecting signals, such as a WAF block and automated-traffic activity, within the same session.

What questions can the AI Assistant answer?
Teams can ask investigative and trend questions such as “What are the top attack source IPs over the last 48 hours?” or “What changed between yesterday’s baseline and today’s spike?” Because it can also read the Imperva documentation, analysts can get configuration and “how do I…” answers in the same place.

Will an AI security assistant replace SOC analysts?
No. The AI Assistant is designed to speed up investigations, not replace expertise. It removes the manual work of pulling and correlating data so analysts can focus on judgment, prioritization, and response.

Is the data the AI Assistant sees kept private and under our control?
Yes. The assistant is permission-aware, so users only see data they are authorized to access, and AI capabilities are optional; customers can enable or disable them at any time.

Want to see it in action? Request a demo or ask your Thales team about the controlled availability process.

The post Your Security Operations Team Just Got Faster: Meet Imperva’s AI Assistant. appeared first on Blog.

Web applications and APIs now sit at the center of nearly every digital business, and the threat surface has grown in step. Independent industry analysis estimates that API traffic represents more than 70% of all web traffic, that API related security incidents have climbed to roughly one third of reported data breaches, and that more than a third of recent API breaches trace back to Broken Object Level Authorization (BOLA) flaws.

At the same time, the latest AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation found that average complete-security efficacy across the leading enterprise WAAP solutions declined year over year, even as operational efficiency improved slightly. The takeaway for security leaders is straightforward: WAAP capabilities are diverging across the market, and shortlist decisions made in 2022 or 2023 may no longer reflect current efficacy or operational fit.

This guide focuses on the major WAAP vendors that most frequently appear on enterprise shortlists. It draws on independent SecureIQLab testing, recent Forrester, Gartner, KuppingerCole, and IDC research, and verified peer reviews to help security and risk leaders evaluate platforms across modern, multi-cloud, API-heavy environments without reducing the decision to a generic ranked list.

1. Scope and methodology

This comparison focuses on the major WAAP vendors most commonly evaluated by enterprise buyers: Akamai, Cloudflare, F5, Fastly, Fortinet, and Radware, alongside Imperva. It uses three categories of independently sourced evidence:

• Certified independent testing: the 2025 SecureIQLab Cloud WAAP v4.0 CyberRisk Validation, conducted under AMTSO Test ID AMTSO-LS1-TP097, which evaluated 11 enterprise WAAP solutions across more than 1,360 attacks aligned to the OWASP Top 10, OWASP API Security Top 10 2023, MITRE ATT&CK, and the Lockheed Martin Cyber Kill Chain.
• Analyst recognition: the Forrester Wave for Web Application Firewall Solutions (Q1 2025), the Gartner Market Guide for Cloud Web Application and API Protection, the KuppingerCole 2025 Leadership Compass for WAAP, the IDC MarketScape for WAAP, and Gartner Peer Insights ratings as of the date of this article.
• Verified customer reviews: Gartner Peer Insights, PeerSpot, G2, and TrustRadius user ratings, used as a sentiment signal rather than as a ranking input.

Of the seven platforms covered here, four (Akamai, Cloudflare, Fortinet, and Imperva) completed the public SecureIQLab v4.0 cycle, while three of the competitors (F5, Fastly, and Radware) are listed in the SecureIQLab comparative report as “Contact SecureIQLab” rather than appearing with published v4.0 results. For those three vendors, the profiles below rely on Forrester, Gartner, and verified customer review sources, and head-to-head efficacy comparisons should be confirmed through buyer-led testing.

Other WAAP vendors (for example hyperscaler-native services and specialized API-security vendors) may be relevant for specific buyer needs, but they fall outside the major-vendor scope used here. Buyers should treat this guide as one input among several and validate every vendor claim against their own application portfolio during a proof of value.

2. What is WAAP?

Web Application and API Protection (WAAP) is a category defined by Gartner to describe cloud-delivered services that protect web applications and APIs against runtime attacks. Core capabilities typically include a Web Application Firewall (WAF), distributed denial-of-service (DDoS) protection, advanced bot management, API security, and increasingly client-side script protection.

In practical terms, a WAAP platform sits in front of an application (or a portfolio of applications and APIs) and inspects every request, blocking exploits aligned to the OWASP Top 10 and OWASP API Security Top 10, distinguishing legitimate users from automated abuse, absorbing volumetric and Layer 7 denial-of-service traffic, and providing the visibility security teams need to investigate and tune.

For a foundational explainer, see Imperva’s What is a WAAP? Learning Center article at imperva.com/learn/application-security/web-application-and-api-protection-waap/ (set as an internal link on publish).

3. Why WAAP matters now

Three forces are reshaping WAAP buying decisions in 2026:

• API growth is outpacing API security. Independent reporting indicates that API related breaches have moved from a niche concern to roughly a third of all data breaches, while only about one in five organizations rate themselves as highly capable of detecting attacks at the API layer.
• Bots and AI-enabled automation are escalating. Public industry data shows AI-enabled bot activity rising sharply year over year, with credential stuffing, scraping, and inventory hoarding increasingly difficult to separate from legitimate users without sophisticated behavioral analytics.
• Cloud-native deployment is the new default. As more workloads move inside hyperscale clouds, development teams increasingly prefer security that runs natively within the cloud environment rather than alongside it through external routing that can add latency and operational overhead.
• Regulatory pressure is compounding. Frameworks such as PCI DSS 4.0 (client-side protection requirements), DORA, NIS2, and sector-specific rules on operational resilience are pushing application security from a best practice into a documented control requirement.

For security leaders, the business outcomes a modern WAAP must support include reduced breach risk and downtime, faster time to protection for new applications and APIs, audit and compliance readiness, and predictable cost as application portfolios scale.

4. WAAP vendor comparison at a glance

Use the table below to narrow the vendor set based on architectural focus and primary deployment use case. Then validate efficacy, API coverage, bot defense, and operational fit through your own proof of value. The order is alphabetical, not a ranking.

Source: SecureIQLab 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0; Forrester Wave: Web Application Firewall Solutions, Q1 2025; Gartner Market Guide for Cloud WAAP; KuppingerCole 2025 Leadership Compass for WAAP. See references.

Independent analyst standing: Forrester Wave WAF Q1 2025

The Forrester Wave groups vendors into Leaders, Strong Performers, and Contenders, a single published designation that reflects the combined strength of each vendor’s current offering, strategy, and customer feedback. Rather than restate Forrester’s underlying sub-scores, the table below shows each covered vendor’s official tier, with a short note on what Forrester emphasized. This analyst recognition complements security-efficacy testing because it weighs roadmap, innovation, integrations, and customer feedback alongside current capabilities.

Source: Forrester Wave: Web Application Firewall Solutions, Q1 2025 (published tier designations and findings). Among the seven vendors covered here, three were named Leaders, three Strong Performers, and one a Contender.

A note on tier equivalence: within Forrester’s methodology, vendors positioned in the same tier hold equivalent standing in the evaluation. The three Leaders (Cloudflare, Akamai, and Imperva) are designated by Forrester as Leaders together; vendor-specific sub-criterion scores within the tier do not change the tier-level designation.

Verified peer feedback (G2)

Independent customer ratings on G2 are a useful third complement to certified testing and analyst evaluation, because they reflect the day-to-day operational experience of paying customers. The table below shows the current G2 standing for each covered vendor’s flagship WAF product profile. Review-base sizes vary widely across vendors, so the rating is best read alongside the volume of reviews supporting it; vendors that have not actively claimed and managed their G2 product profile may show smaller review bases and older reviews.

Source: G2 verified user reviews (most recent rating snapshots at time of writing). G2 product profiles do not always cover a vendor’s full WAAP suite, and review bases vary widely; the table compares each vendor’s flagship WAF product profile. See references.

5. Key criteria to evaluate when comparing WAAP solutions

The framework below combines the SecureIQLab v4.0 evaluation model (security efficacy, operational efficiency, Secure by Design and Secure by Default ratings, false positive avoidance) with capability themes emphasized by Gartner and Forrester.

6. Five buyer questions to guide WAAP evaluation

Use these five questions as a lightweight evaluation framework. Each maps to one or more of the capability themes above.

1. How well does the platform stop the threats my applications actually face?

Look beyond generic OWASP coverage claims. Ask for AMTSO-certified third-party test results, and verify both web (OWASP Top 10) and API (OWASP API Security Top 10 2023) efficacy. In the latest SecureIQLab v4.0 testing, complete-security results spanned an extremely wide range, from near-complete coverage at the top to less than half of attacks blocked at the bottom, so the spread within a single shortlist can be very large.

2. How deep is the API protection, across all my protocols?

APIs are no longer just REST. SecureIQLab v4.0 testing measured coverage separately across REST, GraphQL, SOAP, WebSockets, and gRPC, and found that coverage varied widely by protocol even within a single vendor, with WebSockets generally the weakest area across the group. Confirm vendor coverage protocol by protocol, not just by headline API score.

3. How effective is bot defense against modern automation and AI-enabled abuse?

Ask vendors how they detect headless browsers, residential proxy traffic, and AI-driven scraping, and how those decisions are made without harming legitimate traffic. In the SecureIQLab bot suite, only a small number of the tested vendors blocked every attack type, so perfect bot defense is a genuine differentiator rather than a baseline.

4. How quickly can my team get to a tuned, low false-positive state?

Operational efficiency and false positive avoidance are tightly linked. In the latest cycle, the strongest vendors avoided essentially all false positives, while the weakest let through enough to translate into meaningfully more alerts per day and substantially more tuning effort for security operations teams. A few points of difference here can mean a very different daily workload.

5. How does the deployment and licensing model align with how my portfolio is growing?

Native in-cloud deployment, edge delivery, and traditional reverse-proxy models produce very different latency, resilience, and onboarding profiles, and per-request, per-Mbps, and per-application licensing produce very different cost curves as traffic scales. Walk through a 24 to 36 month projection with each shortlisted vendor, ideally informed by your own traffic baseline.

7. WAAP Vendor profiles

Each vendor profile below uses the same schema: a neutral summary, a list of capabilities verified from public documentation and independent sources, and a “Consider when” statement. Profiles are presented alphabetically. Capabilities should be re-validated against your specific environment during a proof of value.

Akamai — App & API Protector

Current market status: Publicly traded (NASDAQ: AKAM). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.

Summary

Akamai delivers WAAP from one of the world’s largest edge networks, combining WAF, DDoS, bot management, API security, and client-side controls in its App & API Protector product. In SecureIQLab v4.0, the tested cloud-based deployment was among the strongest in the group on both complete security and operational efficiency, comfortably above the group averages, and avoided essentially all false positives. In the Forrester Wave Q1 2025, Akamai was named a Leader, strong on both current offering and strategy, with reference customers citing strong detection and automation; Forrester noted that Akamai lags in DevOps and scanning integrations and that some prospects weigh its pricing carefully.

Key capabilities

• Edge-delivered WAAP integrated with Akamai’s global CDN and DDoS scrubbing capacity.
• Behavioral bot detection that blocked every attack type in the SecureIQLab v4.0 bot suite.
• API discovery and schema-aware protection for REST and modern protocols.
• Layer 7 DDoS coverage with a perfect result in SecureIQLab v4.0 Layer 7 DoS testing.
• Integration with Akamai’s broader Zero Trust and AI security portfolio.

Consider when

Consider Akamai when your organization needs edge-delivered protection at very large scale, has significant CDN and DDoS requirements alongside WAAP, and wants a vendor with an established global footprint and analyst-recognized leadership.

Cloudflare — Cloudflare WAF (Application Security)

Current market status: Publicly traded (NYSE: NET). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, with the strongest current-offering position of any vendor evaluated. Placed in the Visionary category of the SecureIQLab 2025 Cloud WAAP v4.0 validation; rated Secure by Default.

Summary

Cloudflare delivers WAAP from a globally distributed programmable network, with strong developer experience, rapid feature velocity, and integrated DDoS, bot management, API gateway, and Page Shield (client-side protection). In SecureIQLab v4.0, Cloudflare’s complete-security result landed around the group average, but it blocked every bot and Layer 7 DoS attack type and avoided nearly all false positives; API coverage was uneven, with strength in SOAP and gRPC and notable weakness in REST and WebSockets in the tested configuration. In the Forrester Wave Q1 2025, Cloudflare was named a Leader and posted the strongest current offering of any vendor evaluated; Forrester credited an efficiency-focused feature set and noted that reference customers flagged customer support as an area to improve.

Key capabilities

• Cloud-native WAF integrated with Cloudflare’s CDN, DDoS scrubbing, and developer platform.
• Programmable security policies and edge workers for custom logic.
• Bot management that blocked every attack type in the SecureIQLab v4.0 bot suite.
• Page Shield client-side protection aligned to PCI DSS 4.0 requirements.
• Strong developer experience and rapid product release cadence.

Consider when

Consider Cloudflare when your organization values developer-led security, rapid time to deploy, and a unified edge platform across CDN, DDoS, and application protection. Plan to validate API coverage by protocol against your specific traffic mix during a proof of value.

F5 — Distributed Cloud WAAP

Current market status: Publicly traded (NASDAQ: FFIV). Named a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

F5 brings deep WAF heritage from BIG-IP Advanced WAF and a multi-acquisition portfolio (Volterra, Shape Security), assembled into the Distributed Cloud (XC) WAAP service. F5 is often shortlisted by organizations with significant existing F5 application delivery and security investments and a need to span data center, multi-cloud, and SaaS-delivered WAAP. In the Forrester Wave Q1 2025, F5 was named a Strong Performer, solid on both current offering and strategy; Forrester credited built-in web application scanning (via its Heyhack acquisition) and a strong API security story, while noting fewer security operations integrations and a steep learning curve cited by reference customers. Because F5 did not appear in the public SecureIQLab v4.0 dataset, comparative efficacy claims should be validated through buyer-led testing.

Key capabilities

• Distributed Cloud WAAP delivered as a SaaS layer across multi-cloud and edge.
• Behavioral bot defense lineage from Shape Security.
• API security including discovery and schema validation.
• Hybrid deployment alongside BIG-IP Advanced WAF appliances and virtual editions.
• Strong fit for hybrid enterprises with existing F5 footprints.

Consider when

Consider F5 when your environment already standardizes on F5 application delivery and security infrastructure, when hybrid (data center plus SaaS) WAAP is required, and when buyer-led testing can fill the absence of comparable public SecureIQLab v4.0 data.

Fastly — Next-Gen WAF

Current market status: Publicly traded (NYSE: FSLY). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025 (vision described by Forrester as developer- and business-focused). Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

Fastly’s WAF is built on the Signal Sciences engine and is closely integrated with Fastly’s programmable edge platform. The product appeals to developer-led organizations that want deep observability into request decisions, the ability to test rules before deployment, and tight CI/CD integration. The absence of Fastly from the SecureIQLab v4.0 public cycle means head-to-head efficacy comparison against the 11 tested vendors must come from internal testing.

Key capabilities

• Signal Sciences detection engine with detailed signal-based decisioning.
• WAF Simulator for testing rules prior to production deployment.
• Native integration with Fastly’s programmable CDN.
• API security features that have continued to expand in 2024 and 2025.
• Strong reported partner-style customer relationships.

Consider when

Consider Fastly when application security is closely coupled to a developer-first delivery culture, when observability and pre-deployment rule testing are priorities, and when the lack of public SecureIQLab v4.0 data can be supplemented by internal validation.

Fortinet — FortiWeb

Current market status: Publicly traded (NASDAQ: FTNT). Named a Contender in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.

Summary

FortiWeb is Fortinet’s WAAP, available as VM, AMI, container, and SaaS, and integrated with the broader Fortinet Security Fabric. The two independent sources frame Fortinet differently. In SecureIQLab v4.0, FortiWeb posted the strongest complete-security result among the tested platform vendors, with high operational efficiency and near-perfect false positive avoidance (its bot defense blocked three of the four attack types). In the Forrester Wave Q1 2025, Fortinet placed in the Contender tier, the only covered vendor below the Strong Performer band, with developing positions on both current offering and strategy. Forrester noted a roadmap less extensive than others in the evaluation, an absence of rule versioning, rule testing limited to logging mode, and limited compliance and performance reporting, while crediting strong API security capabilities and competitive pricing.

Key capabilities

• WAAP available as virtual machine, AMI, container, and SaaS.
• Integration with Fortinet Security Fabric (FortiGate, FortiAnalyzer, FortiSIEM).
• Machine learning models for traffic profiling and threat detection.
• API security capabilities including anomaly detection, PII labeling, and gRPC support (per Forrester).
• April 2024 Google Cloud Technology Partner of the Year award in application security.
• Strongest complete-security result among the SecureIQLab v4.0 tested platform vendors.

Consider when

Consider FortiWeb when your organization is standardized on the Fortinet Security Fabric, when integrated network and application security is a priority, and when a competitively priced option within a large security platform is the goal. Buyers prioritizing rule lifecycle management (versioning, safe rule testing outside logging mode) or breadth of strategy and roadmap should weigh the Forrester findings and validate these areas during a proof of value.

Imperva (part of Thales) — Web Application and API Protection

Current market status: Now part of Thales (acquired December 2023). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and the KuppingerCole 2025 Leadership Compass for WAAP. Placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation (the fourth consecutive cycle) and awarded the Secure by Default rating.

Summary

Imperva delivers a unified WAAP combining Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN under one platform, available as SaaS, on-premises, or deployed natively inside hyperscale clouds. In SecureIQLab v4.0, Imperva was among the strongest in the group on both complete security and operational efficiency, well above the group averages, and notably achieved perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance, a combination of high efficacy and full false-positive discipline that few vendors matched. In the Forrester Wave Q1 2025, Imperva was named a Leader, strong on strategy and solid on current offering. Forrester highlighted Imperva’s Layer 7 DDoS, its signing of the CISA Secure by Design Pledge, and a roadmap that integrates its application security offerings into a unified platform, while noting room to improve in out-of-the-box DevOps and scanning integrations and in some UI consistency.

Key capabilities

• Unified WAAP platform across SaaS, on-premises, and cloud-native deployment.
• Native in-cloud deployment for AWS, Microsoft Azure, and Google Cloud, with Imperva for Google Cloud (available on Google Cloud Marketplace) inspecting traffic inside the Google Cloud network via Service Extension and Private Service Connect, and onboarding without DNS, SSL, or routing changes.
• Advanced Bot Protection with behavioral analytics and fingerprinting; blocked every bot attack type in SecureIQLab v4.0 testing.
• API Security with discovery, schema-based protection, and BOLA detection; API protocol coverage well above the tested-group average.
• DDoS Protection with industry SLA commitments; perfect result in SecureIQLab v4.0 Layer 7 DoS testing.
• Client-Side Protection aligned to PCI DSS 4.0 magecart and script-protection requirements.
• Perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance in the SecureIQLab v4.0 cycle; Secure by Default rating per CISA-aligned criteria.

Consider when

Consider Imperva when your organization needs unified WAAP across multi-cloud and hybrid environments, when deep API security and bot defense are required alongside core WAF and DDoS, when low operational burden and very high false-positive avoidance are priorities, and when cloud-native deployment inside AWS, Azure, or Google Cloud is on the roadmap.

Radware — Cloud Application Protection Service

Current market status: Publicly traded (NASDAQ: RDWR). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

Radware’s Cloud Application Protection Service combines WAF, bot management, API protection, and DDoS, with continued investment in AI-driven detection and SOC automation tooling. Radware’s heritage in DDoS protection makes it a frequent shortlist option for organizations whose risk profile is heavily weighted to availability attacks. In the Forrester Wave Q1 2025, Radware was named a Strong Performer, strong on strategy and solid on current offering; Forrester credited its AI SOC Xpert tool and tunable detection models, while noting fewer out-of-the-box integrations and reference-customer feedback that reporting could be more flexible. Comparable SecureIQLab v4.0 data is not publicly available for this cycle.

Key capabilities

• Cloud Application Protection Service combining WAF, bots, API, and DDoS.
• Strong DDoS protection heritage.
• AI-assisted SOC tooling for application protection.
• Hybrid and cloud deployment options.
• Forrester recognition for detection models and pricing transparency in Q1 2025.

Consider when

Consider Radware when DDoS exposure is a primary driver, when AI-assisted SOC tooling is valued, and when the absence of public SecureIQLab v4.0 data can be addressed through internal testing.

8. Why Imperva stands out for unified, cloud-native WAAP

Imperva’s differentiation is grounded in four architectural realities that buyers can verify in their own environments and through independent testing.

• Unified WAAP rather than assembled WAAP. Imperva’s Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN are delivered as one platform rather than a portfolio of acquired and integrated products. The result is consistent policy, telemetry, and analytics across the entire application protection surface.
• Validated efficacy with very low operational burden. In the latest AMTSO-certified SecureIQLab v4.0 cycle, Imperva paired among the strongest complete-security and operational-efficiency results in the group with perfect 100% results in false positive avoidance, bot defense, and Layer 7 DoS. Few vendors in the tested set combined top-tier efficacy with that level of false-positive discipline.
• Deployment flexibility, including native cloud integration. Imperva can be deployed as SaaS, on-premises, or natively inside hyperscale clouds. Imperva for Google Cloud, available on Google Cloud Marketplace, inspects traffic inside the Google Cloud network using Service Extension and Private Service Connect, and onboards without DNS, SSL, or routing changes. This native, in-cloud direction extends across AWS, Azure, and Google Cloud, and reflects a broader roadmap of running enterprise-grade WAAP inside hyperscale infrastructure rather than alongside it through external routing.
• Aligned to CISA Secure by Design. Imperva earned the SecureIQLab Secure by Default rating in the same cycle, reflecting hardened defaults and the ability to protect newly deployed applications without extensive manual tuning.

No single platform is the right answer for every environment. Buyers whose dominant requirement is a single edge platform unifying CDN, application protection, and a developer-centric workflow, or whose primary driver is the deepest possible DDoS scrubbing capacity, will want to weigh those needs explicitly. The most reliable approach is to validate any shortlist, including Imperva, against your own threat model, traffic patterns, and cloud footprint during a proof of value.

9. How to choose the right WAAP platform

Choosing a WAAP platform should start with your operating reality, not the vendor list. The matrix below maps the most common dominant security gap to the WAAP capabilities buyers should prioritize during evaluation.

Proof-of-value checklist

• Validate independent efficacy scores against your own application portfolio and threat model.
• Test API protection across every protocol you actually use (not just REST).
• Measure tuning effort and false positive rates under real traffic for at least two weeks.
• Confirm Layer 7 DDoS and bot defenses against representative attack patterns and adversarial automation.
• Test the deployment model you intend to run in production, including native in-cloud deployment where relevant.
• Walk through licensing across a 24 to 36 month projection that includes anticipated traffic and portfolio growth.
• Verify SIEM, SOAR, identity, and developer-tool integrations against your existing stack.
• Review verified peer feedback (Gartner Peer Insights, PeerSpot, G2, TrustRadius) for unfiltered operational reality.

10. Frequently asked questions

What are the best WAAP solutions in 2026?

There is no single best WAAP for every organization; the right platform depends on your threat profile, API footprint, and cloud architecture. Among the major vendors most often shortlisted by enterprises, Akamai, Cloudflare, and Imperva were named Leaders in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, while Akamai, Fortinet, and Imperva placed in the Leader category of the AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation. In that cycle, Imperva combined among the strongest security efficacy in the group with perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance. Validate any shortlist against your own traffic during a proof of value.

What is the difference between a WAF and a WAAP?

A Web Application Firewall (WAF) inspects and filters HTTP traffic to block common web exploits such as those in the OWASP Top 10. Web Application and API Protection (WAAP) is the broader, cloud-delivered category defined by Gartner that pairs a WAF with additional runtime defenses, typically DDoS protection, advanced bot management, API security, and client-side script protection. In other words, the WAF is one component inside a modern WAAP platform.

Which major WAAP vendors were named Leaders in the most recent Forrester Wave for WAF Solutions?

In the Forrester Wave: Web Application Firewall Solutions, Q1 2025, which evaluated 10 providers across 22 criteria, the vendors covered in this guide were placed as follows: Akamai, Cloudflare, and Imperva were named Leaders; F5, Fastly, and Radware were named Strong Performers; and Fortinet was named a Contender.

Which of the vendors covered here completed the most recent SecureIQLab Cloud WAAP testing?

Of the seven platforms covered here, four completed the public SecureIQLab v4.0 cycle: Akamai, Cloudflare, Fortinet, and Imperva. Akamai, Fortinet, and Imperva were placed in the Leader category. F5, Fastly, and Radware are listed as Contact SecureIQLab in the comparative report and did not appear with published v4.0 results.

Why does API protocol coverage matter so much in 2026?

API traffic now accounts for more than 70% of all web traffic, and independent industry reporting links roughly a third of recent data breaches to APIs, with about 35% of API breaches tied to Broken Object Level Authorization (BOLA). Modern WAAPs need to cover REST, GraphQL, SOAP, WebSockets, and gRPC; independent testing has shown wide variance across protocols even within a single vendor’s product.

What does native cloud deployment add over traditional WAAP delivery?

Native in-cloud deployment lets a WAAP inspect traffic inside the cloud provider’s own network rather than routing it externally, which can reduce latency and operational overhead and avoid changes to DNS, SSL, or routing. Imperva for Google Cloud, for example, uses Google Cloud Service Extension and Private Service Connect to operate inside the Google Cloud network, and Imperva offers native deployment across AWS, Azure, and Google Cloud.

What independent WAAP testing standards should I trust?

Look for testing conducted under the Anti-Malware Testing Standards Organization (AMTSO) framework. The SecureIQLab Cloud WAAP v4.0 methodology used in this guide is AMTSO-certified (AMTSO-LS1-TP097). Pair it with analyst evaluations (Forrester, Gartner, KuppingerCole, IDC) and verified peer reviews.

How should I treat vendor-supplied competitive content during evaluation?

Treat vendor-produced competitive comparisons as marketing inputs rather than evidence. Anchor evaluation on AMTSO-certified independent testing, recent analyst reports, and verified peer reviews, and confirm specific claims through your own proof of value.

11. Choose your next step

Strong WAAP decisions combine three things: independent testing data, analyst guidance, and a proof of value run on your own traffic. As next steps, security leaders typically benefit from running a quick application portfolio baseline (top 20 apps and APIs by risk), executing an internal red-team exercise against current controls, and shortlisting two to three vendors for parallel proof of value testing across the dimensions outlined above.

To explore Imperva’s WAAP capabilities, including native deployment for AWS, Azure, and Google Cloud, or to request a technical evaluation, contact the Imperva team.

12. References and appendix

All claims in this guide are supported by independent third-party sources or by vendor public documentation for descriptive facts. The full reference list is below.

Independent testing

[1] SecureIQLab, 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0, AMTSO Test ID AMTSO-LS1-TP097, https://www.secureiqlab.com.

[2] SecureIQLab, 2025 Cloud WAAP CyberRisk Validation Reports (individual vendor reports, including Akamai, Cloudflare, Fortinet, and Imperva).

[3] Anti-Malware Testing Standards Organization (AMTSO), https://www.amtso.org.

Analyst recognition

[4] Forrester, The Forrester Wave: Web Application Firewall Solutions, Q1 2025 (Sandy Carielli, et al., March 20, 2025). Tier placements and composite scorecard scores cited here are from Figures 1 and 2 of the report.

[5] Gartner, Market Guide for Cloud Web Application and API Protection, most recent edition, https://www.gartner.com.

[6] Gartner Peer Insights, Cloud Web Application and API Protection market reviews, https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection.

[7] G2, Web Application Firewall (WAF) category, verified user reviews and product ratings, https://www.g2.com/categories/web-application-firewall-waf.

[8] KuppingerCole, Leadership Compass: Web Application and API Protection (WAAP), 2025.

[9] IDC, IDC MarketScape for Web Application and API Protection (WAAP).

Industry standards and frameworks

[10] OWASP Top 10 (2021), https://owasp.org/Top10/.

[11] OWASP API Security Top 10 (2023), https://owasp.org/API-Security/.

[12] MITRE ATT&CK Framework, https://attack.mitre.org.

[13] Lockheed Martin Cyber Kill Chain, https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html.

[14] CISA, Secure by Design Principles, https://www.cisa.gov/securebydesign.

[15] PCI Security Standards Council, PCI DSS v4.0, https://www.pcisecuritystandards.org.

Industry data sources

[16] SQ Magazine, API Security Breach Statistics 2026, https://sqmagazine.co.uk/api-security-breach-statistics/.

[17] TechRT, API Usage and Growth Statistics 2026, https://techrt.com/api-usage-and-growth-statistics/.

[18] Security Boulevard, 2026 API ThreatStats analysis, https://securityboulevard.com.

Vendor public documentation

[19] Akamai, App & API Protector product page, https://www.akamai.com.

[20] Cloudflare, Application Security product page, https://www.cloudflare.com.

[21] F5, Distributed Cloud WAAP product page, https://www.f5.com.

[22] Fastly, Next-Gen WAF product page, https://www.fastly.com.

[23] Fortinet, FortiWeb product page, https://www.fortinet.com.

[24] Imperva, Web Application and API Protection product page, https://www.imperva.com/products/application-security/.

[25] Imperva, Imperva for Google Cloud product page, https://www.imperva.com/products/imperva-for-google-cloud/.

[26] Imperva, Introducing Imperva for Google Cloud (company blog, 2026), https://www.imperva.com/blog/.

[27] Radware, Cloud Application Protection Service product page, https://www.radware.com.

The post Best WAAP Solutions for Enterprise Application Security: How to Choose the Right Platform in 2026 appeared first on Blog.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

The post The Clock Is Already Ticking: Why Post-Quantum Cryptography Can’t Wait appeared first on Blog.

Every security team knows the pain: a critical alert lands in someone’s inbox, buried under dozens of other emails, or filtered out by a spam rule. By the time anyone sees it, the incident is already in full swing—no ticket opened, no Slack message sent, no automated workflow triggered. The detection worked, but the notification system didn’t.

Why email was never enough

Email was always a compromise for security notifications. It’s universal, but that’s also its weakness:

• Emails get lost. Spam filters and crowded inboxes mean critical alerts are missed, not because Imperva didn’t send them, but because no one saw them in time.
• Emails can’t trigger automation. The ideal response to a DDoS attack isn’t a human reading an email and manually opening a ticket. It’s an automated workflow that opens the ticket, posts to Slack, pages the on-call engineer, and logs the incident, instantly.
• Emails are hard to parse. Extracting structured data from an email for downstream systems is brittle and error-prone

The stakes are high. Imperva research found that 44% of security professionals spend more than 20 hours a week responding to alerts, and 27% of IT professionals receive more than a million security alerts a day. When a critical notification is lost in that flood, response slows down—exactly when speed matters most.

The result? An operational gap between detection and response. That gap closes today.

Introducing Webhook-based notifications

What are webhook notifications? Webhook notifications are automated, real-time messages that a system sends to a URL you choose the moment an event occurs. Instead of waiting for someone to open an email, the event data—usually structured as JSON—is pushed straight to your tools, where it can instantly trigger tickets, alerts, and automated workflows.

Imperva now supports webhook notifications: real-time, structured alerts delivered directly to your systems and tools. You define webhook connections in the Imperva Platform, assign them to notification policies, and from then on, your alerts go exactly where you need them—instantly, in a format your automation can use.

No more spam filters. No more manual ticket creation. No more copy-pasting data at midnight.

Real-world webhook notification scenarios

• DDoS Attack Response: A DDoS event triggers your webhook, which fires a ServiceNow ticket, posts to Slack, and pages the on-call engineer—all before anyone touches a keyboard. When the attack stops, the workflow updates the ticket and notifies the team automatically.
• SSL Certificate Expiration: The expiration event posts directly to the right team’s Slack channel, so the responsible engineer sees it and acts before there’s an outage.
• DNS Configuration Required: A new site needs DNS setup. The webhook creates a task and notifies the infrastructure team, so work is queued before anyone checks the console.
• Bandwidth Overage Warning: Approaching your bandwidth limit? The webhook notifies your FinOps team and opens a ServiceNow ticket, so you can act before overage charges hit

*Note: Some notification types and integrations (like Slack/Teams) are coming soon or in beta. See documentation for current coverage.

Built the right way: Flexible, secure, reliable

Webhook notifications are designed for enterprise reliability:

• Backoff logic: If your endpoint isn’t reachable, Imperva retries delivery multiple times, so alerts aren’t lost to temporary outages.
• Authentication: You can add a secure code in the webhook header, making incoming notifications more trusted and secure for your environment.

The automation advantage

Webhook notifications aren’t just a new channel—they’re an automation unlock. Every alert becomes a programmable trigger: DDoS events, site configuration, bandwidth thresholds. Your automation stack gets a clean, reliable feed for every significant event, enabling faster, more consistent response. This is the foundation of SOC automation: every Imperva alert becomes a programmable trigger for faster, more consistent incident response.

When alerts arrive as structured events, action no longer depends on someone noticing an email. Notifications flow straight into tickets, incident channels, or automated workflows—so the right response happens immediately and consistently.

Deployment: How to set up webhook notifications

There’s nothing new to install. Webhook connections are configured directly in the Imperva platform under Accounts – Webhook Connection. You name the connection, define the endpoint URL, and assign it to the desired notification policy

Today, webhook notifications work alongside email—so you can run both channels in parallel and migrate at your own pace.

Frequently asked questions about webhook notifications

What are webhook notifications?

Webhook notifications are automated, real-time messages that Imperva sends to a URL you define the moment a security or operational event occurs. The event is delivered as structured data your tools can act on immediately—opening tickets, posting to chat channels, or triggering automated workflows—without anyone reading an email first.

How are webhook notifications more reliable than email security alerts?

Email alerts can be lost to spam filters or buried in crowded inboxes. Webhook notifications are delivered directly to your systems, with backoff logic that retries delivery if your endpoint is temporarily unreachable and optional authentication codes in the webhook header to verify each message. The result is fewer missed alerts and a structured payload your automation can parse reliably.

What security events can trigger an Imperva webhook?

Webhook notifications can fire on events such as a DDoS attack starting or stopping, an SSL certificate nearing expiration, a new site that needs DNS configuration, and bandwidth overage warnings. Each event is sent to the notification policy you assign it to. Some notification types and integrations are rolling out over time, so check the Imperva documentation for current coverage.

Can I use webhook and email notifications at the same time?

Yes. Webhook notifications run alongside email, so you can keep both channels active and migrate to webhooks at your own pace. Many teams keep email as a backup while webhooks become the primary channel for automated response.

How do I set up webhook notifications in Imperva?

There is nothing new to install. In the Imperva Platform, go to Accounts – Webhook Connection, name the connection, define the endpoint URL, and assign it to the notification policy you want. For step-by-step instructions and current event coverage, see the Imperva webhook documentation.

The Bottom line

Webhook notifications mean fewer missed alerts, faster automation, and less manual work. Email becomes your backup, not your primary channel. At this stage access to webhook notifications is currently limited, get in touch to find out more.

Your security workflows just got an upgrade.

Contact your Imperva account team to find out more.

The post Real-Time Webhook Notifications: No More Lost Security Alerts appeared first on Blog.

AI agents are not a future concern. They are already changing how enterprise systems are accessed, automated, and abused.

And the security implication is clear: the more autonomous systems rely on APIs, the more important it becomes to know exactly which APIs exist, how they are being used, and whether they are being misused.

If your organization cannot answer those questions, you have a visibility problem. And in an environment where AI can accelerate both legitimate automation and malicious abuse, visibility is the first step to control.

Risk accelerating

APIs have always been a target because they expose data and business logic. What has changed is pace.

AI can now help attackers discover endpoints faster, test more abuse paths, and automate attacks that once took much more effort. Meanwhile, AI agents inside the enterprise are generating more API traffic, often with broader privileges than anyone intended.

That means security teams are facing a harder problem: not just more traffic, but more uncertainty and adversaries with improved tools.

What CISOs should be worried about

The biggest risks are not always the loudest ones.

Whether it’s an over-permissioned agent, a forgotten or shadow API, or a “legitimate” request abused to enumerate data or chain unauthorized actions, the risk is real. It’s often compounded by API tokens with broad access and long expiration times.

These are the kinds of issues that can lead to evasive data exfiltration, unauthorized payments, compliance violations, and operational surprises that go undetected far too long.

If your API security program cannot spot abnormal behavior early, the business is exposed.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

What good looks like

CISOs need a practical model, not more noise.

That model should:

• Continuously discover APIs across the environment.
• Classify which ones are sensitive.
• Establish baselines for normal behavior.
• Detect abnormal or suspicious API activity.
• Support least-privilege access for AI agents.
• Help revoke risky permissions quickly.

This is how security leaders turn AI agent activity from a blind spot into something measurable and governable.

The board conversation has changed

This is no longer just a technical issue for engineering or operations.

Boards care about risk, control, and business impact. They need to know how many AI agent-facing APIs are being monitored, how many anomalous calls have been detected, and how quickly the business can respond when something looks wrong.

That is the real opportunity for CISOs: to move API security into the center of the AI risk conversation.

Download the guide now

For CISOs, security leaders, and executives, this guide explains the new API security realities emerging with AI agents. We created A CISO’s Guide to API Security in the Age of AI Agents to help you navigate the shift with clarity and confidence.

Inside, you will learn:

• Why AI agents are increasing API risk rather than replacing it.
• How to connect API security to business and board-level concerns.
• What to look for in a practical CISO playbook for discovery, visibility, and control.
• How to govern agent-driven access before it becomes business exposure.

AI agents may change how work gets done. But the organizations that understand their APIs first will be the ones best positioned to stay in control.

Download the CISO guide now

The post Why AI Agents Make API Security a CISO Priority appeared first on Blog.

A five-level operating model for turning API security visibility into measurable risk reduction, faster remediation, and confident digital growth — without slowing development.

What is API security operationalization?

API security operationalization is the process of converting API discovery and visibility into continuous, measurable risk reduction across discovery, vulnerability identification, prioritization, mitigation, and scaling. It moves API security from a one-time assessment to a repeatable, outcome-driven program, with KPIs such as mean time to remediation (MTTR), high-risk API count, and exposed endpoint reduction.

Operationalization matters because APIs are the fastest-growing attack surface — and most organizations now have visibility into their APIs but cannot act on it consistently. Without operationalization, discovery becomes a catalog instead of a control.

 Why most API security programs stall after discovery

Most organizations aren’t struggling to see their APIs anymore. They’re struggling to turn API security visibility into consistent, measurable outcomes. According to the OWASP API Security Top 10, the most damaging API risks — broken object-level authorization (BOLA), broken authentication, and unrestricted resource consumption — all exploit gaps that exist after discovery, not before it.

APIs are the fastest growing attack surface — Imperva research shows API-directed attacks now account for a meaningful share of the application threat landscape (see the 2025 Imperva Bad Bot Report for current bot-driven API abuse data). Yet many security programs stall after discovery: risks are identified but not prioritized. Findings are reported but not operationalized. Controls exist, but don’t scale.

Imperva API Security closes that gap.

It enables organizations to move beyond insight and into action, so API security becomes a repeatable, outcome-driven capability that reduces real risk, improves efficiency, and supports faster innovation.

Here’s how to operationalize it for impact.

Figure 1: The Imperva API Security operational maturity model — five levels from Discover to Optimize. 

Level 1: API discovery and classification

Building a complete, continuously updated inventory of every API

API discovery is the continuous process of identifying every API endpoint — managed, unmanaged, shadow, and deprecated — across cloud, on-premises, and hybrid environments, then classifying each one by data sensitivity and business criticality.

You can’t secure what you don’t fully understand, and classifying APIs by data sensitivity helps reduce the scope to a more manageable set. In dynamic environments, APIs are constantly changing, new ones spin up, old ones linger, and many remain undocumented.

Operationalization starts with continuous, accurate discovery and classification:

• Identify every API across cloud, on-premises, and hybrid environments — including REST, GraphQL, gRPC, and SOAP endpoints
• Uncover shadow APIs, unmanaged endpoints, and deprecated/zombie APIs that bypass change-management controls
• Classify APIs by data sensitivity (PII, PHI, PCI, financial), business criticality, and external exposure
• Map authentication posture — which endpoints require auth, which use long-lived tokens, which are publicly accessible without auth

How Imperva delivers:

Imperva API Security provides deep, continuous visibility into your API ecosystem, helping you uncover hidden APIs and automatically build a risk-aware inventory. This gives you not just a list of APIs, but the context needed to act on them.

Outcome: Reduced API attack surface, an inventory you trust, and the foundation every later level depends on. Without trustworthy discovery, prioritization is guesswork.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

Level 2: Identifying API vulnerabilities and business-logic abuse

Expose real-world risk, not just theoretical issues

Modern API attacks don’t rely on obvious exploits. They leverage legitimate access in unintended ways — abusing business logic, over-permissioned tokens, and weak authorization. The OWASP API Security Top 10 ranks broken object-level authorization (BOLA) as the #1 API risk: an authenticated user manipulates an object identifier (user ID, account ID, document ID) to access another user’s data the API never intended to expose. Unlike SQL injection, BOLA produces no malformed payloads — every request looks legitimate.

To operationalize security, you need to detect:

• Broken object-level authorization (BOLA, OWASP API1:2023) and access-control gaps that grant cross-tenant data access
• Broken authentication (OWASP API2:2023) — weak tokens, credential stuffing, missing MFA on sensitive flows
• Unrestricted resource consumption (OWASP API4:2023) — missing rate limits, no quota enforcement
• Excessive data exposure (OWASP API3:2023) — endpoints returning more fields than the client needs
• Anomalous usage patterns and behavioral risks (account-takeover, scraping, slow-rate enumeration)
• Business-logic abuse — checkout, refund, and gift-card workflows weaponized by legitimate-looking calls
• Risky tokens — long-lived credentials, over-permissioned API keys, leaked secrets in client code

How Imperva delivers:

Imperva analyzes API traffic and behavior to surface context-rich risk signals, so you can see not just what’s vulnerable, but how it can be exploited in practice.

Outcome: Shift from static findings to actionable intelligence aligned with real attack paths.

Level 3: Risk-based API prioritization (cutting through alert noise)

Focus on what actually matters to the business

Not all API risks are equal and treating them that way slows teams down.

Operational maturity comes from risk-based prioritization:

• Which APIs are business-critical? — handle revenue-generating workflows, customer authentication, or core data
• Which expose sensitive data? — return PII, PHI, payment data, or trade secrets
• Which are externally accessible? — reachable from the public internet, partner networks, or third-party integrations
• What is the real-world impact if exploited? — regulatory penalty, customer trust loss, downtime cost, blast radius

How Imperva delivers:

Imperva brings together visibility, behavioral insight, and business context to help teams focus on the highest-impact risks first, cutting through noise and enabling faster, smarter decisions.

Outcome: Align security effort with business risk, not alert volume.

Level 4: API risk mitigation and measurable outcomes (KPIs that matter)

Turn insight into action, and prove it’s working

Security only delivers value when risk is actively reduced, and that reduction is measurable.

Mitigation should be paired with clear KPIs:

• High-risk API count — number of APIs flagged as critical-severity, month over month (direct measure of attack-surface reduction)
• Mean time to remediate (MTTR) — days from detection of an API risk to closure (proxy for security engineering velocity)
• Exposed/unmanaged endpoint count — public APIs without owner, doc, or auth control (catches drift between deploys)
• Protection coverage — % of high-risk APIs with active mitigation policies (shows control density across the surface)
• Inline-action rate — % of detected abuse stopped at session level (vs. IP block); differentiator vs. coarse-grained tools

How Imperva delivers:

Imperva enables teams to detect and respond to malicious or risky API activity with precision, using inline actions at the client session level to stop abuse in real time, far more effective than coarse IP-based blocking. This turns API security into a measurable, outcome-driven function.

Outcome: Demonstrate real risk reduction and tangible ROI.

Level 5: Scaling API security through automation and DevOps integration

Embed API security into how your business operates

Manual processes don’t scale in modern API environments. Optimization is about making API security continuous, automated, and integrated.

This means:

• Automating API discovery and risk assessment so every new endpoint is inventoried within minutes of deployment
• Embedding API security into CI/CD pipelines — schema validation, OWASP-scoped tests, and policy-as-code at PR time
• Integrating with the broader stack — SIEM, SOAR, ticketing, IAM, and the Imperva Web Application and API Protection (WAAP) platform
• Repeatable remediation playbooks mapped to API risk class (BOLA, broken auth, excessive data exposure, business-logic abuse)

How Imperva delivers:

Imperva helps operationalize API security at scale, reducing manual effort while improving consistency and coverage. It enables security teams to keep pace with development without becoming a bottleneck.

Outcome: Scale protection without scaling complexity.

The right + left operating model: balancing protection and enablement

Sustainable API security is not just about stronger controls. It’s about balance.

• Right (Protection): Visibility, detection, and enforcement to reduce risk
• Left (Enablement): Automation, scalability, and efficiency to support speed

Too much focus on protection slows the business. Too much focus on speed increases exposure.

Imperva API Security brings both together.

Right + Left = Optimum—where security doesn’t compete with the business; it accelerates it.

Figure 2: Building a Sustainable Strategy – Right + Left = Optimum

Conclusion: Make API Security a Business Enabler

The difference between having API security and operationalizing it is the difference between insight and impact.

With Imperva API Security, organizations can:

• Continuously discover and understand their API landscape
• Identify and contextualize real-world risks
• Prioritize based on business impact
• Mitigate and measure outcomes
• Scale security through automation and integration

The result is not just better security.

It’s faster innovation, stronger resilience, and confident digital growth.

If your API security program is stuck at visibility, it’s time to take the next step.

Operationalize it. Measure it. Scale it.

See how Imperva API Security can help you turn API security into a strategic advantage,

and start driving real business value from day one.

Want to see how Imperva API Security can be operationalized at scale? Watch the detailed expert webinar for practical guidance and real-world insights. 

Frequently asked questions about API security operationalization

What’s the difference between API security and API security operationalization?
API security is the set of controls that protect APIs from abuse. API security operationalization is the practice of running those controls as a continuous, measurable program — with discovery, prioritization, KPIs, and automation rather than one-time scans.

What are the most common API vulnerabilities?
The OWASP API Security Top 10 (2023 edition) ranks broken object-level authorization (BOLA), broken authentication, broken object-property-level authorization, unrestricted resource consumption, and broken function-level authorization as the highest-impact API risks. Most modern attacks combine two or more of these.

How is API discovery different from API documentation?
API documentation describes what an API is supposed to do. API discovery finds every API that actually exists in your environment — including shadow, deprecated, and undocumented endpoints that documentation misses. Operationalized programs treat discovery as continuous, not one-time.

How do you measure API security effectiveness?
Track high-risk API count, mean time to remediate (MTTR), exposed/unmanaged endpoint count, protection coverage, and inline-action rate. KPI movement over time is the proof that the program — not just the toolset — is working.

Does Imperva API Security work with my existing WAF or WAAP?
Yes. Imperva API Security is part of the Imperva Web Application and API Protection (WAAP) platform and integrates with Imperva WAF, the Imperva CDN, and third-party SIEM/SOAR tooling. The same operational model spans web app and API protection.

→ Explore the Imperva API Security platform: https://www.imperva.com/products/api-security/ 

The post API Security Operations: How to Move from Visibility to Measurable Risk Reduction appeared first on Blog.

For decades, companies have operated on a simple assumption that most internet traffic came from people. That assumption no longer holds.

The latest 2026 Bad Bot Report: Bad Bots in the Agentic Age reinforces a shift that is now impossible to ignore. Automated traffic continues to outpace human activity online, accounting for more than 53% of all web traffic in 2025, up from 51% the year before. Human activity has declined to just 47% and continues to fall.

This is not a short-term spike driven by a specific attack cycle or technology trend. It reflects a structural change in how the internet operates. Increasingly, businesses are not serving customers alone. They are serving machines.

Key Findings From the 2026 Bad Bot Report

• Bots now drive 53% of web traffic. Automated activity has officially overtaken humans online, up from 51% in 2024.
• 27% of bot attacks target APIs. Attackers are bypassing user interfaces entirely to operate directly at machine speed.
• Financial services bear the brunt. The sector accounted for 24% of all bot attacks and 46% of account takeover incidents.
• AI agents are a new category of internet participant. They no longer just scan websites; they retrieve data, execute workflows, and act on behalf of users.

AI Agents and Bots Are Becoming the Default Internet User

Automation has always existed on the internet in the form of search engine crawlers, scripts, and background processes. What has changed is the scale, sophistication, and purpose of that automation.

AI is accelerating this shift. AI-driven bots have surged dramatically, but more importantly, AI agents are now emerging as a new category of internet participant. These systems don’t just scan websites; they interact with them, retrieve data, execute workflows, and increasingly act on behalf of users.

In practice, this means that what looks like a customer interaction may not be a customer at all. It may be an AI system querying pricing data, completing a transaction, or testing application behavior. For businesses, this blurs a fundamental line. The distinction between legitimate and malicious traffic is becoming harder to define, because both now operate through the same systems, use the same interfaces, and follow the same logic.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

The Rise of Uncontrolled Automation

The real risk is not the presence of bots, but that much of this automation is unmanaged. In earlier phases of the internet, bot activity was episodic and often easier to identify. Today, automation is persistent. It operates continuously across digital services, often indistinguishable from legitimate use. This creates a new category of risk that many organizations are not yet equipped to handle. Uncontrolled automation can distort business metrics, inflate infrastructure costs, degrade performance, and expose sensitive workflows.

For example, bots can continuously query pricing or availability systems, creating artificial demand signals. They can interact with promotional systems at scale, exploiting business logic in ways that traditional security controls are not designed to detect. Even benign automation, when left unmanaged, can place sustained load on systems that were designed for human behavior.

The result is that companies are increasingly sharing their digital infrastructure with automated agents that they neither fully understand nor control.

APIs and Identity Systems Sit at the Center of Modern Risk

As automation evolves, so do attacker strategies. The traditional model of targeting websites at the surface level is giving way to a more direct approach.

Bots are increasingly interacting with the same APIs that power core business functions, including authentication, payments, search, and inventory systems. In 2025, 27% of bot attacks targeted API endpoints, allowing attackers to bypass user interfaces entirely and operate at machine speed. These interactions often appear legitimate, with well-formed requests and successful authentication, but the difference lies in intent and scale.

This is particularly visible in sectors where digital transactions are tightly linked to revenue. Financial services, for example, accounted for 24% of all bot attacks and 46% of account takeover incidents. The goal is not disruption for its own sake, but direct monetization.

In this environment, identity systems are no longer just a security layer. They are a primary point of exposure.

How AI Agents Are Quietly Rewriting Business Models

The shift toward machine-driven interaction is not only a security issue. It is beginning to reshape how businesses operate.

If a growing share of traffic is automated, then traditional metrics such as user engagement, conversion rates, and demand signals become harder to interpret. A spike in traffic may not indicate customer interest. A drop in performance may not be caused by user behavior.

At the same time, AI-driven systems are creating new forms of demand. Companies are beginning to consider how and whether to allow AI agents to access their services, and under what conditions. This raises questions about access control, pricing, and even monetization.

Some organizations are exploring models where AI-driven access is authenticated, measured, and potentially governed as a distinct channel. While still early, this points to a future in which businesses must actively manage not just who accesses their systems, but what.

From Bot Detection to Automation Control

For years, cybersecurity strategies have focused on detecting and blocking malicious activity. That approach is increasingly insufficient in a world where automation is both pervasive and often legitimate. The more important question is no longer whether traffic is automated, but whether it aligns with business intent.

This shift, from blocking bad bots to governing all automation based on intent, requires a new approach. Organizations must move from viewing bots as anomalies to viewing automation as a fundamental part of their operating environment. That means implementing controls that can distinguish between acceptable and harmful automation, applying governance to how systems are accessed, and designing defenses that can adapt as behavior changes.

In effect, the challenge is becoming one of control rather than detection.

A Machine-Driven Internet

The internet is entering a new phase that’s defined less by human interaction and more by machine-to-machine activity. Automation is no longer a layer on top of digital infrastructure but embedded within it, with significant implications for businesses. Trust, performance, and revenue are increasingly shaped by how well organizations manage automated interaction.

Companies that continue to operate under the assumption that users are human risk misreading their own systems. Those that adapt by understanding, governing, and controlling automation will be better positioned to compete in an internet where machines are not just participants, but the majority.

The shift is already underway. The question for businesses is not whether it will happen, but how they will respond.

Download the Full 2026 Bad Bot Report

Get the complete data, sector breakdowns, and defense recommendations in Imperva’s 2026 Bad Bot Report: Bad Bots in the Agentic Age.

Frequently Asked Questions

What is the Imperva Bad Bot Report?

The Imperva Bad Bot Report is an annual industry research report analyzing global automated bot traffic, attack trends, and the impact of malicious bots on websites, APIs, and applications. The 2026 edition focuses on the rise of AI agents and agentic automation.

How much of internet traffic is bots in 2025?

According to Imperva’s 2026 Bad Bot Report, automated bot traffic accounted for more than 53% of all web traffic in 2025, up from 51% the year before. Human traffic has fallen to 47% and continues to decline.

Why are AI agents a cybersecurity concern?

AI agents act on behalf of users, retrieving data, executing workflows, and completing transactions through the same interfaces as humans. This blurs the line between legitimate and malicious traffic, makes traditional bot detection insufficient, and exposes APIs and identity systems to automation that organizations cannot easily distinguish from real users.

Which industries are most affected by bot attacks?

Financial services experience the highest impact, accounting for 24% of all bot attacks and 46% of account takeover incidents in 2025. APIs are the dominant attack surface, with 27% of bot attacks targeting API endpoints across all industries.

The post Bad Bot Report 2026: The Internet Is No Longer Human and It’s Changing How Business Works appeared first on Blog.

When evaluating cloud security platforms, one question comes up again and again:

“How many Points of Presence do you have?”

At first glance, the logic seems sound. More locations should mean lower latency, faster response times, and better protection. The assumption is simple: if security is delivered at the edge, then more edge locations must automatically translate into stronger application security.

That assumption, however, is largely inherited from the content delivery world — and it does not hold up when applied to real‑time application and API protection.

The Common Assumption: More PoPs Means Better Security

In content delivery networks (CDNs), PoP count is a meaningful metric. Static content benefits directly from being cached as close as possible to end users. The more locations you have, the more likely content can be served locally, reducing latency and improving page load times.

Application security operates under a very different set of constraints.

Web Application and API Protection (WAAP) platforms are not simply delivering content. They must inspect every request, enforce security policies, analyze behavior, detect abuse, and mitigate attacks in real time — all while maintaining visibility across global traffic flows.

In this context, proximity alone is not the primary driver of security effectiveness.

Not All PoPs Are Created Equal

A Point of Presence is a physical location where traffic is processed — but PoPs vary widely in capability.

Some platforms emphasize deploying a very large number of small, highly distributed PoPs optimized for caching and proximity. Others prioritize fewer, high‑capacity PoPs placed at major internet exchange points and backbone hubs.

These high‑connectivity locations sit directly on global networks, allowing traffic to reach them efficiently from broad geographic regions. In practice, users are often only a few milliseconds away from a well‑connected PoP, even if it is not located in the same city or country.

For security workloads, network connectivity, inspection depth, and capacity matter far more than raw geographic density.

Anycast Routing Changes the Equation

Modern security platforms rely on Anycast routing, which automatically directs traffic to the optimal PoP based on real‑time network conditions rather than simple physical distance.

With Anycast routing:

• Traffic follows the most efficient network path
• Performance remains consistent even during outages
• Failover happens automatically without user intervention

A well‑architected Anycast network can deliver predictable performance and resilience without requiring a PoP in every location where users reside.

Security Is Not the Same as Content Delivery

The most important distinction to understand is this:

CDNs scale by distributing copies of static content.
Security platforms scale by performing stateful inspection and coordinated decision‑making on live traffic.

Security inspection is computationally intensive and context‑dependent. Every request must be evaluated against behavioral models, threat intelligence, and policy logic. This work is fundamentally different from serving cached files.

As PoP counts increase, security platforms must make architectural trade‑offs around:

• How much inspection can be performed locally
• How much capacity is available per location
• How security intelligence is synchronized globally
• How attacks spanning regions are detected and mitigated

These trade‑offs define security outcomes far more than the number of locations alone.

What “Security in Every PoP” Really Means

Some modern platforms advertise that they run security services in every PoP, enabling them to deliver cached content and secure application traffic in the same location.

This approach offers clear advantages for latency‑sensitive use cases and environments where performance and security must be tightly coupled at the edge.

However, delivering security everywhere requires security capabilities to be highly distributed and lightweight by design. As PoP counts grow into the hundreds or thousands, platforms must balance:

• Inspection depth versus per‑location footprint
• Local decision‑making versus global coordination
• Uniformity of protection versus operational complexity

In practice, “security in every PoP” often prioritizes speed and proximity over inspection depth, per‑location capacity, and attack absorption strength. While this model performs well under normal traffic conditions, it does not inherently guarantee stronger protection during large, sustained, or highly coordinated attacks.

Concentrated Capacity vs. Distributed Presence

Highly distributed security architectures excel at minimizing latency and handling everyday traffic efficiently.

Security‑first architectures, by contrast, are designed to concentrate capacity, intelligence, and mitigation power at strategically connected locations.

This concentration enables:

• Immediate absorption of large volumetric attacks without traffic redirection
• Deep, stateful inspection even under extreme load
• Faster detection of coordinated attack patterns
• Predictable performance during worst‑case scenarios

For application and API security, the most critical moments are not normal operations, but peak attack conditions. It is during these moments that per‑PoP capacity and global visibility matter more than sheer geographic density.

When PoP Density Does Matter

PoP count does play an important role in specific scenarios:

• Global delivery of static content
• Ultra‑low‑latency applications such as gaming or live streaming
• Environments heavily reliant on edge caching

Many enterprises address this by separating concerns — using one platform optimized for content delivery and another purpose‑built for inline application and API security.

Architecture Over Optics

PoP count makes for an impressive slide, but it does not tell the full story.

The true measure of an application security platform lies in its network design, routing intelligence, inspection depth, per‑location capacity, and ability to perform under attack — not in how many dots appear on a map.

Some platforms optimize for being everywhere.
Others optimize for being strong where it matters most.

PoP count measures proximity.
Security performance measures resilience.

In application security, architecture — not optics — determines outcomes.

The post Why PoP Count Isn’t the Real Measure of Application Security Performance appeared first on Blog.

In today’s dynamic digital environment, the pressure to innovate has never been greater. Development teams are pushing for native cloud tools to maximize performance and cost-efficiency, while security teams require best-of-breed, enterprise-grade protection to defend against an ever-evolving threat landscape. This often creates a point of friction, forcing organizations into a difficult trade-off: sacrifice performance for security, or accept weaker protections for the sake of speed.

To resolve this challenge, Thales Imperva is collaborating with Google Cloud to deliver a solution that helps bridge this gap. We are proud to introduce Imperva for Google Cloud (IGC), an integrated security solution that offers the best of both worlds: enterprise-grade application security with the cloud-native performance you expect from Google Cloud.

Imperva for Google Cloud: A Holistic, Integrated Solution

Imperva for Google Cloud is not just another security layer; it is a fully managed, best-in-class Web Application and API Protection (WAAP) solution built directly into the fabric of Google Cloud. This integration, available now on Google Cloud Marketplace,   provides robust protection without disrupting your existing infrastructure or workflows.

• Cloud-Native Performance Without Compromise: Imperva for Google Cloud uses Google Cloud’s native Service Extension and Private Service Connect to inspect traffic within the Google Cloud network. This means all traffic analysis happens without your data ever leaving Google Cloud infrastructure, preserving optimal latency, performance, and data residency.
• Quick Deployment: Forget complex re-architecture. Imperva for Google Cloud can be deployed quickly using familiar tools like Terraform, Google Cloud CLI (gCloud CLI), or the Google Cloud console UI. There are no disruptive DNS, SSL, or network routing changes required, allowing you to achieve production-ready protection almost immediately.
• Enterprise-Grade Protection Out of the Box: Imperva for Google Cloud is powered by Imperva’s industry-leading security engine, delivering comprehensive WAF, advanced API Security, and Account Bot Protection. Backed by 24/7 threat research, the Imperva solution provides near-zero false positives, with 97% of customers successfully using default policies and 95% running in blocking mode from day one. This dramatically reduces the operational overhead of constant rule tuning.

Real-World Impact: Securely Accelerating Your Business

By eliminating the trade-offs between security and performance, Imperva for Google Cloud helps organizations achieve key business outcomes:

• Accelerate Lift-and-Shift Migrations: Migrate workloads to Google Cloud confidently with security that adapts to your applications, not the other way around. Eliminate migration delays caused by complex security re-architecture.
• Unleash DevOps-Friendly Security: Empower development teams to innovate at speed. IGC closes the security gaps in built-in tools without slowing down deployment velocity or requiring developers to become security experts.
• Protect Modern Cloud-Native Applications: Secure your Kubernetes and microservices architectures with best-in-class defenses optimized for low-latency environments.
• Achieve Unified Multi-Cloud Governance: Manage security for all your Imperva-protected environments from a single, unified dashboard, providing consistent policy management and visibility across your entire multi-cloud estate.

“Bringing Thales Imperva to Google Cloud Marketplace will help customers quickly deploy, manage, and grow the company’s integrated security solution on Google Cloud’s trusted, global infrastructure,” said Dai Vu, Managing Director, Marketplace & ISV GTM Programs at Google Cloud. “Thales can now securely scale and support organizations that want to use its Imperva for Google Cloud solution to increase protection for their cloud-native applications, APIs, microservices and more.”

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot report

Register Now

Join Us on the Journey to More Seamless Cloud Security

As we approach key industry events like our exclusive Executive Briefing Center (EBC) meeting in late March and Google Cloud Next 2026 in April, the conversation around integrated  security has never been more relevant. The launch of Imperva for Google Cloud marks a pivotal moment in our relationship with Google, providing a clear path for customers to secure their digital assets without compromise.

Ready to secure your cloud-native applications?

• Request a demo: Experience IGC in action at Imperva for Google Cloud
• Start your evaluation: Available now on Google Cloud Marketplace

The post Enterprise-Grade Application Security, Cloud-Native Speed: Introducing Imperva for Google Cloud appeared first on Blog.

AI-driven automation is no longer emerging. It is already integrated and accepted as internet traffic. From AI assistants and crawlers to enterprise automation tools, websites are now routinely accessed by non-human actors operating at scale.  Vulnerabilities or weaknesses in your application infrastructure, including risky APIs, are no longer difficult to find, as agentic AI tools, paired with automation, can observe and test endpoints and access points faster than any human.

AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic generated by AI agents, LLM-powered assistants, and autonomous tools — then applies granular policies based on each bot’s identity, intent, and behavior.

Key Takeaways:

• AI-powered bots now represent a significant and growing share of internet traffic, blending seamlessly into legitimate user sessions.
• Traditional bot detection cannot reliably distinguish between beneficial AI assistants and malicious AI-driven agents.
• Unmanaged AI bots create measurable business risks: analytics distortion, inventory manipulation, API abuse, account takeover, and content scraping.
• Imperva Advanced Bot Protection provides granular visibility and control over AI-driven traffic by tool type, category, behavior, and business function.
• Effective AI bot management in 2026 requires multilayered detection with real-time, policy-based response capabilities.

The challenge for security teams is no longer understanding why automation is increasing, but gaining clear visibility and control over what that automation is doing.

The result is a growing grey zone where distinguishing among human users, legitimate AI agents, and malicious bots becomes significantly more challenging, and where traditional security controls often lack the visibility needed to reliably distinguish among them.

According to Imperva’s 2025 Bad Bot Report, bad bots accounted for 32% of all internet traffic — a 2% increase year-over-year. With AI-powered tools accelerating automation, this figure is expected to grow significantly in 2026, making bot detection and bot management a critical priority for every organization.

How Do AI Bots Blend Into Legitimate Web Traffic?

AI agents and automated tools are improving how people interact with the internet, dramatically enhancing productivity and convenience. For example:

• AI assistants like ChatGPT, Perplexity AI, and Google Gemini retrieve real-time answers from multiple websites to summarise content or compare products
• Travel platforms continuously check flight prices, seat availability, and hotel inventory
• E-commerce monitoring tools track pricing, stock levels, and competitor offers across retailers
• AI-powered shopping assistants help users find deals or complete purchases faster
• Enterprise AI tools query SaaS platforms and APIs to automate workflows like reporting, customer support, and data enrichment
• Search and indexing bots extract and index web content to power AI-driven search experiences

However, the same technological advancements that enable these positive experiences are also empowering cybercriminals. Automation at scale lowers the barrier for malicious activity, putting malicious bots at a significant advantage when automated traffic is the expected baseline. They can blend seamlessly into legitimate traffic patterns, making detection significantly more challenging.

What Are the Business Risks of Unmanaged AI Bot Traffic?

Many organizations still view bot protection as optional. However, with AI agents such as crawler bots and fetch bots, now an accepted part of internet traffic and automation accelerating at scale, bot protection has become a core security requirement. Failing to treat it as such exposes organizations to serious business risks:

How Does Imperva Deliver AI Bot Detection and Control?

The ability to control which parts of your application functionality are accessible to AI tools is critical to your AI Security Strategy.

How Does Imperva Provide Visibility Into AI Bot Traffic?

Imperva Advanced Bot Protection (ABP) offers granular visibility into AI tools, agents, and crawlers, providing a detailed, real-time view of which AI tools are accessing your websites, applications, and API endpoints.

With ABP, security teams can clearly see which AI tools are hitting their environment, which applications and URLs are being accessed, the volume and frequency of requests, and whether those requests are being allowed, blocked, or challenged

This level of visibility ensures organizations know exactly what is interacting with their digital services and helps identify unintended policy outcomes, such as blocking AI tools they want to allow, or allowing tools they should restrict.

The AI Tools dashboard provides a centralized view of AI-driven traffic, enabling faster investigation and more informed decision-making.

How Can You Control AI Bots by Tool Type, Category, and Behavior?

Beyond visibility, Imperva enables precise control over how AI tools interact with your applications.

With ABP, security teams can easily:

• Allow, block, or rate-limit specific AI tools
• Apply policies based on categories such as AI crawlers, AI agents, and AI fetch bots
• Quickly adapt policies as new AI tools emerge

This allows organizations to move from reactive blocking to intentional control of automated access.

How Does Imperva Protect Critical Business Functions from AI Bots?

Imperva ABP also provides granular control at the application and business function levels, allowing organizations to define exactly which parts of their applications AI tools are allowed to access. This ensures that:

• Approved tools can only reach intended endpoints
• Sensitive paths, APIs, or business logic remain protected
• Access policies align with business and data governance requirements

This ensures AI tools interact with applications in a controlled, predictable, and secure way.

Why Is Imperva ABP a Leading Bot Management Solution?

ABP protection against AI builds on an already strong foundation of Advanced Bot Protection, combining multilayered detection, intelligent risk scoring, and real-time controls to accurately distinguish between human, legitimate automation, and malicious bots. With deep visibility, rapid decisioning, and expert support, ABP is already a proven solution for managing sophisticated bot threats. It is now further strengthened by the ability to monitor and control AI-driven traffic precisely.

Frequently Asked Questions About AI Bot Protection

Q: What is AI-aware bot protection?

A: AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic from AI agents, LLM-powered assistants, and autonomous tools. Unlike traditional bot detection that relies on static signatures, AI-aware protection uses behavioral analysis and AI tool fingerprinting to distinguish between beneficial AI assistants, legitimate automation, and malicious bots.

Q: What is the difference between traditional bot detection and AI-aware bot management?

A: Traditional bot detection identifies bots using predefined signatures and rules, treating most automated traffic as either good or bad. AI-aware bot management goes further by classifying AI tools by type, category, and behavior — enabling organizations to allow helpful AI agents while blocking or rate-limiting harmful ones with granular policies.

Q: How do AI agents bypass conventional bot defenses?

A: AI agents can mimic human browsing behavior, rotate IP addresses, solve CAPTCHA, and generate realistic session patterns. Because they operate as legitimate AI tools (such as AI assistants and search crawlers), they often pass through conventional defenses that only look for known malicious signatures.

Q: What business risks do AI bots create?

A: Unmanaged AI bots can distort marketing analytics, hoard inventory, abuse API business logic, perform credential stuffing for account takeover, scrape proprietary data and competitive intelligence, and degrade customer experience through increased site latency.

Q: Can businesses allow some AI bots while blocking others?

A: Yes. Solutions like Imperva Advanced Bot Protection enable granular control, allowing organizations to allow specific AI tools (such as approved search crawlers), rate-limit others (such as AI assistants accessing content), and block malicious AI agents — all at the individual tool, category, or endpoint level.

Q: What is agentic AI, and why does it matter for application security?

A: Agentic AI refers to autonomous AI systems that can independently browse the web, interact with APIs, and complete multi-step tasks without human oversight. These agents can probe for vulnerabilities, test endpoints, and access business functions faster than any human, making agentic AI security a critical concern for organizations.

Monitor, Control, and Prevent AI-Driven Bot Threats

Automation is now a permanent and growing part of how the internet operates. The critical challenge is no longer detecting bots alone but understanding and controlling AI-driven interactions at scale.

Organizations need to know exactly which AI tools are accessing their environments, what they are doing, and how to control that access with precision.

Imperva Advanced Bot Protection delivers the visibility, control, and adaptive protection required to operate securely in this new environment.

By enabling organizations to monitor AI agents, control their access at a granular level, and prevent malicious automation from hiding within legitimate traffic, Imperva helps businesses confidently embrace the future of AI-driven digital experiences.

Learn how Imperva Advanced Bot Protection delivers AI-aware bot management for your applications. Explore our bot protection solutions or download the latest Imperva Bad Bot Report for the most current data on AI-driven bot threats.

The post Why AI Bot Protection and Control Are Essential for Application Security appeared first on Blog.

For years, a lot of risky APIs survived simply because they were hard to find. They weren’t documented. Only a handful of engineers knew the endpoints. And if an attacker wanted to abuse them, they had to spend real time reverse‑engineering traffic and guessing how things worked.

That “security by obscurity” was never a security strategy, but it did create friction.

AI removes that friction.

Today, coding assistants and agentic tools can observe patterns in traffic, infer undocumented endpoints, generate proof‑of‑concept exploits, and test thousands of permutations faster than any human. We’ve already seen what happens when exposed APIs meet automation at scale: a hobbyist was able to gain control of thousands of robot vacuums due to exposed APIs and an over‑privileged token, something that simply wouldn’t have scaled without automation on the attacker side.

The takeaway is straightforward: if you don’t know where your APIs are, what they expose, and who can talk to them, AI will find those gaps for you, either in the hands of your developers or your attackers.

Why has API security become critical in the age of AI agents?

API security is the foundation of protecting applications against automated, AI-driven threats. In the past, attackers relied on manual reverse-engineering to discover undocumented API endpoints. Today, AI agents and coding assistants can autonomously map traffic patterns, infer hidden endpoints, and test thousands of exploit permutations in seconds. Furthermore, AI agents can bypass traditional web application firewalls (WAFs) by executing perfectly formatted, syntactically correct requests that abuse business logic—such as chaining legitimate calls to perform a Broken Object Level Authorization (BOLA) attack.

Because AI agents use APIs as their primary control plane, securing these interfaces is no longer just about preventing data breaches; it is about establishing the necessary guardrails to ensure AI tools operate safely and within their intended scope.

How AI Agents Change the Threat Model

AI doesn’t just make attackers faster. It changes what “attack” looks like, because agents can behave like normal users while still doing abnormal things.

1) Business Logic is the New Frontline

Traditional API protections – gateways, WAFs, basic input validation, are good at stopping obviously bad traffic: missing tokens, malformed payloads, suspicious content types.

But agents don’t have to look suspicious. They can follow every syntactic rule and still abuse your business logic.

Imagine an agent that:

• Uses a valid user token and calmly walks the edges of a pricing API until it discovers discount combinations you never intended to allow.
• Chains perfectly legitimate calls to pivot from one customer data to another customer’s data. This effectively executes a Broken Object Level Authorization (BOLA) attack – a critical vulnerability highlighted in the OWASP API Security Top 10 – without brute‑forcing raw IDs.

Nothing in those requests’ screams “attack.” The danger is in the sequence, the intent, and the scale, the exact things many baseline controls don’t reason about.

2) Agent-Specific Protocols Expand the Attack Surface

Agents aren’t only calling the same APIs as your mobile app calls. They’re increasingly using agent‑first toolchains and protocols that wrap platforms behind “tool” interfaces, making discovery and invocation easier than ever.

Look at what’s happening across major SaaS ecosystems: new CLIs and frameworks are designed so an agent can discover capabilities, understand schemas, and call dozens of APIs through a single control surface. Under the hood it’s still JSON over HTTP but packaged in protocols and workflows many security tools don’t meaningfully parse or recognize.

If your security stack doesn’t understand what it’s looking at, it can’t apply real policy. It just sees “some JSON” and hopes for the best.

The Thales Vision: API Security as the AI Agents’ Control Plane

At Thales, we see API Security evolving into the control plane for AI agents: the place where you get a coherent view of what agents are doing, which APIs they’re touching, and how to govern that behavior, consistently and at scale.

1) Start with ruthless visibility

You can’t protect what you can’t see, and AI moves too fast for spreadsheets and tribal knowledge.

We’re focused on:

• Finding every API: Discovering shadow, zombie, and newly created APIs across clouds and data centers, then mapping the data they expose and the business functions they support.
• Making agent traffic visible: Identifying traffic that comes from agents and agent toolchains, tying it back to the human or system they’re acting for, and surfacing suspicious patterns early.

The goal: when your CISO asks, “Which agents can touch customer PII today?” you can answer with confidence instead of guesswork.

2) Speak the same language as AI agents

We’re extending the API Security engine, so it doesn’t just see “JSON over HTTP ” but understands the agent protocols layered on top, things like MCP (Model Context Protocol) style streams and backend API calls from an agent-oriented CLI.

Once we can parse and normalize that traffic, we can:

• Apply the same validation and anomaly detection we already use for REST and GraphQL.
• Correlate what an agent is doing across back‑end services, rather than treating every request as an isolated event.

In practice, that means the security brain becomes protocol‑aware. Whether an action comes from a mobile app, a browser, or an AI agent using a modern toolchain, the same set of eyes is watching.

3) Put real guardrails around tokens and delegation

Agents run on delegation. They act on behalf of users and services using tokens, keys, and temporary credentials. When those credentials are over‑privileged or long‑lived, you get “quiet catastrophe” scenarios, like a single token shared among thousands of agents.

We’re building on our existing token visibility to:

• Score token risk: Evaluate scope, lifetime, usage patterns, and anomalies like sudden geography changes or volume spikes.
• Create policies specifically for agent delegation: For example, “This support agent’s token can only read billing data for the current customer, up to N requests per hour, and never export full datasets.”
• Catch replay and abuse: Detect when tokens are cloned, reused from odd locations, or used by unexpected agent identities.

If an AI agent starts stretching beyond the intent of its access, querying too broadly, too often, or in the wrong context, the platform should be able to flag, throttle, or cut it off in real time.

4) Defend the messy middle: business logic and BOLA

Agents follow natural‑language prompts, not carefully designed UI flows. That makes them unusually good at stumbling into the “negative space” of your application: edge paths nobody documented, but your back end still accepts.

Our approach anchors security in behavior and intent:

• Model sequences of calls as workflows and look for patterns that don’t match real user behavior, for example, moving from one customer account to another without a corresponding permission to change.
• Treat BOLA as more than “did you increment an ID,” and start reasoning about what resource the agent is effectively asking for when it requests “all internal reports” or “all projects in the system.”

The endgame is business‑level guardrails you can express clearly, and enforce across all agents, regardless of how clever the prompts are.

Meeting you where you already are

None of this works if it requires an exotic, parallel deployment just for AI. That’s why we’re embedding agent controls into the places customers already rely on Imperva today:

• Imperva Cloud WAF for internet-facing API
• Imperva WAF Gateway for on-prem and hybrid environment
• Imperva eWAF for cloud-native and microservices workloads

In each case, it’s the same security engine doing heavy lifting, discovering APIs, understanding protocols, analyzing behavior, and enforcing policy inline on every agent’s call.

Where we’re heading

AI agents are already inside organizations, helping engineers, answering customers, and automating operations. The real question is whether they’re operating inside guardrails you actually understand.

Our view is simple:

• You don’t secure AI by bolting something onto the model.
• You secure AI by controlling the APIs and data the model can reach.

By turning API Security into the shared control plane for AI agents, across discovery, protocol understanding, token governance, and business‑logic protection, we want to help teams say “yes” to AI without crossing their fingers behind their back.

If you can see every agent, every call, and every token, you can turn AI from a wild card into an engineered advantage. That’s the future we’re building toward.

The post API Security for AI Agents: Why Protection Has Never Been More Important. appeared first on Blog.

Application development has changed dramatically. Enterprises now release software faster, operate more digital services, and deploy applications across a mix of public cloud, private cloud, APIs, containers, and on-premises infrastructure.

As application delivery has accelerated and architectures have become more distributed, a disconnect has emerged between the teams building applications and those responsible for protecting them.

This tension is often described as the Wall of Confusion between DevOps and IT Security.

But the challenge does not stop there.

Over time, organizations have also introduced multiple security tools to protect different parts of the application stack. Each tool is managed separately, often by different teams, through different platforms, policies, and workflows.

The result is an additional layer of complexity. Security teams must navigate multiple vendors and fragmented controls, while DevOps teams experience delays as security becomes harder to integrate into fast-moving development cycles.

Understanding how to break down both the organizational and operational layers of this confusion is essential for organizations that want to maintain innovation while ensuring consistent, scalable security.

Applications Now Run Across Hybrid Environments

Today, around forty percent of enterprise applications run in the public cloud, and that number is expected to rise significantly to 62% over the next two years.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

Yet the shift to cloud does not mean applications live in one place. Most organizations now operate across hybrid and multi-cloud environments where applications run across public cloud platforms, private cloud infrastructure, on-premises systems, Kubernetes clusters, and an expanding network of APIs.

Cloud-agnostic strategies are also becoming more common as organizations seek flexibility and avoid dependence on a single provider. At the same time, many enterprises continue to operate legacy systems alongside modern cloud-native services.

The result is a highly distributed application landscape. Applications now run across multiple environments simultaneously, and security must be able to protect them wherever they operate.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

DevOps and Security Want the Same Outcome

Despite the perception of conflict, DevOps and IT Security teams are largely aligned on the goals of modern application security. Both groups ultimately want the same outcome: applications that are secure, reliable, and able to scale with business demand.

Research conducted with Vanson Bourne reinforces this alignment. 96% of DevOps and 95% of IT Security professionals agree that modern environments require security that is flexible across any architecture.

This global study of 1,500 professionals across the US, Europe, and APAC highlights an important point. Modern application security is not just a technology problem. It is a workflow and collaboration challenge.

Security and DevOps want the same outcome, but they experience different frustrations. These gaps can create delays, bottlenecks, false positives, and friction that undermine the cloud-native innovation organizations are working to achieve.

The Wall of Confusion: Conflicting Priorities, Fragmented Security and Tool Sprawl

The Wall of Confusion is not just about DevOps and Security working in silos. It is also about how security is delivered. Over time, organizations have added more and more security tools. One for web applications, another for APIs, another for cloud, another for containers. Each tool solves a specific problem, but together they create complexity instead of clarity.

Security teams are left navigating multiple vendors, switching between management platforms, and maintaining different policies across environments. This makes it difficult to keep controls aligned and increases operational overhead.

At the same time, gaps begin to appear. As applications move across environments, it is not always clear if they are fully protected. Policies become inconsistent because what is set in one environment does not automatically apply to another.

In fact, based on a 2026 survey of Imperva Application Security customers, 77% of security professionals say operational complexity is their biggest challenge.

For DevOps teams, this complexity shows up as delay. Security becomes a bottleneck not because it is unnecessary, but because it is too difficult to operationalize.

That is the wall and it is what needs to come down.

Why Traditional Security Models Fall Short

When applications operate across multiple environments, security approaches designed for fixed infrastructure quickly become difficult to manage.

Many organizations rely on a mixture of embedded protections, centralized security services, and environment-specific tools to protect different parts of their application landscape. While each solution may address a particular need, together they can create fragmented security architectures. This fragmentation leads to inconsistent policies, duplicated alerts, limited visibility, and increased manual effort.

Security teams must manage multiple tools and workflows, while development teams experience delays when security is applied inconsistently or too late in the process. Both teams are constrained by the same underlying issue: security models that were not designed for modern, distributed application environments.

Security Must Move with the Application

Modern applications are no longer tied to a single infrastructure model. They are composed of microservices and APIs, deployed through automated pipelines, and distributed across multiple environments.

Security therefore cannot remain a centralized checkpoint that appears late in the development process. Instead, protection needs to move with the application and operate consistently wherever that application runs.

This means security controls must function across public cloud environments, private infrastructure, hybrid deployments, Kubernetes clusters, APIs, and the traditional systems that many organizations still rely on.

DevOps and IT Security teams increasingly recognize this shift. They are not asking for less security. They are asking for security that works the way modern applications work.

Securing Applications Anywhere with Thales

As application architectures continue to evolve, organizations are no longer dealing with a single security challenge, but with the need to protect applications consistently across every environment they operate in.

The issue is not just distribution. It is how to secure that distribution without adding more tools, more complexity, or more operational overhead.

Security strategies built around isolated environments or disconnected tools are no longer sufficient. What is needed is a unified approach that delivers consistent protection, visibility, and control across the entire application landscape.

Now, the question becomes how to deliver that in practice.

Many vendors talk about flexibility but still require organizations to choose a single deployment model or manage multiple disconnected solutions. Imperva takes a fundamentally different approach. It meets organizations where they are, supporting multiple deployment models while maintaining a single, unified security experience.

This includes protection for internet-facing applications and APIs through Imperva Cloud, native integration for public cloud environments (Imperva for Google Cloud), container-based deployment for Kubernetes and microservices, and gateway deployment for on-premises, hybrid, and air-gapped environments.

The key is that all of these deployment options are powered by the same Imperva Security Engine.

This means one management console, consistent policies across every environment, and unified visibility across the entire application portfolio, regardless of where applications are deployed. Security teams do not need to manage multiple tools or vendors, and DevOps teams do not need to change how they build and deploy applications.

That is what securing applications anywhere really means.

Download the whitepaper: DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery

The post Securing Applications Anywhere: Breaking Down the Wall of Confusion appeared first on Blog.

Most organisations assume DDoS (Distributed denial of service) protection is a box they’ve already ticked. If traffic spikes or an attack starts, the thinking goes, their provider will absorb it and move on.

But in the real world it can be a different story. Many incidents aren’t caused by the scale of an attack alone, they happen because their protection isn’t designed to act fast enough, distinguish legitimate traffic or stay active without disruption for normal traffic. Or slows the legitimate traffic down, degrading performance when under an attack.

In this blog, we look at why DDoS resilience is really about continuity, not just mitigation, and what teams often miss when they assume they’re already protected.

The DDoS Protection Gap: Why Performance Breaks Under Pressure.

Modern DDoS attacks rarely look like blunt floods now; they utilize multi-vector strategies targeting the application layer (Layer 7) to blend in. They overwhelm specific application paths or quietly degrade performance until frustrated users give up.

In 2025, Imperva Threat Research team observed an application-layer DDoS attack that peaked at 15 million requests per second against a financial services API, a clear sign that attackers now combine scale with stealth tactics.

When protection isn’t built to handle this kind of attack, organisations often see:

• Delays between detection and mitigation
• Legitimate users are blocked or challenged during peak moments
• Performance degradation that’s dismissed as ‘normal slowing’
• Downtime that occurs despite having DDoS controls in place

The result is widespread impact, disrupting not just infrastructure, but revenue, brand reputation and most importantly, trust.

Why Modern DDoS Protection is a Business Continuity Challenge

Effective  DDoS protection isn’t about surviving the largest possible attack on paper. It’s about ensuring users can continue to access applications, complete transactions and rely on important services, even when an attack is ongoing.

To do that organisations need protection that is:

• Not dependent on manual activation
• Fast, with mitigation measured in seconds, not minutes or hours
• Accurate, so legitimate users aren’t caught in the crossfire
• Edge-based mitigation using a global Anycast network, stopping attacks before they put internal systems under pressure

Without these characteristics, DDoS defences can become part of the problem rather than the solution.

The Oversight: What Security Teams Miss About Resilience

Many organisations unknowingly accept risk because they:

• Assume any DDoS protection will do the job
• Focus on volumetric capacity but overlook detection accuracy, time to mitigate, mitigation efficacy and stealth attacks to the application layer
• Rely on reactive or hybrid approaches that leave a mitigation gap
• Accept user friction as an acceptable side effect of defence activity
• Accept operational complexity as “the nature of the beast”

Often, these gaps only become visible during critical moments such as launches, seasonal peaks or high-traffic events, when resilience matters most.

The Solution: Supporting Continuity with Always-On Mitigation

Thales’s Imperva DDoS Protection is designed to preserve availability and user experience, even during sustained or sophisticated attacks.

Behind the scenes, this means:

• Continuous and detailed profiling of peace-time traffic for fast identification of anomalies and potential DDoS attacks.
• Always- on mitigation at the edge, eliminating delays in response with an industry-leading 3–     second time-to-mitigation SLA for network-layer attacks.
• Versatile set of techniques for minimising disruption to legitimate users, including signatures, behavioural patterns and challenges.
• Attack isolation for avoiding potential collateral damage.
• Global scale and distribution, absorbing attacks close to the source.

The Impact: Why True Resilience Matters for Revenue

DDoS attacks don’t just test security controls; they test business resilience. When protection fails, the impact is immediate, abandoned sessions, lost transactions, frustrated customers and operational pressure at exactly the wrong moment.

DDoS resilience isn’t defined by how large an attack you can withstand, but by how consistently your services remain available while it’s happening.

By aligning always-on mitigation, rapid response and accurate traffic, classification, organisations can reduce risk without compromising user experience and ensure that availability isn’t dependent on perfect timing or manual intervention.

Because the true test of DDoS protection is whether services remain available.

To discuss DDoS protection with a member of the team, get in touch.

The post Why Most DDoS Protection Fails: Solving for Continuity and Resilience appeared first on Blog.

Since the headline-grabbing outages of 2021, we’ve had recurring conversations with large enterprises asking some version of the same question.

Do we really want our CDN, security, and routing control to live in the same place?

This issue of control has become more urgent after a series of well‑publicized, multi‑hour outages across major cloud‑based DDoS protection and security platforms. These incidents are rare but appear to be increasing in frequency. And when they happen, they expose architectural decisions many organisations haven’t revisited in years. The fact is that architectures assumed providers would never fail. Reality proved them wrong.

The concern isn’t whether cloud DDoS mitigation works. At scale, it does. The issue is control: whether customers retain the ability to reroute traffic independently if the provider itself goes down.

Many DDoS protection services simplify onboarding by originating customer prefixes and returning traffic via static paths. Under normal conditions, this works. During a provider outage, especially one affecting routing or orchestration, customers may lose the ability to reroute traffic
independently. Recovery depends on provider‑side changes at the worst possible moment.

That’s when a DDoS mitigation service can become a single point of failure.

Protection and control are different problems

One thing we consistently hear from network and security teams is that DDoS attack mitigation and traffic control are often treated as the same problem. They aren’t.

Resilient architectures separate them:

The Internet already provides a mechanism to enforce this separation: the Border Gateway Protocol (BGP). This is the Internet’s routing protocol; it determines how traffic is directed between the networks.

So, the real question isn’t whether to use cloud‑based DDoS protection. It’s whether that protection operates with your routing policy, or instead of it.

Resilient architectures treat attack mitigation and traffic control as separate concerns. Providers absorb DDoS attacks. Customers retain routing authority using BGP, enabling them to decide how traffic flows during failures.

When customers control BGP, outages take on a different character. They become routing events, not service outages. Traffic can be redirected faster, the blast radius is reduced, and network teams respond using familiar controls instead of escalation paths.

Designing for the inevitable

No provider is immune to failure. CDNs, hyperscalers, and DDoS mitigation services all operate complex, global control planes.

Resilience doesn’t come from assuming outages won’t happen. It comes from designing so that when they do, customers still control the outcome.

That’s why more organizations are adopting architectures where:

• DDoS protection is cloud‑delivered
• Routing authority remains customer‑owned
• BGP is the final decision layer for traffic steering

This approach preserves the benefits of cloud‑scale mitigation while avoiding the creation of new single points of failure.

A practical next step

If you’re rethinking your DDoS architecture, your best starting point isn’t a product demo; it’s an architectural review. Here are some questions to ask yourself:

• Who originates your prefixes today?
• How quickly can you reroute traffic if a provider is unavailable?
• What dependencies exist between mitigation availability and network availability?

Those answers usually reveal more than any outage postmortem.

On the Internet, control of routing is control of availability, and we think that control should always remain in customer’s hands.

Want to discuss what customer‑controlled DDoS protection looks like in practice? Get in touch with Thales to review your architecture.

The post When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced appeared first on Blog.

As APIs power the majority of modern web applications, implementing robust API security is no longer optional – it’s a critical necessity for data protection. This guide explores how to seamlessly integrate API gateway security into your Imperva on-premises environment to mitigate OWASP Top 10 threats, ensuring both web application and business logic threats are effectively managed.

The Need for API Security Integration

APIs not only enable communication between systems but also expose vulnerabilities that can be exploited by attackers. A strong API security solution safeguards your applications against threats ranging from SQL injections and cross-site scripting to more nuanced business logic attacks. With Imperva’s security capabilities integrated into your gateway, you benefit from:

• Comprehensive API Protection: Defend against the OWASP API Top 10 risks, including BOLA and Broken Authentication, by stopping malicious traffic at the gateway.
• Operational Simplicity: Leverages the powerful capabilities of the Imperva gateway without adding unnecessary complexity.
• Flexibility and Scalability: Supports on-premises, cloud-native, and Kubernetes environments, adapting to your organization’s evolving needs.

Key Technical Aspects of the Integration

Dynamic Profiling and Application Insight

Imperva’s patented Dynamic Profiling technology is at the core of this integration. It automatically learns the structure and usage of your web applications by monitoring every URL, parameter, cookie, and HTTP method. This continuous learning process helps to:

• Automatically Adjust Security Profiles: Minimal manual tuning is required as the system adapts to your application’s normal behavior.
• Detect Anomalies: By comparing real-time data against expected usage models, the solution quickly identifies suspicious activities that could indicate an attack.

Protocol Validation and Attack Signatures

The integration offers a dual-layer defense strategy:

• Protocol Validation: Every API request is checked to ensure compliance with HTTP protocol standards, filtering out malformed or malicious requests.
• Attack Signatures: With a comprehensive database of over 6,500 attack signatures that are regularly updated by expert teams, the WAF GW swiftly identifies and blocks known threats.

Diagram: Imperva Security Layer Architecture – This diagram illustrates the layered approach of Imperva’s security, showing how protocol validation, signature matching, and dynamic profiling work together to secure API traffic.

Application Profiling and the Correlation Engine

Understanding your application’s normal behavior is key to spotting potential threats. By profiling real-time usage and employing a sophisticated correlation engine, the solution:

• Detects Business Logic Attacks: Identifies vulnerabilities such as Broken Object Level Authorization (BOLA) and Broken Function Level Authorization (BFLA).
• Enhances Threat Verification: Integrates data analysis with vertical integration to validate and remediate suspicious activities effectively.

Seamless Integration with Leading API Management Tools

Imperva’s API-Anywhere solution provides a gateway-agnostic approach, integrating leading tools like Kong API Gateway via a dedicated plugin. This gateway-agnostic approach ensures:

• Selective Traffic Handling: Only validated, non-malicious traffic is forwarded to the API controller, maintaining optimal performance.
• Automated API Discovery: The system continuously identifies, classifies, and monitors API endpoints, including deprecated and unauthenticated ones, reducing manual effort and accelerating the development cycle.

×

Apr 9 Upcoming Webinar

Stronger Together: Advanced Bot Protection + API Security = Superior Protection Against Automated API Abuse

Register Now

Deployment and Installation: A Step-by-Step Guide

Flexibility in deployment is a key benefit of the Imperva API security solution. Whether your infrastructure is based on cloud-native technologies like Kubernetes or traditional hypervisors like VMware, integration is straightforward.

1. Generate the Installation Package:
   Use the provided HELM chart to generate configuration files and prepare the console.
   • Impv-a-console-x.x.x.tgz (This Package includes the Helm Chart of the Console)
   • Values.yaml (This file contains the configuration)
2. Deploy the Console:
   Install the console in your environment. This can be managed either via the Imperva Cloud Console or a local self-managed option.helm install impv-apisec-console -f values.yaml -n impv-anywhere –create-namespace
3. Enable the API-Security Policy on Your Gateways:
   With the console active, enable the API security policy on your gateways. The gateway begins populating data to the Imperva Unified Management Console (UMC) either in the cloud or on premises, based on your configuration.
   
4. Ongoing API Discovery and Verification:
   Continuous API discovery and Swagger file verification ensure that all endpoints are monitored, classified, and secured, significantly reducing the risk of overlooked vulnerabilities.

Benefits and Added Value

Integrating API security with the Imperva gateway delivers tangible benefits:

• Streamlined Security Operations: Automated profiling and centralized management reduce the operational burden on your security teams.
• Enhanced Developer Productivity: Automated API discovery and inventory management expedite the development cycle.
• Robust Protection Across Environments: Whether your APIs are public-facing or internal, legacy or cloud-native, the solution offers comprehensive security without compromising performance.
• Actionable Insights and Compliance: Gain granular visibility into traffic to support GDPR, PCI DSS, and HIPAA data governance and protect sensitive PII.

Conclusion

A robust API security strategy must be flexible, comprehensive, and easy to deploy. Imperva’s API-Anywhere solution integrated with your gateway environment meets these requirements by offering:

• A Gateway Agnostic Security Solution: Seamlessly integrates with multiple API management tools.
• Automated API Inventory and Protection: Continuously monitors and updates API endpoints, uncovering any shadow or deprecated APIs.
• Dual-Level Threat Mitigation: Protects against both application-level and business logic attacks through dynamic profiling, protocol validation, and advanced correlation engines.

By integrating this solution, organizations can protect critical assets, streamline operations, and maintain high levels of security and compliance, all while enabling a faster, more agile development process.

The post Integrating Advanced API Security with Imperva Gateway Environment appeared first on Blog.

We’re excited to announce the launch of Upload Scan and Control, an essential new feature for Imperva Cloud WAF. This add-on tackles one of the most critical vulnerabilities facing web applications today—insecure file uploads—offering protection with scalability, simplicity, and enterprise-grade control.

Why Secure File Upload Protection Is Critical for Modern Web Applications

File upload functionality is now a staple in web applications; from job portals accepting résumés to customer support platforms collecting documents.

Unfortunately, attackers exploit this functionality to inject malware, ransomware, and other malicious payloads into systems. This also can become the main source for remote code executions.

With Upload Scan and Control integrated into your Web Application Firewall (WAF), you’ll soon be able to enforce file size and type restrictions, blocking unauthorized or suspicious files before they enter your environment, ensuring your upload capabilities remain safe and compliant.

According to the OWASP Top Ten, insecure file uploads remain one of the most exploited web application vulnerabilities worldwide.

The Growing Risk of Malicious File Uploads

Across the Cloud WAF user base, we process over 20 million file uploads daily, with more than 800 customers across industries like finance, healthcare, retail, and government.

Cyber attackers are becoming more sophisticated and often target file uploads as an initial entry point. The earlier you can block malicious content, before it hits an endpoint or server, the greater your chances of preventing a breach entirely.

×

Apr 9 Upcoming Webinar

Stronger Together: Advanced Bot Protection + API Security = Superior Protection Against Automated API Abuse

Register Now

Why Network-Layer File Upload Security Beats Endpoint-Only Protection

Endpoint antivirus and EDR tools play a critical role in detection, but they typically act after malicious files land on your system. At this stage, it may already be too late. Investigations take longer, the damage may already be done, and attackers may have gained a foothold.

Upload Scan and Control stops threats at the edge, before files are saved or executed, enabling true prevention over delayed remediation before they even reach your network layer.

Advantages of Imperva Upload Scan and Control for Cloud WAF

Our new feature delivers several enterprise-grade benefits:

1. Full visibility across all upload points: Identify which applications allow file uploads and monitor activity from a single dashboard.
2. Instant, one-click activation: Protect all current and future apps automatically, eliminating developer integration work.
3. Scalable security for large enterprises: No additional requirements for app owners or developers to introduce additional integrations significantly reducing operational overheads.

Peace of Mind for Security Leaders and Compliance Teams

With Upload Scan and Control, enterprises can:

• Block threats at the edge before they reach your network.
• Trace file origins and identify the responsible user or IP.
• Maintain audit-ready compliance records (such as GDPR, CCPA, and HIPAA) without adding complexity to existing security stacks.

As cloud-native adoption accelerates and threat actors adapt, features like this are becoming essential to maintaining a secure, compliant perimeter.

Get Ready to Enable Upload Scan and Control

If you’re already using Imperva Cloud WAF today, check your Imperva console to see which apps you currently allow file uploads against and start protecting them today. Get in touch so you can activate Upload Scan and Control within your Cloud WAF environment or to schedule a demo, contact your Imperva account team.

The post Cloud Based WAF Upload Scan and Control: The New Standard for File Upload Security appeared first on Blog.

In an era marked by escalating cyber threats and evolving risk landscapes, organisations face mounting pressure to strengthen their security posture whilst maintaining seamless user experiences. At Thales, we recognise that robust security must be foundational – embedded into products and services by design, not bolted on as an afterthought. This principle underpins our commitment to the U.S. Cybersecurity and Infrastructure Security Agency (CISA)’s Secure-by-Design pledge, which calls on software manufacturers to establish security features like multi-factor authentication (MFA) as standard across their product portfolios.

As digital transformation accelerates and attack surfaces expand, the gap between security capabilities and emerging threats continues to widen. According to the 2025 Thales Data Threat Report, organisations are grappling with unprecedented challenges: 69% regard the fast-moving ecosystem as the most concerning GenAI security risk, whilst 83% report that strong MFA is used more than 40% of the time. This indicates both progress and significant opportunity for improvement. These findings underscore a critical reality: whilst security tools and technologies have advanced, comprehensive deployment and consistent enforcement remain essential challenges that demand immediate attention.

This blog examines the pivotal role of multi-factor authentication in modern cybersecurity strategies. We explore the fundamentals of MFA, analyse the evolving threat landscape that necessitates its adoption, and provide practical guidance on implementation. Whether you are a security professional seeking to strengthen your organisation’s defences or an individual user looking to protect personal accounts, this resource offers the insights and actionable steps needed to embrace MFA with confidence and rigour.

Understanding Multi-Factor Authentication: The Basics

Multi-factor authentication verifies your identity using two different forms of identification. Typically this involves something you know (like a password) and something you have (like a code on your phone). Think of it like using an ATM: you need both your bank card and your PIN to withdraw cash.

This dual-layer approach creates a significant barrier for attackers. Even if someone steals your password, they still can’t log in without that second factor. It’s elegantly simple, yet remarkably powerful – your password alone is no longer enough to unlock the door.

The Growing Threat Landscape: Why MFA Is No Longer Optional

Cyberattacks have grown increasingly sophisticated, with stolen passwords at the heart of many breaches. According to the 2023 Verizon Data Breach Investigations Report, nearly 49% of data breaches involved the use of stolen credentials.

MFA directly addresses this vulnerability. Our own research at Thales demonstrates the critical importance of strong authentication measures. According to the 2025 Thales Data Threat Report, 83% of organisations report that strong MFA is used more than 40% of the time, yet significant challenges remain in achieving comprehensive deployment. This data underscores both the growing recognition of MFA’s importance and the continued need for organisations to strengthen their authentication posture.

Furthermore, our 2025 Digital Trust Index – Third-Party Edition reveals a concerning reality: 40% of users reset passwords once or twice a month, highlighting the inherent weakness of password-only authentication systems. These frequent password resets not only frustrate users but also create security vulnerabilities that MFA effectively mitigates.

How MFA Defeats Common Attack Methods

MFA thwarts the most prevalent attack techniques:

Brute-force and credential stuffing attacks: These automated attacks become practically futile with MFA enabled because guessing the password isn’t enough to break in.

Phishing attacks: Even if you unwittingly hand over your password to a phisher, they still can’t access your account without the one-time code or second factor that MFA requires.

It’s no surprise that CISA’s Secure-by-Design guidelines explicitly call for making MFA a built-in, default security feature. In today’s threat landscape, MFA has evolved from a nice-to-have extra to an essential safeguard.

Thales’ Commitment: Security by Design and by Default

At Thales, we build security into our products by design, baked into our products and services. Our commitment to CISA’s Secure-by-Design pledge is reflected in how we develop features like MFA.
We already implement robust MFA across our cloud services to help safeguard your accounts and data. By requiring two forms of identification to access the Thales Cloud Security Console, we add an extra layer of protection that makes it “much harder for unauthorised users to access sensitive information”. This significantly reduces the risk of breaches and builds trust.

The Principle of Shared Responsibility

Thales’ approach recognises shared responsibility. “Security by default” means we provide secure settings and features right out of the box. However, security is also a partnership – we provide the tools, whilst you play a crucial role by using them.
We’ve made MFA available and straightforward to configure, and we actively encourage customers to use advanced authentication methods. Whilst MFA might not be mandated on all accounts by default today, we strongly recommend that you activate it. By choosing to enable MFA now, you’re not only protecting yourself immediately but also aligning with best practices that Thales and the cybersecurity community advocate globally.

Getting Started: How to Set Up MFA

Enabling multi-factor authentication on your Thales account is quick and straightforward. Here’s how:

1. Log in and navigate to your user settings. Go to Account Settings or Profile, where you’ll find security settings for MFA management. You can find these options in the Thales Cloud Security Console setup checklist.
2. Locate the Multi-Factor Authentication option and click to begin setup.
3. Select your preferred MFA method: authenticator app, SMS, or email.
4. Configure the chosen method:
   • For an authenticator app, scan the displayed QR code with your app ( MobilPASS+, Google Authenticator, Microsoft Authenticator, Authy, etc.).
   • For SMS, enter your mobile number to receive a verification code.
   • For email, a code will be sent to your registered email address.
5. Save your backup codes. These are your safety net if you lose access to your MFA device. Store them in a secure location like a password manager.
6. Complete and test the setup. Once verified, MFA will be enabled. Log out and log in again to ensure everything works properly.

That’s it! You’ve added a powerful extra layer of security in just a few minutes.

Choosing Your MFA Method: A Comparison

For organisations seeking a comprehensive overview of authentication options, Thales offers an extensive portfolio of MFA tokens and authenticators. Our OneWelcome Authenticators Portfolio includes FIDO2 passkeys, hardware tokens, smart cards, and software authenticators, ensuring secure access across different environments and devices . This breadth of choice allows organisations to select the authentication method best suited to their security requirements and user needs

When setting up MFA, you have several authentication options:

Authenticator App (recommended): Generates a new 6-digit code every 30 seconds. This method is very secure, works offline, and is significantly more phishing-resistant. Pros: High security, no network dependency. Cons: Requires your phone.

Text Message (SMS): Sends a one-time code to your mobile phone. Pros: Easy to use, no app required. Cons: Slightly less secure than authenticator apps due to potential SIM-swapping attacks, but still greatly improves security over no MFA. CISA recommends SMS-based authentication only as a “last resort” when more secure options aren’t available

Email Codes: Sends verification codes to your registered email. Pros: No extra device needed. Cons: Least secure option if your email is compromised. Use only if other methods aren’t feasible, and ensure your email itself has MFA.

Hardware Security Keys: Physical devices, such as Thales FIDO Security Keys that you plug in or tap to verify login. Pros: Highest level of security, phishing-resistant. Cons: Requires purchasing a device.

Which should you choose? If possible, use an authenticator app or hardware key, as these are most secure. For most users, an authenticator app strikes an excellent balance. SMS is a solid fallback, and email can work if necessary – just be aware of the security trade-offs.

Moving Beyond Passwords: Passwordless Authentication

Whilst MFA significantly strengthens security, the most forward-thinking organisations are taking the next step: eliminating passwords altogether. Passwordless authentication removes the vulnerabilities inherent in password-based systems – no passwords to steal, phish, or reuse.

Thales’ SafeNet Trusted Access empowers organisations to build comprehensive passwordless policies using FIDO2 passkeys, biometrics, and hardware authenticators. Our Passwordless 360 approach provides a detailed framework for implementing passwordless authentication across your organisation, combining security, user experience, and regulatory compliance.

Troubleshooting and Frequently Asked Questions

Q: Do I have to enter an MFA code every single time I log in?
A: Often not every time. Many systems offer the option to “remember” a device for a certain period (e.g., 14 days). This means you won’t need to enter a code each time on that trusted device. However, use this feature only on personal devices you control, not shared or public computers.

Q: I’m not receiving the MFA code, or it says the code is wrong. What should I do?
A: Common solutions include: For SMS, check your signal and that your phone number is correct in account settings. Wait a moment and click “Resend code” if available. For authenticator apps, ensure your phone’s clock is accurate, as codes are time-based. For email, check your spam folder.

Q: What if I lose access to my phone or MFA device?
A: Use your saved backup codes to log in. If you’ve lost those as well, contact Thales support for account recovery assistance.

Q: Can we use our own IdP?
A: Yes, you can leverage external IdPs like SafeNet Trusted Access by Thales, which allows you to build adaptive authentication policies and leverage a broad range of MFA options.

Q: Can I switch MFA methods?
A: Yes. You can disable MFA and re-enable it with a new method anytime through your account settings.

Q: Is MFA required?
A: Whilst not mandatory on all accounts today, we strongly recommend enabling it. It’s one of the most effective ways to protect your account.

Understanding Digital Trust: Research from Thales

Thales’ research demonstrates the critical importance of strong identity and access management. Our 2025 Digital Trust Index – Third-Party Edition reveals that 96% of third-party users face issues logging into partner systems, wasting 48 minutes a month on average. Additionally, 40% reset passwords once or twice a month – highlighting the need for more secure, passwordless methods like MFA.

The 2025 Data Threat Report further emphasises this urgency. According to our research, 83% of organisations report that strong MFA is used more than 40% of the time, yet challenges remain. As organisations adopt AI and face evolving quantum threats, robust authentication becomes even more critical.

Thales’ comprehensive Identity and Access Management solutions provide organisations with the capabilities needed to improve user experiences whilst strengthening security. From Multi-Factor Authentication and Single Sign-On to passwordless authentication and passkeys, Thales delivers the tools to make IAM processes straightforward and dependable.

Final Thought

Cybersecurity is a shared responsibility. We design secure systems, and you make them stronger by turning on protections like MFA. Enable MFA today in your Thales account settings. It takes just a few minutes and makes a significant difference.

Secure by design starts with secure choices.

The post Security by Design: Why Multi-Factor Authentication Matters More Than Ever appeared first on Blog.

The surge in AI-driven traffic is transforming how websites manage their content. With AI bots and agents visiting sites at unprecedented rates (often scraping without permission, payment, or attribution) content owners face a critical challenge: how to protect their intellectual property while capitalizing on legitimate AI use cases.

Today, we’re excited to announce Imperva’s integration with TollBit, a groundbreaking solution that enables our Cloud Web Application Firewall (CWAF) customers to monetize traffic from AI bots and crawlers that would otherwise scrape their content without permission or compensation.

Meeting the AI Traffic Challenge

The traditional ad-supported and subscription-based content models are being disrupted by AI. This integration provides a new economic model where value flows fairly between content creators and AI developers, transforming unauthorized scraping into a sustainable revenue stream.

How Imperva and TollBit Work Together

The integration leverages Imperva’s industry-leading Web Application Firewall capabilities alongside TollBit’s analytics and monetization platform to create a comprehensive solution:

1. Detection & Enforcement: Imperva CWAF identifies AI bot traffic at the edge, providing the critical first layer of protection.
2. Intelligent Redirection: Using Imperva’s redirect rules, requests from AI bots are automatically redirected to a TollBit subdomain (e.g., tollbit.example.com), with CWAF returning an HTTP 302 response.
3. Payment Gateway: The TollBit subdomain returns an HTTP 402 response code (payment required), prompting AI bot operators to obtain valid TollBit tokens for authorized access.
4. Analytics & Insights: Through SIEM log integration, Imperva Access and Security logs flow to TollBit’s analytics engine, providing executives with clear, AI-specific analytics that show how bots are engaging with their content and the business impact of that traffic both within Tollbit and Imperva’s UMC.

Implementation Architecture

The integration requires a straightforward setup process:

• Onboard your domain to Imperva Cloud WAF
• Create a TollBit account and verify domain ownership via DNS TXT records
• Configure a TollBit subdomain with appropriate DNS NS records
• Create redirect rules in Imperva’s management console to route AI bot traffic
• Set up AWS S3 bucket integration for log processing and analytics

To ensure compatibility with TollBit’s requirements, an AWS Lambda function prefixes dates to Imperva log file names, enabling seamless ingestion into TollBit’s analytics platform.

A Shared Vision for Fair Compensation

This partnership represents a fundamental shift in how content owners approach AI traffic. Rather than simply blocking all bots or allowing unrestricted scraping, sites now have granular control to enforce access rules and pricing on their own terms.

Content owners deserve fair compensation for how their content powers the AI ecosystem. By combining Imperva’s security capabilities with TollBit’s monetization tools, we’re enabling the transition from unauthorized scraping to sustainable, licensed transactions.

What This Means for Imperva Customers

With this integration, Imperva CWAF customers gain:

• Robust protection against unauthorized AI scraping at the application layer
• Complete visibility into AI traffic patterns and behaviors through dedicated analytics
• Flexible control to decide which AI agents can access content and under what conditions
• New revenue streams that turn scraping attempts into legitimate, paid transactions

The agent economy is here, and autonomous AI visitors are becoming a permanent fixture of web traffic. With Imperva and TollBit, you can ensure these interactions happen on your terms—fairly, transparently, and profitably.

Get Started

If you’re an Imperva Cloud WAF customer and want to activate the integration:

• Create your own Tollbit account on the TollBit platform https://app.tollbit.com/sign-up.
• Create custom rules in the Imperva Cloud WAF platform as instructed in the TollBit Docs.

TollBit is free for publishers and websites so you can be up and running in no time.

Learn more about how Imperva’s integration with TollBit can help you protect and monetize your content in the AI era.

The post Imperva Partners with TollBit to Power AI Traffic Monetization for Content Owners appeared first on Blog.

The more critical APIs become, the more sensitive data they carry identities, payment details, health records, customer preferences, tokens, keys, and more.

And this is where organizations face a painful, often invisible problem:

To protect APIs, many organizations end up exposing the very data they are trying to secure.

Most API security tools still rely on raw-payload logging, traffic replay, or shipping full request bodies into external analytics systems. That means sensitive customer data:

• Leaves controlled environments
• Gets stored in multiple systems
• Crosses borders without intention
• Lands in tools not designed to hold PII
• Multiplies breach risk and regulatory pressure

This creates a direct conflict between security, privacy, and compliance, and businesses are caught in the middle.

The Real-World Impact: When Privacy Becomes a Security Liability

Across industries – financial services, retail, healthcare, travel, public sector, the story repeats:

1. Breach blast radius expands

The more systems that hold raw API payloads, the bigger the impact when any one of them is compromised.

2. Compliance becomes harder, not easier

GDPR, CCPA, HIPAA, PCI, and emerging data-sovereignty regulations penalize:

• unnecessary data retention
• cross-border data transfers
• third-party exposure
• lack of data-minimization controls

Most API security tools inadvertently violate all four.

3. Data residency rules block API security deployments

Organizations operating in multiple regions can’t centralize raw API data in a single cloud service, but many tools require doing exactly that.

4. Dev and QA environments become privacy risks

When security tests are based on production payload replays, sensitive data leaks into non-production systems.

5. Security teams lose visibility if they avoid raw logging

Many leaders try to “lock down” data flows, but that often leaves API blind spots, making it harder to detect business logic abuse, scraping, or session-based attacks.

This is the API privacy paradox:
You either weaken privacy to strengthen security or weaken security to preserve privacy.

The Industry Approach Is Broken

The traditional API security model makes three flawed assumptions:

1. You must log or store raw payloads to get visibility.
2. You must centralize traffic for analytics.
3. You must replay production data to test API security.

These assumptions create privacy exposure, compliance failure, and operational friction.

Imperva Solves This by Rethinking the Architecture

Imperva’s privacy-first, local-first platform was built around a core belief:

API security should not require exposing sensitive data, ever.

The architecture flips the traditional model:

1. Inspect at the PoP (where traffic lives)

Traffic is parsed in-memory at the Point-of-Presence closest to the application, SaaS PoP or on-prem.

Raw values never leave the PoP.

2. Convert sensitive values into privacy-safe artifacts

Classification + hashing replaces raw payloads with:

• label
• schema fragments
• one-way irreversible hashes
  This is the only data that ever moves upstream.

3. Detect and respond using metadata only

Anomaly detection uses metadata such as:

• data labels
• schema context
• session identifiers
• hashed tokens

No raw content is needed or exposed.

4. Enforce using hashes, not identities

Hash-based enforcement enables:

• per-session blocking
• token-level mitigation
• behavior-based decisions
  without seeing or sharing the sensitive value behind the hash.

5. Same privacy guarantees across all deployments

Cloud, on-prem, hybrid – the mechanics never change.

What This Means for the Business

This is where Imperva’s architecture translates directly into measurable, enterprise-wide value:

Smaller blast radius = lower breach liability

Fewer systems hold PII, drastically reducing what attackers can steal and what you must disclose.

Faster compliance alignment

Local data processing and zero raw persistence align with GDPR, HIPAA minimum-necessary, and sovereignty rules.

Real-time protection with zero added exposure

Inline, in-PoP inspection gives detection teams full visibility without raw payload retention.

Safer automation in Dev/QA

Privacy-aware test artifacts eliminate the risk of production PII leaking into pipelines.

Reduced third-party risk

Vendors never receive raw payloads, only metadata and hashes.

A future-proof privacy posture

As regulatory pressure increases, architectures like this become mandatory, not optional.

Why This Whitepaper Matters

This whitepaper breaks down exactly how Imperva delivers production-grade API protection while preserving privacy, with clear explanations and practical examples.

You’ll learn:

• How to get deep visibility without storing raw payloads
• Why in-PoP processing reduces exposure and simplifies compliance
• How hash-based enforcement protects identities while enabling precise blocking
• How to design a privacy-first architecture that works across hybrid/multi-cloud

In other words:
If you need to secure APIs and meet privacy, residency, or compliance requirements – this is essential reading.

Ready to See How Privacy-First API Security Really Works?

Download the whitepaper and learn how Imperva protects APIs without exposing sensitive data.

The post The Privacy Gap in API Security: Why Protecting APIs Shouldn’t Put Your Data at Risk appeared first on Blog.

The holiday shopping season is the busiest time of year for online retailers, and increasingly the most dangerous. As traffic surges and customers rush to place orders, cybercriminals use the distraction and volume to blend in. Account Takeover (ATO) attacks spike sharply in November and December, targeting shoppers’ saved payment details, loyalty points, wish-lists, and personal data.

Most retailers focus on keeping sites fast and campaigns running smoothly, but this seasonal pressure creates blind spots in authentication, login flows, and Application Programming Interface API endpoints. Attackers know this and use automated tools and AI-driven bots to slip into accounts with little resistance.

During peak season, it doesn’t take long for an unnoticed credential-stuffing surge, or a burst of suspicious login attempts to translate into real financial loss and customer frustration. For many retailers, the challenge isn’t a dramatic breach, it’s the quiet, persistent account abuse that goes undetected until the damage is already done.

The Escalation of Account Takeover Attacks

According to the 2025 Imperva Bad Bot Report, Account Takeover attacks increased by 40 percent in 2024 and by more than 50 percent since 2022. The rise reflects the expanding attack surface of modern digital businesses and the increasing availability of stolen credentials.

ATO attacks are rarely brute force assaults in the traditional sense. Most rely on automation and intelligence. Attackers use:

• Credential stuffing to test stolen username and password pairs obtained from prior data breaches
• Credential cracking to predict likely passwords using AI or dictionary-based guessing techniques
• Brute force attacks to systematically attempt all possible combinations where no prior credential data exists

Each of these techniques is enhanced by bot networks capable of emulating legitimate traffic and distributing attacks across thousands of IP addresses to avoid detection.

Once an account is compromised, attackers can alter stored payment details, redeem loyalty points, exfiltrate personal data, or pivot into connected systems through single sign on integrations. The damage can be widespread and difficult to undo, making remediation costly, complex, and often too late to fully protect the victim.

The Cost of Compromise

A successful Account Takeover is not just a security failure; it is a business crisis. The consequences cascade across financial, regulatory, and reputational dimensions.

• Financial loss from fraud, chargebacks, and stolen assets
• Operational disruption as security and customer support teams manage lockouts and resets
• Regulatory exposure under privacy and data protection laws such as GDPR, CCPA, and PCI DSS
• Legal costs and compensation claims from affected customers or partners
• Reputational damage leading to customer attrition and reduced trust

Regulators increasingly view inadequate protection of user credentials as a preventable failure. In industries such as financial services, retail, and telecom, where digital identity underpins customer engagement, the stakes are exceptionally high.

The AI Advantage for Attackers

Artificial intelligence is amplifying both the scale and sophistication of ATO campaigns. Where brute force once relied purely on volume, AI brings adaptive learning and behavioural mimicry.

Modern credential stuffing bots now simulate human navigation, introduce artificial pauses, and mirror typing patterns to bypass rate limits and behavioural detection systems. Machine learning

models trained on breached data can predict likely password sequences based on language, demographics, and prior password resets.

This capability turns traditional defences into speed bumps rather than barriers. The result is faster, more evasive attacks that require intelligent, context aware countermeasures.

The Expanding API Attack Surface

As organizations modernize applications, APIs have become both essential and exposed. They connect services, mobile clients, and third-party integrations, and they now represent a primary conduit for identity and data access.

According to Imperva telemetry, around 12 percent of all API attacks in 2024 were Account Takeovers. Many of these attacks are low volume and high value, designed to evade detection. Attackers harvest sensitive information in small increments such as user identifiers, loyalty balances, and payment tokens, and use that data later for large scale fraud or identity theft.

During the holiday shopping season, attackers take advantage of the fact that retail systems are under more pressure and handling far more automated traffic than usual. Bots are designed to blend seamlessly into this activity. They mimic real customers using legitimate browsers, realistic headers, and correctly formatted API calls, which makes them difficult to distinguish from genuine shoppers.

Instead of triggering obvious high-volume spikes, attackers quietly test stolen credentials across login APIs, probe authentication flows, and map out which accounts are valid. They reuse tokens, exploit weak session handling, and launch credential stuffing campaigns at a pace that fits naturally within peak season traffic. Because the requests look structurally correct, they often bypass volumetric detection and slip past basic rate limits.

Once inside an account, automated scripts extract loyalty balances, change delivery addresses, modify stored payment methods, or pivot through single sign on to gain access to additional services. For many retailers, these subtle API driven attacks are now the fastest growing source of credential-based compromise, and they reach their highest risk in November and December.

Thales recommends:

1. Improve visibility across login traffic this holiday season

During peak shopping periods, login volumes surge and attackers use the noise to hide. Monitor login attempts, unusual session behaviour, device changes, and repeated failures so you can spot suspicious activity early.

2. Strengthen authentication without slowing real customers

Shoppers expect fast checkout experiences, especially during sales events. Use smarter authentication controls that react to risk signals such as new devices or sudden spikes in login attempts, while keeping the journey seamless for genuine users.

3. Protect high value pages such as login and checkout

These are the most heavily targeted points during the holiday rush. Account Takeover attacks often begin on the login page and escalate at checkout. Ensure these flows have the strongest monitoring and protection in place to detect unusual behaviour before accounts are compromised.

4. Secure all APIs involved in customer accounts and orders

Retailers rely on APIs for login, checkout, loyalty, order history, and account management. These endpoints see huge traffic increases in November and December, making them prime targets for automated abuse. Apply full visibility and security controls across them.

5. Deploy Advanced Bot Protection to stop automated ATO attempts

Bots spike dramatically during holiday promotions. Advanced bot protection identifies and blocks automated credential testing, scripted login attempts, and account probing in real time without adding friction for real shoppers. This is critical for preventing ATO during your busiest weeks.

Visit Imperva.com Account Takeover Protection.

The post ’Tis the Season to Be Cyber-Wary: How Thales Protects Against Account Takeover During Peak Shopping Season appeared first on Blog.