What we believe

We’ve been thinking deeply about enterprise security. The operating model that served us for the past decade (collect telemetry, store it, query it, build dashboards to watch it) is no longer keeping pace. We need to shift to the new world: telemetry, context, reasoning, and actions. An approach that produces outcomes. The latest cybersecurity frontier models further made this shift urgent. Models like Claude Mythos can now find software vulnerabilities and reason through complex attack paths at machine-speed, leading to an exponentially increasing backlog of vulnerabilities.

Introducing AWS Continuum for code vulnerabilities

Today, we’re announcing AWS Continuum for code vulnerabilities, now available in gated preview. Continuum for code vulnerabilities addresses the full lifecycle of a code vulnerability at machine speed: from discovery through actions. It reasons over your environment, confirms what is real, and drives toward resolution. It’s model agnostic, using multiple frontier models where each performs best, and is built to incorporate the latest and most capable models as they emerge.

Continuum is built on lessons learned from running security across AWS and Amazon.com. Securing businesses that operate in different industries required a system that understands business context rather than applying generic rules uniformly.

How it works

Continuum for code vulnerabilities reasons over your full environment. This context includes structured data already living in Amazon Web Service (AWS) (your infrastructure, permissions, network topology, code) and the unstructured data that captures how your organization operates and your risk profile (your documents, communications, business priorities).

Continuum for code vulnerabilities operates in four continuous phases.

1. Discovery: Security teams tackle a backlog of vulnerabilities, and many are already using frontier models to find more. Continuum starts by ingesting that existing backlog and performing its own vulnerability scan of your environment. This creates a more comprehensive view of vulnerabilities and the associated attack paths.
2. Prioritization: Continuum uses context to evaluate, enrich, and prioritize every finding. Is the affected component deployed, is it reachable, is it in a production path, and what would the business impact be if exploited? The result is an evidence-backed list of priorities, allowing Continuum and your team to focus on what’s most important.
3. Validation: Continuum validates findings to surface false positives before they waste your team’s time. It contextualizes vulnerabilities against your environment. It then constructs working exploit examples in a sandboxed environment that provide concrete, reproducible evidence of the issue.
4. Mitigation and remediation: Continuum assesses existing defenses around a validated issue, including blocking and compensating controls along with detection mechanisms. It then draws on its understanding of the codebase, context, and findings to recommend mitigation or remediation of the vulnerability with a network change, policy change, or code patch. The patch recommendation is validated using the same system that confirmed the vulnerability. It also provides blast radius visibility and rollback paths where feasible.

This is just the beginning. We’re starting with code (1^st and 3^rd party) and then expanding to other aspects of security.

Trust is graduated

Continuum starts in learn mode with a human in the loop. Every recommendation includes the reasoning behind it. As you gain confidence, you can graduate Continuum to enforce mode, enabling remediation that can be increasingly automated based on categories and risk profiles you define.

Continuum capabilities

In addition to Continuum for code vulnerabilities, Continuum includes capabilities you might already know. The AWS Security Agent penetration testing and code scanning functionality is now part of Continuum as Continuum pen testing and Continuum code scanning (Preview). We’re also launching Continuum threat modeling in preview, which automatically generates comprehensive threat models from design documents or source code and outputs results in STRIDE format. These capabilities serve as detection and analysis sources that feed into the broader Continuum loop of discovery, prioritization, validation, and remediation.

Getting started

We’re working with customers across financial services, automotive, and technology to shape AWS Continuum. Customer feedback confirms the direction: security teams want tools that earn trust and take action.

AWS Continuum for code vulnerabilities is available in gated preview. Sign up to request access at AWS Continuum.

If you have feedback about this post, submit comments in the Comments section below.

AI security is getting attention because AI has stopped being a side experiment.  It is now part of how work gets done. Employees use copilots to write, research, code, and analyze. Product teams are adding AI into customer experiences. Developers are building applications on top of foundation models. Business teams are experimenting with agents that can read email, summarize documents, query data, and trigger workflows.  That is a very different world from the one many AI review processes were designed for.  An AI system can pass a benchmark and still fail in production. It can behave safely in a clean test environment and then encounter real […]

The post AI Red Teaming Makes the Unknowns Known appeared first on Check Point Blog.

In this blog post you’ll learn how to detect and prevent subdomain takeover – a tactic where threat actors exploit dangling DNS records to redirect traffic to attacker-controlled resources. We’ll explain the issue, how the situation arises, and how you can use various AWS features and services to help mitigate the impact of this tactic.

Under the shared responsibility model, securing configurations in the cloud is your responsibility. AWS supports you through strong defaults, guidance in the Security Pillar of the Well-Architected Framework, and security services to help you meet that responsibility. The AWS Customer Incident Response Team (AWS CIRT) also monitors for new and trending tactics that threat actors use to exploit specific customer configurations, so that you can make informed design decisions and improve your response plans.

AWS CIRT has observed threat actors actively scanning for public DNS CNAME records that point to resources that no longer exist, looking for subdomain takeover opportunities.

Note: The subdomain takeover tactic does not leverage vulnerabilities of AWS services. It exploits a dangling DNS record to redirect traffic to an attacker-controlled resource.

Quick DNS Primer

CNAME Records: A CNAME (Canonical Name) record is a DNS entry that points one domain name to another. For example, api.example.com can be configured to point to api.example.s3-website-us-east-1.amazonaws.com. This feature of DNS enables users to configure a memorable, human-friendly domain name while the actual resource lives at a longer, machine-generated AWS hostname. A security issue emerges when the target resource is deleted but the CNAME record pointing to it remains – creating a “dangling” record.

Dangling Records: When a resource (like an S3 bucket) is deleted but the DNS record pointing to it is left behind, that DNS record becomes “dangling”, pointing to a resource that no longer exists. For resources in globally shared namespaces, threat actors can potentially reclaim the name of your deleted resource and serve malicious content through your DNS record.

What is subdomain takeover?

A subdomain is a prefix added to a domain that allows you to organize access to your resources. A subdomain takeover occurs when you delete the underlying resource and a threat actor creates a new resource with the same name to take advantage of the DNS records still pointing to it.

A subdomain takeover is possible when a CNAME record points to an AWS resource that uses a globally shared DNS namespace where the resource name can be chosen by any AWS customer. The following AWS resources meet these criteria:

Amazon S3 (global namespace): Bucket names like mybucket.s3.amazonaws.com are globally unique and can be claimed by any account if the bucket is deleted. Note: S3 buckets created with account regional namespaces (launched March 2026) are scoped to your account and are not subject to this issue.

Amazon CloudFront: Distribution domain names like d111111abcdef8.cloudfront.net are assigned by AWS and cannot be chosen by an attacker. However, if you delete a distribution and another customer creates one that happens to receive the same domain name, a dangling CNAME could resolve to their content.

AWS Elastic Beanstalk: Environment names like myapp.elasticbeanstalk.com are globally unique and can be claimed by any account if the environment is terminated.

Resources like Amazon VPC, Amazon EC2 instances, or private hosted zones are not subject to this tactic because they do not expose globally claimable DNS namespaces.

MITRE ATT&CK classifies this technique under T1584.001: Compromise Infrastructure – Domains.

Analyzing an example scenario

Consider the following scenario:

You create a DNS CNAME record pointing to your S3 website endpoint. The subdomain subdomain.example.com now resolves to subdomain.example.s3-website-us-east-1.amazonaws.com, which serves content from the S3 bucket named subdomain.example. If your team deletes the bucket and forgets to delete the DNS record, users that navigate to the site will see an error stating that the bucket doesn’t exist. However, at this point, if a threat actor sees this error and moves in to claim the bucket name, they will be able to set up their own site that users will see when they navigate to the subdomain.example.com site.

Figure 1 shows an S3 bucket named subdomain.example (a globally unique bucket name) configured to host a static website, with the S3 website endpoint subdomain.example.s3-website-us-east-1.amazonaws.com.

Figure 1: S3 bucket configured as a static website

As shown in Figure 2, we use Amazon Route 53 to create a CNAME record to resolve to our Amazon domain name; to give users a friendly name and so they do not have to remember the long S3 website name in URLs.

Figure 2: DNS Resolver configured with CNAME record pointing to origin bucket

The customer’s AWS administrator decides to stop serving content from the S3 bucket and deletes it, as shown in Figure 3.

Figure 3: Resource deleted without removing the CNAME record

With the S3 bucket deleted and the CNAME record still in place, the DNS record is now dangling. A threat actor identifies this situation and creates a new S3 bucket with the same global name subdomain.example in an AWS account that the threat actor controls, as shown in Figure 4. The threat actor can now serve content from this new bucket, including potentially malicious content. End users remain unaware of this switch and continue to access subdomain.example.com, trusting the content because it appears to originate from a URL they recognize.

Figure 4: Subdomain takeover happens

Potential impacts of a sub-domain takeover

Consider these potential impacts:

Reputation risk: There is a potential risk to your organization’s reputation, because you don’t control the content being served from the threat actor’s site that your DNS record points to.

Potential exposure to phishing campaigns: Users within your organization might have the subdomain bookmarked in their browser, not knowing the resource is no longer available, then unsuspectingly navigate to the site that now hosts malware or is used to phish user credentials.

Blocking: If the subdomain is flagged by security vendors for malicious activity, it could impact your business operations.

Financial loss: Subdomain takeover incidents can result in a financial impact due to the potential disruption to service delivery as you deal with the event.

Proactive detection

AWS Config for proactive detection

For proactive detection, you can use AWS Config to continuously monitor your Route 53 CNAME records and verify that the target resources exist in your account.

Prerequisite: This approach requires AWS Config recorder to be enabled for the resource types you want to monitor (S3 buckets, CloudFront distributions, Elastic Beanstalk environments). If Config isn’t recording a resource type, it won’t appear in the inventory check. For more information, see Setting up AWS Config with the console.

Why use AWS Config inventory instead of DNS resolution checks?

A common approach is to check whether a CNAME resolves to a valid endpoint. However, this method has a critical flaw: if an attacker has already claimed the resource, DNS resolution will succeed – to their resource, not yours. You would have no indication that you don’t own what’s responding.

By querying AWS Config’s recorded configuration items, you’re checking whether the resource exists in your account inventory, not just whether something responds at that DNS name. This approach correctly identifies dangling CNAMEs even after a takeover has occurred.

Implementation approach:

Account-level vs. organization-level scope

The reference implementation queries AWS Config inventory within a single account. This means that if a CNAME record in Account A points to a resource that legitimately exists in Account B within the same AWS organization, the rule will flag it as NON_COMPLIANT.

For organizations that share resources across accounts, you can modify the solution to use an AWS Config Aggregator, which queries resource inventory across all accounts in your organization. This is similar to how IAM Access Analyzer supports both account-level and organization-level scopes. To use this approach, you need an organization-level Config Aggregator already configured, and the Lambda function’s IAM role needs the config:SelectAggregateResourceConfig permission.

We recommend starting with account-level scope for simplicity, then expanding to organization-level if your environment includes cross-account resource sharing.

The main idea is to create a custom AWS Config rule that queries your Route 53 hosted zones for CNAME records, then parses each CNAME target to determine whether it points to a known AWS resource pattern such as S3, CloudFront, or Elastic Beanstalk. For each match, the rule cross-references the target against your AWS Config inventory to verify that the resource actually exists in your account. If the resource isn’t found, the rule marks the CNAME record as NON_COMPLIANT, surfacing it for review.

The Config rule should focus on known AWS resource patterns:

• S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com
• CloudFront: *.cloudfront.net
• Elastic Beanstalk: *.elasticbeanstalk.com

Note: CNAME records pointing to external third-party services are outside the scope of this detection mechanism, as those resources won’t appear in your AWS Config inventory.

NON_COMPLIANT findings from your Config rule can be routed to AWS Security Hub for centralized visibility, or trigger SNS notifications to alert your security team.

Figure 5: Dangling DNS Detection Solution

Reference implementation:

We’ve published a complete implementation of this detection approach as an open-source solution. The solution deploys a Lambda function that discovers CNAME records across all your Route 53 hosted zones and uses pattern matching to identify targets pointing to S3, CloudFront, and Elastic Beanstalk. It then queries your AWS Config inventory to verify whether each target resource still exists in your account. When a dangling record is detected, the solution generates a HIGH severity finding in Security Hub and can optionally send SNS notifications to alert your security team. A CloudWatch metrics dashboard is also included for ongoing compliance tracking.

Deployment:

# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection

# Build the Lambda deployment package
./scripts/package.sh

# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/

# Deploy the CloudFormation stack
aws cloudformation deploy \
  --template-file infrastructure/template.yaml \
  --stack-name dangling-dns-detection \
  --parameter-overrides \
      LambdaCodeS3Bucket=YOUR_BUCKET \
      EvaluationFrequency=TwentyFour_Hours \
  --capabilities CAPABILITY_NAMED_IAM

The stack creates an AWS Config custom rule that runs on your specified schedule (default: every 24 hours), evaluating all CNAME records and reporting compliance status.

Mitigating the effects

Mitigating subdomain takeover requires both preventive procedures and responsive capabilities.

Prevention: Standard operating procedure

The most effective mitigation is a standard operating procedure for resource deprovisioning that ensures DNS records are removed before the underlying resource:

1. Within your DNS zone, delete the CNAME record that points to the fully qualified domain name (FQDN) of the resource that you plan to deprovision.
2. Wait for the DNS TTL to expire before deleting the resource. DNS resolvers cache records for the duration of the TTL (for example, a TTL of 3600 means resolvers may serve the old record for up to one hour). If you delete the resource before the TTL expires, a threat actor could claim the resource name while cached CNAME entries are still directing traffic to it.
3. Deprovision the resource that you no longer want to use.
4. Run a DNS check of the CNAME record that you removed to verify that the resource is no longer resolving.

Key principle: Always delete DNS first, wait for the TTL to expire, then delete the resource. This order eliminates the window where a dangling record could be exploited.

Prevention: S3 account regional namespaces

As mentioned earlier, AWS introduced account regional namespaces for Amazon S3 general purpose buckets in March 2026. While this is a meaningful step toward mitigating the S3-specific takeover vector, there are important operational limitations to be aware of:

Existing buckets are unaffected. Buckets already created in the global namespace cannot be migrated to an account regional namespace. The bucket names remain globally unique and claimable by anyone if the bucket is deleted.

Global namespace is still the default. When creating a new bucket through the console, CLI, or SDK, the global namespace remains the default selection. Users who aren’t aware of the new option will continue creating globally-scoped buckets.

Existing IaC templates require updates. Existing infrastructure-as-code templates (CloudFormation, CDK, Terraform) that don’t explicitly opt in to the account regional namespace will continue provisioning buckets in the global namespace. For CloudFormation, this means setting the BucketNamespace property to account-regional. For other IaC tools, consult their documentation for the equivalent configuration. Organizations need to audit and update their templates to opt in.

For these reasons, the dangling DNS detection approach described in this post remains critical – particularly for organizations with existing S3 infrastructure, and for CloudFront, and Elastic Beanstalk resources where no equivalent namespace scoping exists.

Response: Notification and remediation

When a dangling DNS record is detected, the reference solution described in the Detection section automatically creates a HIGH severity finding in AWS Security Hub and reports the CNAME record as NON_COMPLIANT in AWS Config. If you provide an SNS topic ARN during deployment, the solution also sends notifications to alert your security or operations team via email, Slack, or other channels. For production environments, consider a human-in-the-loop workflow where these notifications are reviewed by a team member who approves the DNS record deletion before it’s executed. This prevents accidental deletion of legitimate records during transient issues.

The reference solution also includes a CloudWatch dashboard for tracking compliance status and evaluation metrics over time, giving your team ongoing visibility into DNS health across your hosted zones.

Note: Fully automated remediation (auto-deleting DNS records) carries risk – a false positive could disrupt legitimate services. We recommend starting with detection and notification, then evaluating automation based on your detection accuracy and operational maturity.

Conclusion

Subdomain takeover is a preventable misconfiguration that can have significant impact on your organization. A layered defense approach provides the best protection:

Prevention: Implement a standard operating procedure that deletes DNS records before deprovisioning the underlying resource.

Detection: Use AWS Config custom rules to proactively identify CNAME records pointing to resources that no longer exist in your account.

Response: Configure notifications through SNS or Security Hub so your team can respond quickly when dangling records are detected.

Monitoring: Maintain ongoing visibility through CloudWatch dashboards to track DNS health and compliance status.

The key insight is that good DNS hygiene – knowing when your CNAME records point to a nonexistent resource – is your first line of defense. Automated detection through AWS Config provides a safety net when operational procedures fail. And if you detect an issue, having a playbook ready to enact your response can lower the impact and your mean time to recovery.

If you have feedback about this post, submit comments in the Comments section below.

Attackers can move from access to exfiltration in 72 minutes. Learn how modern SOC teams close the speed gap with Unit 42's AI-driven automation, threat hunting, MDR and Managed XSIAM.

The post Inside the Modern SOC: The 72-Minute Race appeared first on Unit 42.

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.

Shadow AI is no longer a theoretical risk. Employees are adopting AI tools faster than security teams can track them, often without IT’s knowledge, and frequently on devices and surfaces that traditional security tools simply can’t see. If you asked your security team right now how many AI tools are active across your organization, on which surfaces, and what’s being shared, could they answer? For most organizations, the honest answer is no. And that gap, between what your employees are doing with AI and what your security team can actually see, is where enterprise risk lives today.  AI adoption in the enterprise didn’t slow down and wait for governance to catch […]

The post The AI Your Security Team Can’t See Is the One You Should Worry About appeared first on Check Point Blog.

Palo Alto Networks is pleased to announce the successful completion of a new Cloud Medium security assessment conducted by the Canadian Centre for Cyber Security (Cyber Centre), significantly expanding the number of Palo Alto Networks cloud services assessed for Protected B / Medium Integrity / Medium Availability (PBMM) environments. This assessment includes a broad range of capabilities across our Cortex®, Cortex Cloud and Strata™ platforms. By achieving this milestone, Palo Alto Networks enables  organizations handling Canada’s most sensitive data to leverage a unified, AI-driven security architecture without compromising on compliance or operational resilience.

For years, many organizations viewed PBMM as something that only mattered to the Canadian federal government. It was often seen as a procurement requirement—a framework tied to public sector cloud adoption, relevant for departments handling Protected B information, but not necessarily for the private sector.

That assumption is changing.

The reality is that the challenges driving PBMM are no longer unique to government environments. Banks, energy providers, transportation networks, healthcare organizations, crown corporations, and other critical infrastructure operators are now facing many of the same pressures:

• Expanding attack surfaces across hybrid and multi-cloud environments.
• Increased regulatory scrutiny and privacy obligations.
• Greater operational dependence on cloud and AI technologies.
• Increased reliance on third-party providers and software supply chains.
• The need to maintain operational resilience during cyber incidents and disruptions.
• A growing expectation that organizations can demonstrate—not just claim—security maturity.

That is why PBMM matters far beyond Ottawa. At its core, PBMM represents a rigorous approach to validating whether enterprise-grade security platforms can operate securely in environments where trust, resilience, and operational continuity are critical.

Increasingly, that level of assurance matters to everyone.

What PBMM Really Represents

PBMM, a rigorous cybersecurity and data classification standard used by the  Canadian Centre for Cyber Security, stands for Protected B / Medium Integrity / Medium Availability. While often associated with federal cloud security requirements, PBMM is not simply a checkbox exercise. It is a comprehensive assessment framework aligned to Canadian cybersecurity guidance and operational security expectations.

What makes PBMM important is that it evaluates whether platforms and services can securely support sensitive and mission-critical workloads in real-world environments.

Palo Alto Networks meeting these rigorous PBMM requirements through three core pillars:

• Strata (Network Security): Secures data resiliency and zero trust connectivity, driving robust perimeter and cloud edge protection.
• Cortex Cloud (Cloud Security): Provides complete visibility, security governance, and data protection across complex cloud-native architectures.
• Cortex (Security Operations): Powers the agentic SOC, combining unified data, AI, and automation to detect and respond to threats in real time.

These are not theoretical requirements. They are practical operational expectations designed for environments where downtime, visibility gaps, or security failures can have significant consequences.

Organizations today are no longer evaluating cybersecurity solely based on features. They are evaluating whether platforms can be trusted to support critical operations at scale.

Why Security Expectations Are Changing

The cybersecurity landscape has evolved dramatically. Infrastructure is distributed across cloud providers, SaaS applications, remote users, third-party integrations, operational technology (OT), AI platforms, and interconnected supply chains. At the same time, attacks have become faster, more automated, and more disruptive.

In this environment, security can no longer be treated as a compliance exercise. Organizations need confidence that their platforms, operational processes, and security controls can function effectively under pressure.

This is why Palo Alto Networks has undertaken independent PBMM assessments across its portfolio, providing customers with greater assurance and trust. By meeting these rigorous standards into Strata and Cortex, we enable non-government entities—like financial institutions and utility providers—to deploy the same defensive rigor used to protect national security systems.

Transforming Critical Infrastructure with a Unified Platform

To effectively manage risk, critical infrastructure operators require a platform approach that helps eliminate security silos, reduce manual intervention, and accelerate threat mitigation.

Key Portfolio Advantages for Critical Infrastructure & Enterprise:

• AI-Driven Threat Detection & Response: Cortex XSIAM® and Cortex XDR® unify telemetry across endpoints, network, and cloud to deliver unparalleled visibility and automated threat stitching, neutralizing advanced cyberthreats before they disrupt operations.
• Comprehensive Cloud Native Protection: Cortex Cloud secures applications from code to cloud to SOC, offering posture security, data protection, and continuous compliance monitoring tailored to stringent Canadian data standards.
• Zero Trust Network Security: Strata enables secure access and consistent policy enforcement across campus, branch, and data center environments, protecting critical OT and IT systems from lateral threat movement.
• Elite Incident Response: Backed by Unit 42®, organizations gain access to threat intelligence and rapid incident response services to augment their teams and build long-term cyber resilience.

Operational Resilience Is Becoming a Strategic Requirement

One of the most significant shifts occurring across industries today is the growing focus on operational resilience. Organizations are increasingly asking questions that extend beyond traditional cybersecurity controls:

• Can we maintain critical services during a cyber attack?
• Do we have visibility across our cloud environments and supply chain dependencies?
• Can we rapidly detect, respond to, and recover from disruptions?
• Are our governance processes keeping pace with cloud adoption and AI innovation?

As organizations adopt cloud-native architectures, AI-driven technologies, and interconnected digital ecosystems, resilience has become a board-level concern. The ability to prevent incidents remains important, but organizations are equally focused on their ability to withstand, respond to, and recover from them.

This is where frameworks like PBMM provide value. Beyond evaluating security controls, PBMM assesses the governance, operational processes, monitoring capabilities, and risk management practices that help organizations operate securely.

For critical infrastructure operators, resilience is no longer simply an IT objective—it is a business imperative. Increasingly, the organizations that earn trust are those that can demonstrate they are prepared to operate effectively when disruption occurs.

Final Thoughts: PBMM Reflects the Future of Trust

PBMM may have started solely as a government assessment framework, but its relevance now extends far beyond federal environments. It represents something universal: the ability to operate securely, reliably, and transparently in environments where trust matters most.

By expanding our PBMM-assessed offerings across Cortex and Strata, Palo Alto Networks underscores its commitment to securing Canada's digital future. We provide the validated foundation organizations need to innovate with confidence, protect sensitive data, and maintain operational continuity under any circumstance.

Read the Assessment Summary Report

To learn more about the Palo Alto Networks Cloud Medium security assessment, review the publicly available assessment summary report issued by the Canadian Centre for Cyber Security.

Ready to modernize your defenses with PBMM-assessed solutions? Schedule a demo with our team or contact Unit 42 to learn how we can help elevate your organization's resilience against emerging cyber threats.

The post Securing Canada’s Digital Future: Why PBMM Matters Beyond Government appeared first on Palo Alto Networks Blog.

The model behind a security workflow shapes how fast a threat is caught, how accurately an incident is investigated, and how much a defender can trust the result. We treat that choice with care. Today we’re taking a clear step forward: Check Point has joined OpenAI’s Daybreak initiative through its Trusted Access for Cyber (TAC) program. These are real steps in how we bring AI into our defensive operations, and in the security we deliver to our customers. What Trusted Access for Cyber Gives Us Trusted Access for Cyber is OpenAI’s program for vetted security organizations that need its most […]

The post Check Point Joins OpenAI’s Trusted Access for Cyber Program and Daybreak Initiative appeared first on Check Point Blog.

Key Findings:   Check Point Research identified a critical vulnerability chain in LangGraph, an open-source framework from the creators of LangChain that enables developers to build complex, stateful, and controllable AI agent workflows using LLMs; they have approximately 46.5 million monthly downloads, making it one of the most widely adopted AI agent platforms in the world An SQL injection in LangGraph’s function could allow attackers to gain full control via remote code execution of a server by exploiting weaknesses in how the system processes and handles data. A compromised LangGraph server exposes everything the agent touches, including LLM API keys, customer data, CRM credentials, conversation history, and internal network […]

The post When Your AI Agent’s Memory Becomes a Security Liability appeared first on Check Point Blog.

He walked into the lobby with a fake badge clipped to his shirt. He had bought it online the week before. It was not perfect, and it did not need to be. From a few feet away, it looked close enough: a logo, a name, a photo, and a lanyard. The kind of thing most people glance at for half a second before their brain decides, “Looks fine.”

The post The Art of the Badge: A Hard Truth About Physical Security appeared first on Black Hills Information Security, Inc..

Frontier AI is moving faster than most governance and response systems were designed to handle.

The corporate landscape across the Japan and Asia-Pacific (JAPAC) region is facing an unprecedented regulatory and operational reckoning. The rise of hyper-autonomous ‘frontier’ AI models is pushing cyber security out of human hands and into a real-time war of machine against machine. This shift has triggered a highly coordinated enforcement wave cascading through JAPAC’s premier digital hubs, where regulators and enterprises are moving in lockstep to address machine-speed threats. 

With corporate watchdogs Australian Prudential Regulation Authority (APRA) and Australian Securities and Investments Commission (ASIC) firing warning shots via urgent market letters, and neighbouring authorities like the Monetary Authority of Singapore and South Korea’s central government enacting strict new AI safety rules, organisations are being forced to completely overhaul their defensive architecture. Decades of relying on slower, committee-based governance are being shattered by new threat intelligence showing that autonomous AI agents can now exploit vulnerabilities and exfiltrate critical data within minutes—turning traditional 72-hour regulatory reporting windows into mere post-mortems.

The warning comes as the gap between corporate readiness and technological reality widens right across the JAPAC corridor. Much of the region’s current governance and cyber risk architecture still reflects a legacy system engineered for predictable, slower-paced environments. We have spent years building risk models where vulnerability discovery, incident escalation, and defensive response unfold gradually enough for traditional executive oversight and committee structures to remain effective. But that comfortable pace has officially vanished.

The Machine-Speed Reality

The sheer velocity of this shift was highlighted during restricted testing of Anthropic’s advanced frontier model, Claude Mythos, under an initiative known as Project Glasswing. Palo Alto Networks was among a select group of technology and cyber security organisations chosen to evaluate the implications of the model before its broader release. Mythos demonstrated an unprecedented capability to identify and exploit vulnerabilities across major operating systems at a level matching or exceeding advanced human experts.

During combined testing involving Mythos, Claude Opus 4.7, and OpenAI’s GPT-5.5-Cyber, the real-world impact of machine speed became starkly visible. In a single month, Palo Alto Networks disclosed 26 Common Vulnerabilities and Exposures (CVEs) representing 75 distinct issues, a massive surge compared to a typical monthly volume of fewer than five CVEs.

While discovering flaws at that scale would historically have raised uncomfortable questions around software quality, the landscape has fundamentally shifted. In this new era, radical transparency, paired with the ability to reflect and act instantly, has emerged as a critical corporate superpower. Frontier AI is accelerating both sides of the digital chessboard simultaneously: while attackers are gaining unprecedented speed, defenders are gaining a level of visibility that simply did not exist a few years ago. Real-time warfare between AI defenders and AI attackers is rapidly becoming the standard operating model.

AI Agents: The New Corporate ‘Insiders’

This shift introduces a profound dilemma for corporate leadership. Recent regulatory guidance repeatedly emphasises the necessity of human supervision, and for good reason—ultimate accountability must always remain with people. Boards must still set risk appetite, Chief Information Security Officers (CISOs) must determine operational thresholds, and security teams must decide how much authority autonomous systems should hold inside critical environments.

However, organisations must now look a step further. Autonomous AI agents—operating on behalf of employees, suppliers, or automated workflows—are quickly becoming the new corporate ‘insiders’. If not managed with extreme care, they represent massive, systemic blind spots.

Current identity and access frameworks are starting to buckle under the strain because they were never built to distinguish between human users and autonomous agents acting on their behalf. Traditional identity systems assume a predictable human pattern: a user authenticates, requests access, and operates within set boundaries. Autonomous agents, by contrast, interact continuously with APIs, generate code on the fly, move fluidly across workflows, and operate with delegated authority from trusted users.

When these agents begin operating deep inside critical infrastructure, financial services, or government workflows, the risk profile changes entirely. Security teams are no longer just dealing with stolen passwords or human misuse; they are managing autonomous systems capable of acting at machine speed across highly interconnected environments, with potentially devastating consequences if control is lost.

The Failure of the 72-Hour Window

This acceleration has effectively broken traditional regulatory reporting timelines. Recent threat observations from Unit 42 reveal that in approximately 20 percent of modern breaches, attackers successfully exfiltrate data within the very first hour of a compromise.

When data theft occurs inside 60 minutes, a 72-hour reporting window ceases to function as an effective defense mechanism. Instead, it becomes a post-mortem.

For example Australia’s current reporting obligations—including those under the SOCI Act, CPS 234, and the Privacy Act—were largely designed for static environments where defenders had sufficient time to investigate, escalate internally, and coordinate remediation before damage spread. Today, many CISOs quietly acknowledge the immense operational strain created by overlapping reporting frameworks during a live crisis. In the chaotic early stages of a compromise, security teams frequently find themselves managing compulsory reporting requirements from different regulators while their engineering teams are still actively trying to contain a fast-moving incident.

A Region-Wide Regulatory Reckoning

Australia is far from alone in this challenge. The regulatory anxiety echoing through the halls of APRA and ASIC is part of a highly coordinated, region-wide crackdown across the Japan and Asia-Pacific (JAPAC) tech corridor. As frontier models shrink the ‘time-to-exploit’ to near zero, neighbouring digital economies are rapidly realising that their legacy frameworks are equally vulnerable.

In Singapore, the regulatory response has been immediate. The Cyber Security Agency (CSA) recently issued a stark advisory warning that advanced frontier models can examine complex codebases and automate attacks faster than human developers can write patches. In lockstep, MAS finalised its Guidelines on AI Risk Management. Under these new rules, financial institutions are now mandated to perform continuous ‘AI Cyber Stress Testing’— requiring boards to prove that complex, autonomous AI-to-AI interactions within their systems won't trigger an unmanageable domino effect.

Meanwhile, South Korea has shifted from guidelines to hard law. The nation's landmark AI Basic Act (Framework Act on Artificial Intelligence) has officially entered into force, creating strict compliance mandates, mandatory data audits, and extraterritorial penalties for any enterprise deploying high-impact AI systems without ironclad human guardrails.

Across JAPAC, a uniform regulatory shift is underway: voluntary AI ethics frameworks are being replaced by proactive, real-time enforcement measures. 

Moving with Discipline

Organisations broadly acknowledge that AI demands a distinct approach, yet implementation gaps remain. Businesses must move away from managing AI like standard software and instead commit the significant defensive resources needed to protect complex AI supply chains. 

The language coming from regulators reflects these exact challenges. ASIC Commissioner Simone Constant warned that frontier AI capability could expose vulnerabilities at unprecedented speed and scale, creating systemic consequences across entire sectors. Her message to corporate Australia was direct: do not wait for perfect clarity to address the threat posed by new AI models. Instead, organisations must act now, and act with discipline, to strengthen the cyber resilience fundamentals that underpin their businesses.

The testing conducted within Project Glasswing ultimately proved that while frontier models can expose weaknesses at terrifying speed, that exact same capability can be weaponised defensively. By deploying AI to reduce exposure and identify vulnerabilities before adversaries can operationalise them, organisations can effectively level the playing field.

The most resilient organisations over the next few years will be those that combine real-time frontier AI defensive capabilities with disciplined human supervision, rather than treating the two as separate priorities. In the era of machine-speed warfare, you cannot successfully have one without the other.

To learn more about how we are securing the frontier of technology, visit the Palo Alto Networks Trust Center and explore the latest threat insights from Unit 42.

The post Beyond Human Oversight: Adapting to the Frontier AI Era appeared first on Palo Alto Networks Blog.

The release of OMB Memo M-26-14 ("Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats") marks a historic turning point in federal cybersecurity. By officially rescinding the M-21-31 directive, the White House has delivered a clear message to federal IT leaders: the era of compliance-driven data hoarding is officially over.

While the previous framework was a well-intentioned response to the SolarWinds breach, its mandate to collect and retain vast oceans of unstructured logging data created unintended, unsustainable operational burdens. For the past several years, federal agencies have faced skyrocketing cloud storage bills and overwhelmed Security Operations Centers (SOCs). Crucially, they have been left with vast quantities of cold data that lacked clear operational utility.

As OMB noted, retaining endless data without operational focus is neither cost-effective nor operationally feasible. With M-26-14, the federal government is pivoting to a smarter, sleeker, and far more decisive strategy: a risk-based, prioritized logging framework driven by AI and machine-speed defense.

The Core Shifts: What Federal Leaders Must Understand

M-26-14 strips away administrative "red tape" to focus on how modern cybersecurity risks have evolved. Nation-state threat actors are actively leveraging advanced automation and Artificial Intelligence (AI) to orchestrate attacks at unprecedented speeds. They move laterally across agencies in minutes, hiding behind legitimate corporate credentials.

To beat machine-speed threats, your data layer must operate at machine-scale. The new memo reorganizes federal visibility around two foundational pillars:

1. Continuous Event Monitoring — Owning the Present

Continuous Event Monitoring demands that logging infrastructure shift from a passive archiving tool to a live-streaming asset. Agencies are now required to monitor network and asset activity in real time, rapidly flag anomalous behavior via behavioral analytics, and initiate immediate mitigation actions directly through their SOCs.

2. Threat Hunting, Investigation, Response, and Forensics — Dominating the Post-Compromise

When a compromise is suspected, agencies can no longer spend days running slow database queries or pulling disconnected csv files. M-26-14 mandates that agencies keep 6 months of logs "hot and searchable" and 1 year fully "retrievable." This allows defenders to immediately stitch together cross-domain attack patterns, perform rapid root-cause forensics, and share threat intelligence seamlessly with CISA and the FBI.

3. Expanding the Blast Radius: Entering IoT and OT

Perhaps the most significant structural change is the explicit inclusion of Internet of Things (IoT) and Operational Technology (OT) systems. Adversaries do not respect the boundary between your corporate IT network and your physical infrastructure. Under M-26-14, your logging and threat-hunting capabilities must aggressively cover the entire enterprise—from public cloud workloads to the physical facility controls and critical infrastructure grids running on an agency's behalf.

The Clock is Ticking: The Aggressive Maturity Deadlines

Agencies cannot afford a passive approach. The timeline established by OMB M-26-14 moves quickly:

• T+90 Days: CISA will publish the new Logging Reference Architecture (LRA) codifying hybrid/centralized deployments, Zero Trust Maturity Model (ZTMM) integration, and AI-driven monitoring guidelines.
• LRA +90 Days: Agencies must submit their comprehensive Agency Logging Plans.
• LRA +120 Days: Achieve Basic Level 1 Maturity.
• LRA +180 Days: Achieve Intermediate Level 2 Maturity.
• LRA +320 Days: Achieve Advanced Level 3 Maturity (Advanced/Optimal Effectiveness).

Activating OMB M-26-14 with Palo Alto Networks Cortex

Trying to retrofit a legacy SIEM architecture to meet the advanced or optimal effectiveness tiers of M-26-14 is an engineering and budgetary dead end. Legacy SIEMs scale costs linearly with ingestion and rely on static, human-written correlation rules that fail against AI-fueled threats.

The FedRAMP Certified Palo Alto Networks Cortex platform—anchored by Cortex XSIAM (Extended Security Intelligence and Automation Management)—was engineered from the ground up to solve the exact problems this new memo addresses.

From Disconnected Columns to Cross-Domain "Stitching"

Legacy logging stores data in isolated silos. An analyst trying to track an adversary has to manually look at an identity log, cross-reference it with a network firewall alert, and match it to an endpoint execution.

Cortex XSIAM features a revolutionary Analytics Engine that automatically stitches multi-vendor logs across cloud, network, endpoint, and identity at the moment of ingestion. It transforms raw text into a single, cohesive, context-rich story, instantly aligning incidents with the MITRE ATT&CK framework.  Cortex XSIAM doesn’t just ingest data, it understands the data which enables stitching of multiple data elements into a single, multi-context construct which accelerates analysis via AI and machine learning.

Replacing Static Rules with Cloud-Scale AI

Adversaries use AI to evade signature detection. Cortex XSIAM fights fire with fire, applying out-of-the-box, unsupervised machine learning models to baseline normal behavioral patterns across your entire federal enterprise. When an anomalous lateral movement, data exfiltration attempt, or credential abuse event occurs, XSIAM flags the threat instantly—without requiring your team to spend weeks writing custom correlation code.

Accelerating Continuous Event Monitoring (CEM) and Threat Hunting, Investigation, Response and Forensics (THIRF)

There is more to CEM than just monitoring network activity.  Activity on endpoints, within your identity management solution(s) and in the cloud are just as important.  Understanding the data, knowing which log records are related to each other across multiple log sources, which events are relevant and the context they provide is required.  

Understanding these events and their contextual relationships is fundamental to providing THIRF in an efficient manner.  Cortex XSIAM provides over 2,900 machine learning models out of the box, models that are trained on the data in your environment so they detect anomalous activity based on what is “normal” in your environment, not trained on generic data from other customers or a lab.  These models can identify threats based on data stitched together from multiple sources to provide a more complete context yielding more accurate and consistent results while decreasing time to value.

Securing the Unmanageable: Agentless IoT/OT Defense

You cannot install an EDR logging agent on a smart building HVAC system or an industrial programmable logic controller (PLC). Palo Alto Networks utilizes non-disruptive, passive network analysis to continuously discover, profile, and generate high-fidelity security logs for IoT and OT infrastructure. These logs stream directly into XSIAM, eliminating critical federal blind spots and protecting your High Value Assets (HVAs) from cross-boundary pivot attacks.

Solving the Storage Conundrum Safely

Keeping six months of high-velocity event logs fully "hot and searchable" under a traditional database indexing model creates a crushing financial burden. Cortex XSIAM fundamentally resets the Total Cost of Ownership (TCO) equation by leveraging an index-free, cloud-native data lake architecture that decouples storage costs from analytical performance. By eliminating legacy ingestion taxes and infrastructure overhead, federal defenders can search petabytes of data in seconds—effortlessly meeting the 6-month searchable and 1-year retrievable thresholds. Furthermore, integrated data masking rules strip away sensitive PII or low-value data noise before it hits the SOC, ensuring agencies only pay for operationally vital intelligence.

The Bottom Line for Federal Leaders

OMB M-26-14 is a massive step forward for federal cybersecurity. It frees CISOs from the operational gridlock of untargeted data archiving and empowers them to build faster, modern, and highly responsive security operations.

Meeting the strict 120-to-320-day maturity milestones requires moving past the tools of the last decade. By partnering with Palo Alto Networks and deploying the Cortex suite, federal agencies can seamlessly transition into a risk-aligned, AI-driven SOC. They can confidently check the box on OMB compliance while achieving what the directive actually intends: protecting the resilience and integrity of the federal mission at machine speed.

Palo Alto Networks’ Cortex XSIAM is FedRAMP certified at both the moderate and high levels.

Want to learn more about how to structure your upcoming Agency Logging Plan to meet CISA's upcoming Logging Reference Architecture? 

Contact the Palo Alto Networks Federal Team today to schedule an architectural deep-dive.

The post Shifting from Data Hoarding to Active Defense: Navigating the New Era of OMB M-26-14 appeared first on Palo Alto Networks Blog.

Read all about the latest AWS security features, compliance updates, and hands-on resources in our new, monthly digest posts. You’ll find expert blog posts, new service capabilities, code samples, and workshops.

This month’s AWS Security Blog posts covered AI security, network protection, identity management, compliance frameworks, and supply chain security. Read on for practical guidance on securing agentic AI workflows, filtering network traffic by category, defending against supply chain attacks, and more.

Security posture improvement in the AI era
Author: Celeste Bishop | Published: May 1, 2026
Learn to use the Security Health Improvement Program (SHIP) to strengthen security fundamentals across 10 core use cases for confident AI adoption.

Enabling AI sovereignty on AWS
Author: Stéphane Israël | Published: May 12, 2026
Learn how AWS delivers control and choice across the AI stack to help customers meet digital and AI sovereignty requirements.

The AWS AI Security Framework: Securing AI with the right controls, at the right layers, at the right phases
Authors: Riggs Goodman III, Christopher Rae | May 15, 2026
A structured framework that helps security leaders align the right security controls to the right AI use case, at the right layer, at the right deployment phase.

Why Policy in Amazon Bedrock AgentCore chose Cedar for securing agentic workflows
Authors: Liana Hadarean, Jean-Baptiste Tristan | May 20, 2026
Learn how Cedar’s deterministic authorization, automated reasoning, and formal verification capabilities secure agentic AI tool invocations through Amazon Bedrock AgentCore Gateway.

Securing open proxies in your AWS environment
Author: Dodd Mitchell | Published: May 4, 2026
Learn to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP reputation, and control costs.

Introducing AI traffic analysis dashboards for AWS WAF
Authors: Christopher Jen, Eitav Arditti, Kaustubh Phatak | Published: May 5, 2026
A new dashboard providing visibility into AI bot and agent activity including bot identification, intent classification, and access pattern analysis.

Simplifying policy management with URL and Domain Category filtering on AWS Network Firewall
Authors: Lawton Pittenger, Sofía Aluma-Santos, Eric Fortenbery, Mostafa Elkhouly | May 28, 2026
Learn to use AWS Network Firewall’s URL and domain category filtering to control access to website categories like AI services, manage exceptions for approved domains, and monitor traffic patterns with Amazon CloudWatch Logs Insights.

Regional routing for AWS access portals: Implementing custom vanity domains for IAM Identity Center
Authors: Georgi Baghdasaryan, Laura Reith, Sowjanya Rajavaram | May 14, 2026
Learn to build a custom vanity domain with latency-based routing and automated failover for IAM Identity Center multi-Region access portals.

Automating identity lifecycle and security with AWS Directory Service APIs
Authors: Ali Alzand, Kevin Sookhan | May 21, 2026
Learn to use the new AWS Directory Service Data APIs with Amazon GuardDuty and AWS Step Functions to automate identity lifecycle management and respond to security threats.

Announcing the ISO 31000:2018 Risk Management on AWS compliance guide
Authors: Jesse McMahan, Akanksha Chaturvedi, Mayur Jadhav, Juan Rodriguez, Sana Rahman | Published: May 1, 2026
A compliance guide providing practical guidance for establishing a risk management program using ISO 31000:2018 principles in AWS environments.

New compliance guide available: ISO/IEC 42001:2023 on AWS
Authors: Abdul Javid, Amber Welch, Muhammad Sharief, Jonathan Jenkyn, Satish Uppalapati | Published: May 6, 2026
A compliance guide providing practical guidance for designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.

Introducing the updated AWS User Guide to Governance, Risk, and Compliance for Responsible AI Adoption
Authors: Krish De, Stephen James Martin, Brenda Fong, Kelvin Leung | May 13, 2026
An updated guide providing FSI customers practical considerations for responsible AI adoption across governance, risk management, compliance, data management, and AI agent management.

Governing infrastructure as code using pattern-based policy as code
Authors: Guptaji Teegela, Paul Keastead | May 19, 2026
Learn to use Open Policy Agent (OPA) in CI/CD pipelines to validate AWS infrastructure changes before deployment using recurring control patterns.

Import historical data from AWS CloudTrail Lake to Amazon CloudWatch
Authors: Isaiah Salinas, Erik Weber|Published: May 6, 2026
Learn to import historical data from AWS CloudTrail Lake into Amazon CloudWatch for centralized log analysis.

Automating post-quantum cryptography readiness using AWS Config
Author: Pravin Nair | May 14, 2026
Learn to use the PQC Readiness Scanner to inventory your ALB, NLB, and Amazon API Gateway endpoints and continuously monitor their TLS configurations for post-quantum cryptography readiness.

Detecting and preventing crypto mining in your AWS environment
Authors: Jason Palmer, Nadia Mahmood | May 13, 2026
Learn to use Amazon GuardDuty to identify and mitigate cryptocurrency mining threats in your AWS environment with a multi-layered defense strategy.

Well-architected best practices for software supply chain security
Authors: Trevor Schiavone, Desiree Brunner | May 26, 2026
Learn to apply AWS Well-Architected Framework security best practices to defend against software supply chain attacks like Shai-Hulud using temporary credentials, centralized dependency management, artifact signing, and continuous scanning.

AWS Security Hub Extended: Why enterprise security products should sell themselves
Author: Michael Fuller | May 20, 2026
A thought leadership piece on how AWS Security Hub Extended enables frictionless, pay-as-you-go adoption of curated partner security solutions alongside AWS-native services.

Five ways to use Kiro and Amazon Q to strengthen your security posture
Author: Roger Nem | Published: May 5, 2026
Learn to use Kiro and Amazon Q Developer for security finding triage, infrastructure remediation, security reviews, and service control policies (SCP) development.

AWS Security Agent full repository code scanning feature now available in preview
Authors: Ayush Singh, Daniele Bonadiman | May 12, 2026
Learn to use AWS Security Agent’s full repository code review to perform deep, context-aware security analysis of your entire code base.

Complimentary virtual training: Get hands-on with AWS Security services
Author: Ashley Nelson | Published: May 11, 2026
Security Activation Days are free 3–6 hour virtual workshops providing hands-on practice with AWS security services guided by specialists.

Investigations of reported security vulnerabilities affecting Amazon and AWS services, software, and products.

• Ongoing updates on Copy.fail and variants
• CVE-2026-7791 – Local Privilege Escalation via TOCTOU Race Condition in Amazon WorkSpaces Skylight Agent
• CVE-2026-8178 – Remote Code Execution via Unsafe Class Loading in Amazon Redshift JDBC Driver
• CVE-2026-8596 & CVE-2026-8597: Issue with Amazon SageMaker Python SDK – Model artifact integrity verification issues
• CVE-2026-8686 – Heap out-of-bounds read in coreMQTT MQTT5 property parsing
• CVE-2026-8838 – Remote Code Execution in amazon-redshift-python-driver
• CVE-2026-9133 – Arbitrary file read in rabbitmq-aws plugin
• CVE-2026-9255 – Tool Execution Without Authorization via Piped Stdin in Kiro CLI
• CVE-2026-9291 – Insecure Deserialization in Amazon Braket SDK Job Results Processing
• CVE-2026-10591 – Kiro IDE Insufficient File Write Restrictions to Execution-Sensitive Paths
• CVE-2026-10584 – HTTPS Fallback to HTTP in Graph Explorer

This month brings 8 new AWS samples spanning application security, data protection, infrastructure security, governance, and AI security. From AI-powered security agents on Amazon Bedrock AgentCore to centralized AWS Config monitoring at scale, these repositories help you implement security best practices across your AWS environment.

Schedule AWS Security Agent penetration test
Learn to deploy a AWS CloudFormation template that uses Amazon EventBridge and AWS Step Functions to schedule recurring AWS Security Agent penetration tests with Amazon Simple Notification Service
(SNS) notifications on completion.

Security review assistant
Learn to deploy a multi-agent system on Amazon Bedrock AgentCore that automates Deliverable Security Reviews by combining architecture analysis, IaC code review, ASH vulnerability scanning, and compliance assessment into a single pipeline.

AWS Security Agent Recorder
Learn to use a cross-browser extension that records the unique domains your web app contacts and auto-fills them into the AWS Security Agent penetration test configuration.

KMS access audit
Learn to resolve and report who can use your AWS Key Management Service (KMS) keys across IAM policies, key policies, and grants, with IAM Identity Center resolution to identify the humans behind SSO roles.

Building a conversational AI agent for AWS WAF analysis with AgentCore
Learn to deploy an AI-powered agent using Amazon Bedrock AgentCore and Strands SDK that investigates AWS WAF security incidents, detects bypasses, and generates security reports through natural language.

Centralized AWS Config CI monitoring with Amazon CloudWatch
Learn to centrally monitor AWS Config Configuration Item recording across all accounts in an AWS Organization using CloudWatch Cross-Account Observability, with dashboards showing top resource types, per-account volume, and conformance pack compliance.

CloudFormation Guard security analyzer
Learn to deploy an AI agent powered by Amazon Bedrock AgentCore that scans CloudFormation resource documentation, identifies security-critical properties with risk levels, and generates ready-to-use cfn-guard 3.x rules for your CI/CD pipeline.

Guarded user-controlled attested runtime deployment (Guardian Platform)
Learn to deploy LLM models securely in consumer AWS accounts while protecting model weights using AWS Nitro TPM attestation, KMS envelope encryption, and Zero Operator Access with immutable AMIs.

This month brings 1 new AWS Labs repository focused on governance, helping research institutions deploy secure, tagged infrastructure with self-service access and multi-account controls.

ResearchStack on AWS
Learn to deploy research computing infrastructure on AWS in minutes — Amazon EC2, S3, EFS, Amazon SageMaker AI, and ParallelCluster — with built-in security, cost tracking, and governance using CloudFormation templates and optional AWS Service Catalog.

May 2026 shows AI security maturing from model-level controls to full-stack protection of agentic workflows. The posts and samples provide patterns for policy-based authorization with Cedar, network traffic filtering by category, and cross-account compliance monitoring. The security bulletins address vulnerabilities in SDKs, drivers, and developer tooling. Each resource includes deployment steps or runnable code so you can validate in your own environment before adopting. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.

If you have feedback about this post, submit comments in the Comments section below.

There is a question I have been hearing more and more from CISOs, compliance officers, and security architects over the past year. It does not start with “we had a breach” or “we failed an audit.” It starts with something that sounds almost philosophical:

“Are we quantum-safe?”

A year ago, that question came from the most forward-thinking 5% of our customer base. Today, it is coming from everyone. And that shift, from curiosity to urgency, tells you everything you need to know about where the security industry is headed.

Post-Quantum Cryptography is not a future problem anymore. It is a right now problem. And the customers asking us about it are not being paranoid. They are being smart.

What is post-quantum cryptography? Post-quantum cryptography (PQC) is a new generation of public-key algorithms designed to remain secure against attacks from both classical and large-scale quantum computers. Unlike RSA and elliptic-curve cryptography, which rely on math that a sufficiently powerful quantum computer can break, PQC algorithms are based on mathematical problems that are believed to be hard for quantum machines as well -protecting the data your organization encrypts today from being decrypted in the future.

The “Harvest Now, Decrypt Later” Threat Is Already in Motion

Let us be direct about the threat model, because it is one that does not get nearly enough attention in mainstream security conversations.

You do not need a quantum computer to exist today for your encrypted data to already be at risk.

Sophisticated nation-state adversaries are actively collecting encrypted TLS traffic right now, including your transactions, your authentication sessions, and your sensitive data in transit, with the explicit intention of decrypting it later once quantum computing reaches sufficient capability. This strategy has a name: “Harvest Now, Decrypt Later.” And it is not theoretical. It is happening.

The implication is sobering: the security decisions you make today about encryption determine the confidentiality of data that will still be sensitive in five, ten, or fifteen years. Healthcare records. Financial transactions. Government communications. Intellectual property. Any data with long-term value is already a target for harvesting.

Classical TLS, the encryption backbone of the modern internet, was not built to withstand quantum-scale attacks. The mathematical problems that make RSA and ECC hard to break today become tractable for sufficiently powerful quantum computers. When that threshold is crossed, the encryption protecting decades of harvested data becomes transparent.

This is not a hypothetical edge case. It is a strategic, long-horizon attack that demands a strategic, long-horizon defense.

Our Customers Are Already Asking. We Already Have the Answer.

Here is something I want to be transparent about, because I think it matters.

At Thales, we have been getting questions about PQC readiness from customers consistently and with increasing frequency. These are not fringe inquiries from academic researchers or early adopters chasing the next shiny thing. These are enterprise security teams, regulated industry customers in finance, healthcare, and defense, and compliance officers who are watching the regulatory horizon and doing the math.

They are thinking about it. And they deserve a vendor who is already ahead of it.

That is exactly why I am proud to share what we have built. Thales’ Imperva platform now supports hybrid TLS handshakes combining X25519 and MLKEM768, a pairing of classical elliptic curve cryptography with a quantum-safe Key Encapsulation Mechanism aligned directly with NIST PQC standards. This hybrid approach protects connections between clients and Imperva Points of Presence with both classical and quantum-safe algorithms running simultaneously, ensuring security regardless of which threat model materializes first.

And we did not just build the capability for customers. We completed the migration of all Imperva sites ourselves. We validated it in production before asking anyone else to trust it.

That is what proactive security looks like.

What Hybrid TLS Actually Looks Like in Practice

I know “hybrid TLS handshake” can sound abstract, so let me ground it in something concrete.

When a client connects to a Thales Imperva-protected application today, that TLS 1.3 session is authenticated using X25519MLKEM768, a combined algorithm that you can actually observe directly if you inspect the connection in Chrome’s security panel. You will see exactly what the screenshot above shows: “The connection to this site is encrypted and authenticated using TLS 1.3, X25519MLKEM768, and AES_128_GCM.”

That is not marketing language. That is your browser’s own security panel confirming quantum-safe encryption is active.

What this means practically:

• A classical adversary cannot break the X25519 component
• A quantum-capable adversary cannot break the MLKEM768 component
• Both would need to be broken simultaneously, which represents an effectively impossible bar with current and near-future capabilities

The hybrid model is deliberate and important. Pure PQC algorithms, while mathematically quantum-resistant, are newer and have had significantly less real-world cryptanalysis time than their classical counterparts. The hybrid approach ensures we are not trading one risk for another. We are stacking defenses. This is defense-in-depth applied to cryptography itself.

Zero Performance Trade-off. No Traffic Impact. Full Protection.

Here is the objection I hear almost every time PQC comes up in a customer conversation: “That sounds computationally expensive. What does it do to latency?”

The answer, which genuinely surprises most people: nothing measurable.

Our PQC implementation introduces no performance trade-off and no traffic impact. This matters enormously because one of the most common reasons organizations delay critical security upgrades is the perceived performance cost. Security teams propose the upgrade. Engineering teams push back on latency. The initiative stalls.

With Thales’s PQC implementation, that objection is gone.

Quantum-safe encryption that slows your applications down is not a real solution. It is a compliance checkbox that creates new operational problems while solving a cryptographic one. We were not willing to ship that. The implementation delivers genuine quantum-safe security without the operational tax, and that is the only version of this capability worth deploying at enterprise scale.

The Compliance Horizon Is Closer Than You Think

If the threat model alone is not enough to create urgency in your organization, and for some organizations it is not, that is an honest reality, then the regulatory and compliance landscape should be.

Governments and standards bodies have moved decisively and fast:

• NIST finalized its first PQC standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are no longer drafts. They are published standards.
• The S. White House issued NSM-10 directing federal agencies to inventory cryptographic systems and prioritize PQC migration timelines
• CNSA 2.0 mandates PQC adoption for national security systems with defined timelines
• Financial services regulators in the EU and UK are actively publishing PQC readiness guidance for institutions
• DORA and NIS2 in Europe are tightening cryptographic resilience requirements across critical infrastructure sectors

The direction is unambiguous. Regulated industries, including finance, defense, and healthcare, are going to face PQC compliance requirements. The organizations that begin migration now will meet those requirements ahead of schedule, with time to test, validate, and optimize. The ones that wait will be scrambling to meet deadlines under pressure.

Thales’s PQC support is directly aligned with enterprise and regulated sector expectations today. When your auditor, your regulator, or your enterprise customer asks whether your traffic is quantum-safe, the answer should already be yes.

This Is a Security Evolution, Not a Cryptographic Revolution

I want to address something directly, because the way PQC gets discussed in the media can make it sound like a complete overhaul that requires ripping out and replacing your entire security infrastructure overnight.

That framing is not helpful. And it is not accurate.

PQC is a security evolution. The underlying architecture of TLS, certificates, and encrypted communications does not change. The mathematical primitives powering key exchange and authentication do. For most organizations, particularly those working with a security partner like Imperva that has already done the migration work, the path forward is far more manageable than the “quantum apocalypse” narrative suggests.

The hybrid approach makes this especially true. You do not abandon classical cryptography overnight. You layer quantum-safe algorithms alongside proven ones, maintain backward compatibility where needed, and progressively increase quantum-safe coverage as the ecosystem matures and client-side support expands.

Supporting our customers to be PQC compliant at the start of the year was just one step in that evolution. It is a step we took proactively, before our customers needed to ask twice, because that is what it means to be a security partner rather than just a security vendor.

What You Should Do Right Now

If you are a CISO, a security architect, or a compliance officer reading this, here is where I would focus your energy:

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.