In November 2024 Google reported the first public case of an AI agent, Big Sleep, finding a previously unknown exploitable flaw in real software: a memory-safety bug in SQLite, reported in early October and fixed the same day, before it reached a release [1].

As of 26 August 2026, Anthropic reported 2,300 disclosed vulnerabilities in 392 open-source projects, all found since 1 November 2025. Of these, 421 had been fixed upstream, which is not the same as fixed in every installation [2]. The two programmes are not directly comparable, but the direction is plain enough. Automated discovery is becoming a mass process, but remediation is not.

Attackers have the same tool. In May 2026 Google Threat Intelligence Group described, for the first time, a zero-day which it assessed with high confidence had been found and weaponised with the help of AI [3].

Code in which no vulnerability was known yesterday may contain a confirmed one today, and a working technique for exploiting it tomorrow, without changing by a single line. Finding a vulnerability does not necessarily create an exposure. The appearance of a working technique may.

One Part of the Exposure Is Not Yours

In the previous article (The Anatomy of Exposure: Why the Market Cannot Agree on What Counts as One) I defined an exposure as a combination of an attacker’s starting position, one or more existing conditions, a technique and the target — in short, origin → condition → technique → target. It exists when the target is reachable from that starting position and the technical prerequisites for the technique are satisfied.

The condition and the target belong to your environment. The starting position is defined relative to it, although it can shift as an attack progresses: yesterday the internet, today a stolen VPN account. The technique is the element that moves directly with the attacker’s capabilities.

That article left one question open: when should a technique be treated as applicable? My answer: when there is a working method of carrying it out, not merely a class of attack to which it belongs. Exposure is therefore a function of two changing systems, your environment and the attacker’s capabilities.

Your environment moves too. An upgrade removes one condition and may introduce another; a new route makes reachable what was isolated yesterday; a changed firewall rule opens a path nobody designed. In a working organisation the environment is rarely settled for long.

The practical difference is that one of these systems can at least be watched from inside the organisation, through change management, telemetry and configuration-drift monitoring. The other reaches you only through external signals, and usually late.

None of this turns exposure into a probability. Its existence remains a matter of yes or no; priority is built from other fields, such as observed exploitation, likelihood and the value of the target. But any statement that an exposure exists holds only at the moment of observation. An entry in the ledger is an observation with a date attached.

A change affecting the condition, path, starting position or target leaves the last known state of the exposure in place but removes the confirmation behind it: the record is marked needs_revalidation. The state of the object and the state of our knowledge about it are separate axes and belong in separate fields. The trigger may be a change-management event, a configuration-drift scan, which also catches whatever escaped the formal process, or the expiry of the observation itself.

Until it is checked again, the record counts as active. The count errs on the high side by design: revalidation may confirm the exposure or close it. The expiry of a blocked status produces the same mark with different knowledge behind it: the condition is known to be in place, and only the control is in doubt.

The Threshold

Without a threshold, a “working method” becomes a matter of interpretation, and ledgers kept by different teams will diverge. The threshold I propose is a demonstrated method that carries the attack through to its result and is applicable to the version, configuration and prerequisites present in your environment. For a software flaw that means a functional exploit; a process crash in a test environment does not qualify. For a password-reset procedure it means a rehearsed social-engineering call that gets past the help desk. Publication is not required: a private exploit crosses the threshold as surely as a published one.

The proof may be external, and there is no need to reproduce every public exploit yourself. Applicability, however, is a property of your environment. If a functional exploit has been published for the version you run, the instance is reachable and the prerequisites are met, the exposure exists. You need not attack your own production systems to acknowledge it.

Until a working method exists, there is no exposure — only a vulnerable condition and some probability that a technique will appear, which is a matter for vulnerability prioritisation. CVSS 4.0 draws the same line in its own terms: the lowest level of its Exploit Maturity metric, Unreported, means only that no one has reported a method [4]. Where no assessment exists at all, the standard assumes the worst.

Exists, Observed, Probable

What usually ends up in one field is in fact three different things. A working technique appears, and that decides whether the exposure exists at all. Later it may turn up in real attacks, which is what a CVE’s entry into CISA’s Known Exploited Vulnerabilities catalogue records [5]; threat-intelligence reports and your own incidents say the same. Separately, EPSS may judge exploitation more likely: it estimates each day the probability that exploitation of a given CVE will be observed within 30 days [6].

The second and third change priority, not existence. In the ledger they are three fields, each with its own date:

• feasibility_known_since — when a working method was confirmed;
• observed_since, with source — when and where exploitation was seen;
• likelihood_30d — the current estimate and the date it was calculated.

The first field records when you learned that the method existed. When it actually appeared, you do not know. A private method reaches your ledger by only three routes: threat intelligence, your own validation or an incident. With an incident, and often with an intelligence report, the first two fields acquire the same date, and both are late.

An exposure may therefore exist before it can be recorded. To the ledger it is indistinguishable from absence; to the attacker it is perfectly real. An empty field means “unknown”, not “no”. This is a limitation of the model, and another scanner will not help.

Controls Move Too

A compensating control does not remove the underlying condition. A WAF does not repair SQL injection, an EDR agent does not alter a vulnerable binary, segmentation does not close a CVE and MFA does not abolish a password. A control changes only the ability to use the condition.

That is why, in the previous article, I kept a blocked exposure in the ledger, only in a different column: its state changes, active → blocked, while the record stays. The state has a shelf life, and it can expire in three ways, each found by a different check.

The first is bypass. The control sees the attack but reads it differently from the system it protects. In the WAFFLED study, researchers at Northeastern University and Dartmouth College confirmed 1,207 bypass requests against five widely used WAFs, which parsed HTTP bodies differently from the applications behind them [7]. A retest will find such a failure only with the right request. With the old set it will probably stay green.

The second is surface mismatch. The control works as designed, but the attack passes outside the surface it covers. CVE-2023–4966, known as Citrix Bleed, let attackers steal valid NetScaler session tokens and open a session without a password or second factor [8]. MFA may have been working perfectly; the attack took the state created after it.

The GTIG case is of the same kind. Google described a high-level logic flaw in the two-factor scheme itself: the developer had hard-coded an exception to a trust check, so that anyone with valid credentials could skip the second factor [3]. A test of whether the normal login path demands a second factor could well have stayed green while another path escaped the check. Repeating it will never find the failure; only reconsidering what the control is assumed to cover will.

The third is false evidence, where what fails is the source of the green status. In January 2024 Ivanti issued mitigation guidance for its gateways, and attackers got round it. More serious was what CISA then found in its own laboratory: the accompanying Integrity Checker Tool was insufficient to detect compromise, and root-level persistence could survive a factory reset [9]. Such a failure can be found only through evidence independent of the control.

Four Questions for a Blocked Exposure

If an exposure stays in the ledger after a compensating control is applied, mitigated=true is not enough. For each of the three failures to be detectable, four questions need answers.

1. Source. Who says the technique is blocked: a scanner, the control itself, an independent test, or a person closing a ticket?
2. Date and artefact. When was it last checked, with which test or payload, and has that test been kept?
3. Expiry. How long is the result valid, who is responsible for rechecking it, is the record counted as active once it expires, and how does that affect the count of active exposures?
4. Surface. Which part of the technique does the control actually block, and when was that assumption last reviewed?

The questions are not tests in themselves. Their purpose is to preserve the evidence, its provenance and its expiry, and to bring the coverage assumption into the open.

The fourth is the most difficult. A control may work correctly and protect the wrong surface. The green status is then entirely honest, and entirely useless.

AI Makes a Bad Definition More Expensive

Once machines find vulnerabilities, build attack paths and test controls, it is natural to let them set priorities as well. The danger lies in doing so with a poor definition of what is being counted. Discovery is getting cheap, exploits are quicker to build than they were, and validation can be run far more often. A system that cannot tell these events apart merely replaces a slow error with a fast one.

Anthropic’s dashboard shows where the defender’s bottleneck lies. Its models produced 26,153 candidates over the same period; external security firms reviewed 5,008 and confirmed 4,576. Anthropic names independent human triage as the rate-limiting step, and some confirmed flaws had not yet been reported for that reason [2].

On the attacker’s side the same bottleneck is narrower and cheaper. In a campaign Anthropic described in November 2025, AI performed 80–90 per cent of the tactical work against some 30 organisations, with humans intervening at four to six critical points [11]. In July 2026 Hugging Face disclosed an intrusion into its production infrastructure carried out end to end by an autonomous agentic system: two code-execution paths in the dataset-processing pipeline, harvested cloud credentials, movement across internal clusters [12]. It was nobody’s campaign: the agent was running an internal OpenAI cyber-capability evaluation, and covered the chain in thousands of small automated decisions with no malicious operator behind it [13].

The two sides do not pay the same price for being wrong. The model in the 2025 campaign also made mistakes, including invented credentials [11], but to an attacker a false hypothesis usually costs a failed attempt, at worst a burnt foothold or an alert. To a defender it may cost a production change, developer time or a false blocked status.

So the sequence finding → confirmed condition → applicable technique → exposure can already be traversed almost entirely by AI on the attacker’s side, and in some observed cases end to end. On the defender’s side every step requires evidence, and the more the machine finds, the heavier the burden on those who must act. Human review remains the bottleneck because a defender’s action needs evidence that will stand up afterwards.

Agents also create new conditions for attack. One that finds and fixes vulnerabilities needs data, tools and privileges, and OWASP lists identity and privilege abuse among the principal risks of agentic applications: delegated trust, inherited credentials and role chains used to obtain unauthorised access or actions [10]. The agent is not itself an exposure. It may be a target; its identity may be a condition and its privileges part of a path, all under the same model.

What to Count

A vulnerability tells you what is wrong with a system. An exposure tells you what an attacker can actually use: from which position, by which technique, against which target and in spite of which controls. The two have different lifetimes. A vulnerability exists while the condition remains. An exposure may:

1. appear without any change to the code, because a technique appears;
2. appear or disappear without any change to the code, because reachability, the starting position or the prerequisites change;
3. become blocked without any change to the code, because an effective control is introduced;
4. return, because the control is bypassed, covers the wrong surface or rests on false evidence;
5. become far more important, because the technique spreads among attackers. This alters its priority and leaves its state alone.

These are five different events. Reduce them to one severity score or one ticket status, and the history of the object disappears.

The metric that matters is how long an attack was actually possible. In practice we measure only its observed part, from the first visible event — our own validation, a published exploit, an entry in KEV, an incident — until remediation. The ledger gives a lower bound.

The time a ticket stays open, usually reported as MTTR, measures the process. Observed exposure time measures the part of the attacker’s window that we were able to see or reconstruct.

The server, its IP address and its vulnerable binary may not have changed once in all that time.

All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.

Disclosure: AI tools assisted with source research, draft wording and translation. The ideas, the model and all editorial decisions are the author’s.

References and sources are listed in the appendix. Data current as of October 2026.

Originally published on HackerNoon: [link]

Appendix: A Possible Record Lifecycle

A record is described along two independent axes:

• exposure_state — the state of the exposure according to the latest confirmed evidence: active, blocked or closed;
• verification_state — the state of our knowledge about it: verified or needs_revalidation. Exposure-state transitions
• A working method is confirmed for a reachable condition → create the record as active, verified.
• A compensating control is confirmed → active → blocked.
• A bypass, surface mismatch or false evidence is found → blocked → active.
• Revalidation establishes that the condition has been removed or the target is no longer reachable → closed, with closure_reason: condition_removed, unreachable, target_removed or prerequisites_removed.

Verification-state transitions

• A change affects the condition, path, starting position or target, or the observation or control validation expires → needs_revalidation; exposure_state retains its last confirmed value.
• Revalidation → verified; exposure_state becomes active, blocked or closed according to the result.

Sources

[1] Google Project Zero, From Naptime to Big Sleep:
https://projectzero.google/2024/10/from-naptime-to-big-sleep.html

[2] Anthropic, Coordinated vulnerability disclosure dashboard, snapshot 26 August 2026:
https://red.anthropic.com/2026/cvd/

[3] Google Threat Intelligence Group, AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access, 11 May 2026:
https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access

[4] FIRST, CVSS v4.0 Specification Document, Exploit Maturity (E):
https://www.first.org/cvss/specification-document

[5] CISA, Known Exploited Vulnerabilities Catalog:
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

[6] FIRST, EPSS:
https://www.first.org/epss/

[7] WAFFLED, arXiv 2503.10846:
https://arxiv.org/html/2503.10846v1

**[8]**CISA AA23–325A:
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-325a

**[9]**CISA AA24–060B:
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b

[10] OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026, 9 December 2025, ASI03 Identity and Privilege Abuse:
https://genai.owasp.org/resource/owasp-top-10-for-agentic-application

[11] Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, 13 November 2025:
https://www.anthropic.com/news/disrupting-AI-espionage

[12] Hugging Face, Security incident disclosure — July 2026, 16 July 2026:
https://huggingface.co/blog/security-incident-july-2026

[13] Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, 27 July 2026:
https://huggingface.co/blog/agent-intrusion-technical-timeline

In May 2024, XM Cyber and the Cyentia Institute estimated that a typical organisation had about 15,000 exposures. Fewer than one per cent were vulnerabilities with CVEs [1]. Roughly 80 per cent were associated with identity and credential misconfigurations [1].

These are slightly awkward figures for vulnerability management. The familiar machinery of scanners, patching programmes, SLAs and vulnerability backlogs appears to deal with only a small part of what is now being described as exposure.

There is an awkwardness for exposure management too. A single vulnerability scanner can readily generate tens of thousands of critical findings. Yet the supposedly broader category produces only 15,000 exposures.

The difficulty is mostly one of accounting. The figures are not counting the same thing.

A scanner may count conditions. Another product may count affected assets. A graph-based system may count attack paths. All can put the word exposures above the resulting number.

Until the unit is known, comparison is largely decorative.

The object being counted

For the purposes of this article, four terms need separating.

A condition is a security-relevant state: a CVE, a public bucket, an administrative account without MFA, an excessive IAM permission or an exposed service.

A finding is evidence reported by a tool that such a condition exists. It has a source, an age and, with luck, some measure of confidence. A public bucket discovered by CSPM, DSPM and a cloud audit remains one public bucket. That doesn’t make three buckets.

An exposure is a combination of an attacker's starting position, one or more existing conditions, a technique, and the target — an entity, data set or function — against which that technique can be applied. It exists when the target is reachable from that starting position and the technical prerequisites for the technique are satisfied.

Probability is deliberately absent from that definition. So are target value and the presence of an effective compensating control.

The last omission is important. Suppose a WAF rule completely blocks an exploit. The underlying conditions have not changed. Nor have the attacker origin, technique or target. Disable the WAF rule tomorrow and the same exposure becomes usable again.

The exposure has changed state, not identity.

A blocked exposure therefore remains in the ledger. It belongs in a different column.

Risk is a separate question. It concerns how difficult exploitation is, whether anyone is likely to attempt it and what the consequences would be.

The distinction is less academic than it sounds. An Internet-facing development server with a working exploit is still exposed even if it contains nothing of consequence. Its low value reduces the risk. It does not make the technical opportunity vanish.

Counting the same environment

Consider a short chain:

Internet → public workload → cloud role → secret → production database.

There is a public entry point, excessive permissions on the cloud role and an accessible credential.

A scanner might produce three findings. A platform combining several sources might produce five or seven because some of the same conditions were detected more than once. An asset-oriented product may count affected workloads and identities. A graph system may count the available attack paths.

Another platform may collapse the chain into one exposure: a toxic combination in which several factors together create a problem that none represents on its own [2].

It is therefore quite possible for the same environment to contain 40,000 findings, 8,000 affected assets, 600 attack paths and 900 exposures without any obvious arithmetic error.

The unit has changed.

A larger number does not necessarily indicate better discovery. It may simply indicate finer granularity.

Comparing findings with exposures is rather like comparing notes with melodies.

Reachable from where?

There is another source of disagreement even after two products have decided to count exposures rather than findings or assets.

They may not start the attacker in the same place.

Take BOLA. An authenticated user changes an object ID and obtains another tenant’s data.

Viewed from the unauthenticated Internet, there is no exposure yet; the attacker first needs an account. Viewed from the position of an ordinary authenticated user, the same endpoint and defect are sufficient.

“An attacker cannot reach it” is consequently an incomplete statement. The identity and position of the attacker matter.

Origin belongs in the model: Internet, authenticated user, compromised endpoint, contractor VPN, insider, compromised vendor tenant, or another explicitly defined starting point.

It also matters to deduplication. One CVE on one asset does not necessarily amount to one exposure. A different starting position may create a different opportunity and lead to a different action.

Such distinctions rarely receive much space on product-demo heatmaps. They matter rather more when two numbers are being compared.

A market with several definitions

I reviewed 47 primary sources from analyst firms, platform vendors, attack-path and validation specialists, ratings companies and independent analysts. There is broad agreement on the verbs. Exposures are to be discovered, assessed, prioritised, validated and remediated [3].

The noun is less settled.

Wiz draws the distinction between vulnerability and exposure through reachability. A weakness becomes an exposure when an attacker can actually get to it because of Internet accessibility, excessive permissions, missing compensating controls or similar circumstances. Its analogy is a useful one: a vulnerability is a door with a weak lock; exposure is the same door standing open to the street [4].

XM Cyber counts something rather different: a vulnerable resource combined with a credible threat technique along an attack path [5].

Gartner does not provide a strict standalone definition of the object on its Exposure Assessment Platforms page. It nevertheless refers to “exposures, such as vulnerabilities and misconfigurations”, allowing the underlying condition itself to sit inside the category [6].

The differences are not semantic niceties.

Under the Wiz formulation, exposure resembles a reachable weakness. Under XM Cyber’s, the unit contains both the resource and the attacker technique. Under Gartner’s wording, a vulnerability or misconfiguration may itself be an exposure.

There is no particular reason for those three models to produce the same number when presented with the same estate.

The usual question — which vendor found the correct number of exposures? — is therefore premature. One first needs to know what each vendor has elected to count.

The market has failed to agree on the object. It has had no such trouble with names.

CTEM, EAP, AEV, UVM, TEM, CEM, USEM, UEM, ROC, CREM and CRPM have all appeared [7].

They describe overlapping rather than identical propositions. Some begin with discovery, others with validation or remediation. Boundaries have shifted quickly.

Forrester in 2025 criticised the remediation capabilities of exposure-management products and treated UVM as a distinct field [8]. Within months, attack-surface management, exposure management and UVM were being brought together again under the broader label of proactive security platforms [9].

It may be the consolidation of a mature market. Or of an immature one. On this evidence, the difference hardly matters.

The unit of account remains unresolved either way.

A familiar problem

There is some history here.

The first CVE list, published in September 1999, contained 321 entries. One of the problems it was intended to address was that security-tool vendors used their own measures of vulnerabilities and exposures. Buyers had no common basis for comparing the numbers [10].

CVE supplied a common identifier at the level of an individual vulnerability. Exposure has no obvious equivalent one level above.

It may not acquire one.

An exposure contains judgement in a way that a CVE identifier need not. Someone must decide what constitutes a single unit and when the technical prerequisites are sufficient to treat a technique as applicable. Part of the count is observed; part of it is modelled.

This makes the fate of Cisco Vulnerability Management an interesting footnote. Cisco announced its end-of-sale and end-of-life on 10 December 2025. The product, formerly Kenna, was among the better-known platforms built around CVE prioritisation. Cisco named no replacement [11].

The market grew out of counting CVEs. Twenty-seven years later it still lacks agreement on what, at the next level, should be counted instead.

The count is not the risk

Even a common unit would solve only part of the problem.

XM Cyber said in early 2026 that 74 per cent of identified exposures were dead ends: they did not lead to critical assets [12]. Its 2024 research put roughly 1.5 per cent of exposures on choke points traversed by a disproportionate share of attack paths [13].

A thousand exposures in one environment can therefore be quite unlike a thousand in another.

Removing a single condition from a point shared by hundreds of attack paths may matter more than repairing a hundred unrelated vulnerabilities.

There is nothing wrong with reporting that 5,000 CVEs have been closed. It is a measure of work done. It is not, by itself, a measure of how much attacker opportunity has been removed.

The two are easily confused because both produce numbers.

The missing denominator

Absolute counts also conceal what was observed.

Suppose one company reports 900 active exposures and another 300. That doesn’t make the second company safer.

The first system may observe 95 per cent of the relevant declared infrastructure while the second observes 30 per cent.

The smaller number then becomes less impressive.

No finding does not mean no condition. It can also mean no data.

An exposure count therefore needs a denominator. At a minimum, a useful number should say what is being counted and how much of the declared scope is actually visible to the system.

A fall from 900 exposures to 500 could be the result of an effective remediation programme.

It could also mean that a connector failed yesterday.

The dashboard may look better in both cases.

Five questions

Before comparing two exposure-management products, I would want five things made explicit.

1. The unit. What does one record represent: a condition, a finding, an affected asset, an attack path or a normalised exposure? If it is an exposure, how is it constructed?
2. Identity. Which fields make two observations the same exposure? If three scanners report the same condition, is that one record or three? If an asset is reclassified as Tier 0, has the exposure changed or merely its risk?
3. Origin. Where does the attacker start, and is that position stored in the model? Is an opportunity from the Internet the same exposure as one from a compromised endpoint?
4. State. If a compensating control completely blocks the technique, does the exposure disappear, become blocked or remain active? The terminology is secondary. What matters is whether existence and state are treated separately.
5. Coverage. How much of the declared scope is actually observed, and what happens to the count when a data source disappears?

Those answers tend to explain the difference between 40,000 exposures in one product and 900 in another more effectively than a discussion of whose algorithm is more sophisticated.

The useful question is a simpler one:

What do you count as one?

Until there is a common answer, two exposure dashboards can disagree without either being wrong.

They may simply be keeping different books.

Sources and references are provided in the appendix. Data current as of September 2026.

All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.

Originally published on HackerNoon: [link]

0. Introduction

Ten of the eleven public security vendors I tracked moved into AI Security between July 2024 and July 2026. Of the 66 companies in the Broader Sample, eight did. In Exposure Management the picture is reversed: three of 11 against 14 of 66. Same market, two different maps — and where they diverge says more than where they agree.

Part 1 argued that NGFW is no longer the architectural center of security decisions. Part 2 examined that argument across nine vendors. Part 3 asks a narrower question. It does not measure the architectural role of NGFW directly; it looks at where security vendors have committed new resources, and whether those commitments are accumulating in the data, Identity, Exposure, Data Protection, and AI capabilities that provide context beyond an individual control.

The analysis uses four observation layers, with closed M&A and generally available product launches as the strictest measure of Action. Three directions show the strongest convergence across the evidence. Three others remain unresolved.

This material was prepared in summer 2026, using data available up to 28 July 2026.

1. Executive Summary

I tracked 77 security companies between July 2024 and July 2026: 11 large public vendors and a Broader Sample of 66 companies. The study also covers 3,075 conference talks, 31 forecast documents from 19 organizations, and patent material. For Action, the filter is deliberately strict: only closed acquisitions and products that reached general availability. Among TOP-11, this produced 34 closed M&A transactions and 33 GA launches.

None of these datasets measures customer adoption. Action and Expo are mainly supply-side signals; Narrative and conference talks show what the industry is discussing; patents are used only as evidence of technical work. The article therefore describes where vendors are committing resources and where the industry is directing attention, not where customers are already spending most of their money.

Three directions stand out across several layers.

Data Security Analytics (DSA) has the broadest Action footprint: 10 of 11 TOP-11 vendors and 30 of 66 companies in the Broader Sample. It is an analytical cluster rather than a purchasing category — the definition matters for reading the number, and I return to it in Section 3.3. Large platforms expand it through both acquisitions and internal development; smaller vendors rely much more heavily on new products. AI Security is much more platform-led. Ten of 11 TOP-11 vendors launched qualifying products and seven also used M&A, against eight of 66 companies in the Broader Sample. Conference attention rose sharply and Expo presence doubled. The Action category here means protecting AI systems, models, prompts, agents and data flows, not simply using AI inside an existing security product. Identity shows a different pattern. Aggregate Action is lower: five of 11 and six of 66. But new activity is concentrating around machine and service identities. Identity also remains prominent in Narrative and conference data. The interesting development is therefore not a new IAM market, but a new front inside an old one. The other three directions are less settled.

Exposure Management is already broad among specialists: 14 of 66 companies in the Broader Sample, against only three of TOP-11. Product development appears to be running ahead of consolidation by the large platforms. Data Protection & DSPM shows the opposite imbalance. Action remains narrow, at two of 11 and five of 66, while Expo positioning rose by 65%. Conference attention did not rise materially as a share of the overall program. That may be an early commercial category taking shape or simply positioning running ahead of demand. These data cannot distinguish between the two. Post-Quantum Cryptography sits outside the main Action taxonomy, so its current product breadth is not measured on the same basis. What can be seen is a steady presence in Narrative, rising conference attention and modest growth in Expo positioning. Much of the practical work today concerns crypto inventory and crypto-agility, while the transition itself is also being driven by standards bodies, infrastructure providers, libraries and HSM vendors. The distinction between these six directions matters more than their ranking. AI Security is being pulled into the market by large platforms. Exposure Management is being built largely by specialists. Identity is changing from within. DSPM is being packaged faster than it is appearing in Action. PQC is advancing through standards and preparation rather than through the same product path.

Section 7 states five forecasts that can be checked against the same filter. In short: at least two Exposure Management specialists acquired by TOP-11 vendors by the end of 2027; at least eight of the eleven with a qualifying Machine, Service or Agent Identity event over the same period, up from four today; fewer than four with a qualifying PQC or crypto-agility launch; Data Protection & DSPM reaching at least five vendors by the end of 2028, with three of those tied to AI data; and DSA still the broadest Action cluster at that point.

The broader conclusion is more cautious. Nothing here demonstrates that mature controls such as NGFW are disappearing. What the data do show is that substantial new activity is accumulating in the systems that provide telemetry, identity, asset, data and risk context around those controls. That is consistent with the argument developed in Parts 1 and 2, but it does not prove it by itself.

2. Framing the Question

The market produces many signals about its future, but they do not all mean the same thing.

A forecast shows what an organization thinks will matter. A conference program shows what practitioners and researchers are paying attention to. Expo presence shows what vendors are trying to package and sell. Patents reveal some of the technical problems being worked on. A product launch or acquisition goes further: resources have already been committed.

For that reason, I separate the evidence into three types.

Action is the strongest observable signal of commitment: closed M&A and products that have reached general availability. Narrative shows which problems repeatedly appear in forecasts and market outlooks. Development & Positioning combines patents, conference Talks and Expo presence. These are different datasets, but together they show where technical work, professional attention and commercial packaging appear.

Figure 1. Three Types of Market Signals

The important point is not that one signal is large. It is whether several different signals begin to point in the same direction.

Nor do I assume that they form a sequence. A conference theme may emerge before a product exists; an acquisition may happen before analysts agree on a category name; Expo may expand before there is evidence of broad demand. Divergence is therefore as informative as convergence.

This is particularly useful for mature markets. Identity, for example, may show only moderate growth as a whole while activity concentrates sharply around machine, service and other non-human identities.

The question in Part 3 is therefore not simply which category is growing fastest. It is where vendors have already committed resources, where the wider market is beginning to concentrate attention, and where those two pictures disagree.

There is also a second question, carried over from Parts 1 and 2. If new activity is accumulating around telemetry, Identity, assets, data and risk context rather than inside one control, does that make a more connected security decision process technically possible?

I return to that question only after the market evidence has been examined. Security Analytics Decision Layer (SADL) is an architectural interpretation of the findings, not another market category and not part of the quantitative ranking.

3. Methodology

The detailed methodology, full sample composition, classification rules and source universe are available in the [research materials on GitHub]. This section retains only the definitions needed to interpret the results that follow.

3.1. Two Action Samples

Action is measured separately for two groups.

TOP-11 consists of Palo Alto Networks, Fortinet, Cisco, CrowdStrike, Check Point, Zscaler, SentinelOne, Cloudflare, Tenable, Rubrik and Okta.

The Broader Sample contains 66 other security companies:

• United States — 18;
• Israel — 17;
• European Union — 16;
• other regions — 15.

TOP-11 is a working name, not a ranking. The Broader Sample is a purposive comparison set rather than a statistically representative sample of the global security market.

The two samples remain separate throughout the analysis. The purpose is to compare how large platforms and other vendors are moving, not to treat the 77 companies as one population.

3.2. What Counts as Action

The Action observation window is 28 July 2024 to 28 July 2026.

Table 2. What Counts as Action

Only closed acquisitions and products that reached general availability qualify.

Preview and beta releases, feature updates, partnerships and integrations without a new standalone offering are excluded.

For TOP-11, this filter produces 34 closed acquisitions and 33 GA launches.

The main metric is the number of companies with at least one qualifying event in a domain, rather than the total number of events. Where a domain needs to be examined in more detail, company × direction and event × direction counts are used as secondary measures.

3.3. Taxonomy

Action events are classified through a two-level taxonomy:

Domain → Direction

The taxonomy contains 10 domains and 57 directions.

Two definitions are important for interpreting the results.

DSA is an analytical cluster rather than a purchasing category. It combines SIEM, XDR/MDR, SOAR, Threat Intelligence, Risk Engine and adjacent analytics capabilities because the analysis is interested in their convergence.

AI Security means securing AI, not using AI. A security product does not enter this domain merely because it uses machine learning, generative AI or an LLM. The category covers protection of models, prompts, agents, inference and AI-related data flows.

The complete taxonomy and mapping rules are available in the [research appendix on GitHub].

3.4. Narrative

Narrative is based on 31 forecast and outlook documents from 19 organizations.

Themes are counted twice: first by document and then by organization. The second pass prevents organizations that publish more frequently from dominating the result simply through volume.

Narrative is therefore a measure of recurring market attention, not evidence of future customer demand.

3.5. Development & Positioning

Three additional datasets provide different kinds of evidence.

Patents are used qualitatively to identify technical work behind the market categories.

Conference Talks measure professional and research attention. The dataset contains 3,075 presentations across 20 conferences in 2024 and 2025.

Expo / Positioning measures vendor presence among exhibitors, solution providers and sponsors and is treated as evidence of commercial positioning rather than sales or adoption.

These datasets are not combined numerically with Action or Narrative.

3.6. Different Layers, Different Time Windows

The datasets also operate on different clocks.

Figure 2. Different Layers — Different Time Windows

Table 3. Five Datasets, Five Clocks

Action uses a fixed two-year window. Narrative may look several years ahead. Patent publication can lag the R&D behind it, while Talks and Expo are observed year by year.

For that reason, the analysis does not assume a sequence such as:

patent → talk → Expo → product → M&A

The signals are compared for convergence and divergence, not treated as stages of one market-development funnel.

3.7. Scope

None of these datasets directly measures customer adoption, production use, renewals, revenue attributable to individual capabilities or market share.

The Broader Sample is manually constructed, Narrative partly reflects vendor positioning, and public disclosure varies between companies and regions. The two-year Action window should therefore be read as a period of observable market movement, not proof of a long-term trend.

Within those limits, Action is used as the strongest observable signal in the study because a completed acquisition or GA launch demonstrates that resources have already been committed.

Detailed sampling rules, inclusion and exclusion criteria, counting methodology, classification rules, source treatment and limitations are available in the [full methodology on GitHub].

4. Action: Where Companies Directed New Activity

Action gives the clearest view of where vendors have already committed resources. Four patterns appear immediately.

DSA is the broadest cluster: it ties AI Security for the lead among TOP-11 and leads outright in the Broader Sample.

AI Security is concentrated among the large platforms. Almost the entire TOP-11 has entered the domain, while activity in the Broader Sample is much narrower.

Exposure Management runs the other way. Only three TOP-11 vendors have qualifying events, against 14 companies in the Broader Sample.

Identity is different again. The aggregate domain is not especially broad, but new activity is concentrating inside it around machine and service identities.

The ranking matters less than these differences in shape.

4.1. The Overall Action Map

Figure 3. Companies with qualifying events by domain

Figure 3 measures the breadth of new publicly observable activity during the two-year window. It is not a measure of market size.

The Broader Sample is not sparse. Qualifying events were found for 47 of its 66 companies and covered 47 of the 57 directions in the taxonomy. Yet activity is distributed very unevenly between domains.

The mechanism is different as well. The Broader Sample produced 62 qualifying product launches and 22 acquisitions. Among TOP-11, the balance is much closer. Smaller vendors are more often building their way into a direction; large platforms make greater use of acquisition.

Deal value tells a different story from company count.

Terms were disclosed for 21 of the 34 TOP-11 acquisitions. Together they were worth about $32.4 billion, but 77% of that total came from a single transaction — the CyberArk acquisition. The median disclosed deal was only $187 million.

This difference between breadth and capital is important.

AI Security ties DSA for the widest company coverage among TOP-11 and produces the largest number of event × direction signals. Yet it accounts for less than 2% of disclosed acquisition value. Platforms have entered AI Security through a series of smaller acquisitions and their own product launches.

Identity is almost the reverse. Only five TOP-11 companies have qualifying Identity activity and only two acquisitions sit behind it, yet the domain accounts for roughly four-fifths of disclosed capital.

The headline number therefore says little about what a typical transaction looked like. One large Identity acquisition dominates the total, while the broader movement into AI Security is spread across many smaller actions.

Activity is also concentrated among the buyers. Palo Alto Networks closed six of the 34 TOP-11 acquisitions; CrowdStrike, Check Point and Cisco closed five each. Those four companies account for 21 of the 34 deals.

The Action picture is therefore not simply one of large vendors moving together. Different groups of companies are using different mechanisms, and the money is even more concentrated than the activity itself.

4.2. DSA: One Focus, Two Development Mechanisms

DSA sits at the top of both Action samples:

• 10 of 11 TOP-11 companies;
• 30 of 66 companies in the Broader Sample.

But the mechanism is different.

Among TOP-11, seven companies used M&A and five launched new products; two did both. Large platforms are extending their existing data and operations stacks partly through internal development and partly by buying missing capabilities.

The Broader Sample is more product-led: 27 companies launched qualifying products, nine used M&A, and six did both.

That matters because DSA is not simply the result of consolidation among large vendors. A sizeable specialist market is still building standalone SIEM, XDR/MDR, SOAR, Threat Intelligence, Risk Engine and adjacent products.

So DSA is best read here as a broad analytical and Security Operations cluster, developing through two different mechanisms: consolidation at the top and product formation below it.

4.3. AI Security and Exposure Management: Two Opposite Paths

The clearest asymmetry in Action is between AI Security and Exposure Management.

AI Security appears in:

• 10 of 11 TOP-11 companies;
• 8 of 66 companies in the Broader Sample.

All ten active TOP-11 vendors launched commercial products, and seven also used M&A. Among the largest platforms, protecting AI is already becoming part of the standard portfolio.

Outside TOP-11, the market is narrower. Specialist activity is concentrated mainly around LLM protection, prompt filtering and AI data security rather than broad AI Security platforms.

Exposure Management develops almost the other way around:

• 3 of 11 TOP-11 companies;
• 14 of 66 companies in the Broader Sample;
• 13 of those 14 through new product launches.

CTEM and External Attack Surface appear most often, with 11 companies in each direction.

The large platforms have not yet matched that breadth. Most of the work is being done by specialists solving narrower problems around asset visibility, exposure, attack paths and risk prioritization.

AI Security is therefore being pulled into the market from the top. Exposure Management is being built from below.

That difference matters more than the raw number of events.

4.4. Identity: A New Front Inside a Mature Market

At the aggregate level, Identity looks moderate:

• 5 of 11 TOP-11 companies;
• 6 of 66 companies in the Broader Sample.

But the aggregate hides where the activity is concentrated.

In TOP-11, broad acquisitions create presence across several Identity directions at once. Five companies generate 26 event × direction signals, but those signals should not be read as 26 independent initiatives.

The Broader Sample gives a cleaner view of the new product activity. All six active companies are represented through their own launches, with Machine Identity and Service Identity appearing most often — four companies each.

The activity is increasingly concentrated around technical identities: machines, workloads, service accounts, certificates, APIs and, increasingly, autonomous agents.

So, the signal is not a new wave across Identity as a whole. It is a new front inside an old market: non-human identity.

Large vendors are mostly acquiring breadth. Specialists are building products around the narrower problem.

4.5. Other Domains: Low Action Does Not Mean Decline

Cloud, Network, Endpoint and Application Security show lower Action coverage:

• Cloud — 4 TOP-11 and 5 in the Broader Sample;
• Network — 3 and 5;
• Endpoint — 1 and 6;
• Application Security — 2 and 4.

These figures should not be read as evidence that the markets are shrinking.

The Action filter excludes most normal development inside mature products: feature expansion, new detection logic, integrations, policy changes and the absorption of acquired technology. Mature domains can therefore remain important while producing relatively few qualifying events.

This is particularly relevant to Network and Endpoint Security.

Cloud is a useful example of another point. Its TOP-11 Action coverage is actually higher than Exposure Management, but its signals are less interesting for this study because they are more consistent across the layers. Cloud already looks like a mature domain rather than a market in the middle of a visible structural change.

Data Protection & DSPM is different. Action remains limited — two TOP-11 companies and five in the Broader Sample — but that is precisely where the next layer becomes useful.

Action tells us where resources have already been committed. Narrative can show whether the market is beginning to treat the problem as more important than current product activity would suggest.

5. Narrative: What the Market Considers Important

The Narrative layer produces a less tidy picture than Action.

AI remains first under both counting methods. Identity and Platformization also stay near the top, although they change places depending on whether the unit is a document or an organization. Below them, agreement weakens. Exposure becomes much more visible when publications are grouped by source, while Cloud moves the other way. PQC remains present but lower in both counts.

The important point is not the exact order. It is which themes survive a change in the way the evidence is counted.

5.1. What Repeats Across Both Passes

Figure 4. Themes Repeated Across Two Analytical Passes

By documents, the leading themes are AI, Identity, Cloud and Platformization. By organizations, AI remains first, while Platformization and Identity remain close behind.

AI is the only theme whose position does not change.

Identity and Platformization move slightly but remain near the top under both methods. That makes their position more convincing than a high count produced mainly by a few prolific sources.

Cloud is a useful counterexample. It ranks third by documents but only fifth by organizations. Its apparent prominence is therefore more concentrated among frequent publishers.

Exposure shows the reverse effect more sharply: weak as a standalone forecast category, much stronger once related themes are grouped by organization.

That difference becomes important later.

5.2. AI Extends Far Beyond AI Security

The AI Narrative is much broader than the AI Security category used in Action.

Forecasts cover AI-assisted attacks, automated reconnaissance, AI in SOC operations, model protection, agent security, data flows and autonomous systems.

This distinction matters. The Action dataset counts security for AI. Narrative also includes AI used in security.

So the prominence of AI in forecasts is not a second measurement of the same product category. It shows something broader: the market expects AI to alter several existing security domains at once.

AI agents make that overlap particularly clear. Once an agent has credentials, access to tools and access to corporate data, the problem spreads beyond AI Security into Identity, Data Protection and policy enforcement.

5.3. Identity: The Perimeter Becomes Non-Human

Identity remains near the top under both counting methods.

But the language around it is changing. Forecasts increasingly refer to machine and service identities, non-human identities, ephemeral credentials, ITDR, agent identity and the permissions of autonomous systems.

This does not mean that the Identity market has become an NHI market. Human IAM remains part of the same Narrative.

The change is narrower and more interesting: the definition of an identity worth controlling is expanding beyond the employee account.

That is consistent with Action, where Machine Identity and Service Identity are the most repeated specialist launch areas.

5.4. Platformization: The Gap Between Data and Controls

Platformization is not a product category in the Action taxonomy, but it appears repeatedly in Narrative.

The vocabulary varies: Unified Data, SIEM/XDR convergence, Security Operations platforms, tool consolidation, cross-domain analytics — but the underlying problem is similar: telemetry and context remain scattered across products that do not naturally share either data or decisions.

This provides a useful counterpart to DSA.

There is no one-to-one mapping between Platformization in Narrative and DSA in Action. But both point to the same pressure: security data is becoming more useful when it can be combined across domains rather than kept inside separate tools.

5.5. Exposure Management and PQC: Two Different Paths

Exposure Management behaves differently from AI, Identity or Platformization.

It barely appears as a standalone forecast category when documents are counted. But when related material is grouped by organization, Exposure forms a distinct theme across 10 of the 19 sources.

That fits the Action data unusually well. A specialist product market already exists, while the language used to describe it is still consolidating.

In other words, the products appear to have arrived before the category name was fully settled.

PQC is almost the opposite case.

Post-Quantum Cryptography and crypto-agility appear consistently in Narrative, but lower in the ranking. Unlike Exposure, the Action taxonomy does not measure PQC product breadth directly.

Its importance therefore comes from a different set of signals: standards, migration planning and infrastructure change. Much of that transition is being driven outside the security-vendor sample: by standards bodies, cloud and infrastructure providers, cryptographic libraries and HSM vendors.

PQC is already part of the long-term agenda. This study cannot say how broad its standalone product market is.

5.6. Narrative Is Also Marketing

There is an obvious bias in this layer: 11 of the 19 organizations are the TOP-11 vendors themselves.

Their forecasts may reflect early visibility into customer requests, incidents and product competition. They are also part of their go-to-market.

Narrative should therefore be read as evidence of what the industry is trying to make important as well as what it believes will become important.

Regulation creates a different blind spot.

NIS2, DORA and the EU AI Act all fall within or close to the research window, yet regulation barely appears as a separate market theme. That does not mean it is unimportant. Regulatory requirements are usually translated into demands for asset visibility, investigation, retention, reporting and control rather than bought as a category called “compliance.”

Some of that demand may therefore appear indirectly inside DSA, Exposure Management, Identity or Data Protection.

This study cannot measure how much. It measures supply and industry attention, not the reason a customer eventually signs a purchase order.

The Narrative layer therefore adds two things to Action. It shows where market language is catching up with products, as in Exposure, and where attention is running ahead of measurable product breadth, as in PQC.

The next layer asks whether the same directions are also visible in technical work, conference program and commercial positioning.

6. Development & Positioning

Action shows where vendors have already committed resources. Narrative shows what the industry says will matter. A third view comes from patents, conference program and Expo positioning.

These datasets measure different things and should not be combined into a ranking. Patents provide evidence of technical work; Talks show professional attention; Expo shows how vendors are packaging themselves commercially.

The differences between them are often more useful than the absolute growth rates.

AI is rising strongly in conference attention and faster still in commercial positioning. Identity points in the same direction across both. Data Protection & DSPM is growing much faster at Expo than in conference programs. PQC remains more visible in professional discussion than in commercial presence.

6.1. Patents: Technical Work Behind the Market Labels

Patent counts are not comparable between companies. Jurisdiction, company age, filing strategy and publication lag make such comparisons unreliable. I use the material only to see whether the market categories correspond to identifiable engineering problems.

Four motifs occur.

• In Identity, the technical subject is moving beyond the employee account. The material covers device signals, machine and service access, credentials and certificates. Okta describes flexible service access driven by the identity provider (US12170676B1); Tanium covers enterprise certificate management (US12671595); SentinelOne addresses attacks that reuse or pass existing credentials (US12452273B2).
• In Exposure Management, the emphasis moves from finding vulnerabilities to establishing context: asset importance, network topology, attack paths and risk ranking. Palo Alto Networks describes vulnerability impact assessment tailored to the network (US12432248B2); BitSight treats asset importance ranking as a problem in its own right, ahead of prioritisation (US12348485).
• In Data Protection, the chain increasingly runs from discovery to classification, ownership, exposure and policy. Cyera’s material covers data discovery in cloud environments (US12499083B2) and dynamic policy generation (US12407737B1). The problem is no longer simply preventing a file from leaving a system; it begins with knowing what the data is and why it matters.
• In Security Operations, the recurring theme is the connection between analytics and action. Cisco describes dynamic adaptive defence that changes controls as a threat evolves (US11985160B2); SentinelOne describes endpoint controls that adapt to the current risk level (US20240089273A1); BitSight covers generation of security improvement plans (US12223060B2).

Patents do not show whether these mechanisms are widely deployed in production. They do show that several categories visible in Action and Narrative correspond to concrete technical problems rather than market labels alone.

6.2. Talks and Expo: Different Signal Profiles

The conference dataset contains 3,075 Talks across 20 security conferences in 2024 and 2025.

Talks are used here as a measure of professional and research attention. Expo counts represent vendor-side commercial positioning. Their absolute values are not directly comparable, but their movement can still be compared.

Figure 5. Talks and Expo / Positioning Dynamics, 2024–2025

The percentages also need context. AI Expo presence doubled from 55 to 110 vendors, but its absolute presence still remained well below Identity and Cloud. PQC increased by 20%, but that meant a rise from only 25 to 30.

The useful question is therefore not which percentage is largest, but what kind of profile each direction shows.

AI: Attention Rises, Positioning Rises Faster

The conference AI category is broader than AI Security in Action. It includes both security for AI and the use of AI inside security operations.

Even with that limitation, the direction is clear. Talks on AI rose by 52% in raw count and Expo positioning doubled — the fastest growth of any direction in this dataset.

The discussion is also moving beyond prompt injection and basic LLM vulnerabilities toward agent security, model and inference protection, AI supply chains and the use of LLMs in Detection Engineering.

This does not duplicate the Action result. Action shows that large platforms have already entered AI Security. Conferences show that the surrounding technical and professional problem space is still expanding.

Identity / NHI: Strong Cross-Layer Alignment

Identity increased by 63% in Talks and 58% in Expo positioning.

The two percentages should not be treated as equal growth rates: the datasets have different denominators. What matters is that both move in the same direction.

Conference programs increasingly discuss non-human and agent identities, identity resilience, machine credentials and service access. This overlaps with the Machine Identity and Service Identity launches visible in Action and with the Identity Narrative.

The signal is broader than NHI alone, but NHI is clearly one of the areas where new attention is concentrated.

Data Protection & DSPM: Positioning Runs Ahead

The profile is different for Data Protection & DSPM.

Talks rose by 14% in raw count, but their share of the overall conference program remained almost unchanged at 4.9%. Expo positioning, meanwhile, increased by about 65%. AI shows the same ordering, but there conference attention is growing strongly as well. Here it is not.

Vendors are increasingly packaging data discovery, classification, permission exposure, shadow data and protection of data used in AI workloads as a distinct commercial category.

That is a real positioning signal. It is not evidence of equivalent buyer demand.

The gap could indicate an early market taking shape. It could equally mean that vendors are moving faster than customers. These datasets cannot distinguish between the two.

PQC: Preparation Before a Broad Product Wave

PQC rose by 33% in Talks and 20% in Expo positioning, from a much smaller base than AI or Identity.

Conference programs concentrate on crypto-agility, migration planning, implementation risk and the replacement of existing cryptography.

That fits the Narrative layer, where PQC is already a recurring strategic topic. But because PQC sits outside the main Action taxonomy, this study cannot compare its product breadth directly with the other directions.

For now, the visible signal is preparation for an infrastructural transition rather than evidence of a broad standalone product wave.

6.3. One Market, Several Trajectories

By this point the six directions no longer look like stages of one common maturity curve.

AI already combines broad platform Action with rising attention and positioning.

Identity shows one of the strongest alignments across Action, Narrative, Talks and Expo, with NHI emerging inside the broader domain.

Exposure Management has a specialist product market before the large platforms have consolidated around it.

Data Protection & DSPM is being packaged commercially faster than its Action or conference share is growing.

PQC is advancing through professional preparation and infrastructure change, while its product breadth is outside the scope of the Action dataset.

DSA follows another path again: broad Action, supported less by a named conference category than by recurring work around analytics, correlation and Security Operations.

The point is not to force these signals into a single score. It is to see that several important security directions are moving, but by different mechanisms.

The next step is to put those paths side by side.

7. Where the Signals Converge

Putting the layers together produces a simpler picture than looking at any one of them alone.

DSA, AI Security and Identity show the strongest alignment across the evidence. Exposure Management, Data Protection & DSPM and PQC do not. Their signals are real, but they take different forms. Three directions are confirmed across the layers in this sense and three are still forming.

That distinction matters because markets do not necessarily move from discussion to product to consolidation in a fixed order. In this sample, some categories are being built by specialists before large platforms enter them; others are being packaged commercially before Action becomes broad; still others are being driven partly outside the security-vendor market.

In Figure 6, being “in focus” refers to TOP-11 participation. A direction can already have a broad specialist market and still sit on the left of the chart.

Figure 6. Six Directions — Different Forms of Market Movement

7.1. Three Aligned Directions

• DSA is the broadest Action cluster across the two samples, but the common thread is connectivity rather than a new product category. What holds the cluster together is not a single category but a common problem: connecting telemetry, analytics, investigation and response. Narrative describes much the same pressure through Platformization, Unified Data and consolidation.
• AI Security follows a different route. Its Action is concentrated among the large platforms, while the wider AI agenda is also expanding rapidly in forecasts, conferences and commercial positioning. Protecting AI is becoming part of the platform portfolio rather than emerging only as a specialist market.
• Identity is less broad in Action, but the direction of change is unusually consistent across the layers. The new activity is concentrated around machine, service and other non-human identities. This is better understood as a new front inside a mature Identity market than as a separate replacement for it.

7.2. Three Divergent Profiles

• Exposure Management already has a relatively broad specialist product market, while TOP-11 participation remains limited. The open question is whether that specialist market remains independent or becomes consolidated into larger platforms.
• Data Protection & DSPM shows stronger commercial positioning than Action. Expo presence is rising much faster than its share of conference attention, while qualifying product activity remains narrow. That may indicate an early market forming; it may also be vendors positioning ahead of demand. The evidence does not resolve the difference.
• PQC follows another path altogether. It is visible in forecasts and professional discussion, but product breadth is outside the Action taxonomy used here. Much of the transition is likely to arrive through standards, infrastructure, libraries and cryptographic hardware rather than through a conventional security-product category.

These are not three weaker versions of the same trend. They are three different market structures.

7.3. What Asymmetry Means

The important result is not that all six directions are growing. They are not moving in the same way.
AI Security is already broad among the large platforms. Exposure Management, by contrast, remains mostly specialist-led. Identity is changing from within an established market rather than forming a new one beside it. DSA combines broad activity at the platform level with continued product development among specialists. Data Protection & DSPM is being positioned commercially faster than qualifying Action is appearing. PQC is moving through standards, infrastructure and preparation as much as through the security-vendor market itself.
A single ranking would hide most of these differences.

They also make it difficult to describe the market as moving through a common sequence from idea to product to mature category. Exposure already has products before the large platforms have consolidated around the category. DSPM has strong commercial positioning without equally broad Action. PQC is already part of the strategic agenda even though this study does not measure its product breadth on the same basis.

The same market can therefore produce very different signals depending on where one looks. That is more useful than deciding which direction should be placed first or second on a trend list.

7.4. What These Movements Have in Common Architecturally

At the level of market categories, these directions have little in common. Look instead at the context each adds to a security decision, and the picture changes.

DSA provides telemetry, correlation and risk context. Identity tells us who or what is acting. Exposure adds information about assets, dependencies and attack paths. Data Protection adds sensitivity, ownership and exposure of the data itself. AI introduces models, agents and data flows that also need to be understood and controlled.

PQC is different. It is primarily an infrastructural cryptographic transition rather than another source of decision context.

These capabilities can support different parts of the same decision process, but they do not create that process automatically.

Products may tell an organization what happened, what is exposed, which identities are involved and which controls are technically available. They do not determine which action is appropriate for that organization, whether the action produced the intended result, or whether the same response should be used the next time a similar situation occurs.

This is where the findings reconnect with Parts 1 and 2.

The market is supplying more of the context required for a security decision outside any single enforcement point. The action itself may still be carried out through NGFW, IAM, EDR, cloud controls, SOAR or an ordinary operational change process.

What connects those pieces is not another product category. It is the organization’s own decision process.

That is the limited role of SADL in this article. It is not part of the market taxonomy and the data do not imply that organizations need another platform. It is simply one way of describing how separate sources of context, analysis and enforcement can be connected into a working cycle.

The market can supply the components. The organization still has to decide how they are used together.

7.5. What Would Change This Picture

The evidence above describes the period ending on 28 July 2026. The forecasts below are deliberately narrower. They are intended as tests of whether the patterns identified in the study continue.

• Between 29 July 2026 and 31 December 2027, I expect at least two Exposure Management specialists from the Broader Sample to be acquired by TOP-11 vendors.
• Over the same period, I expect at least eight of the eleven TOP-11 vendors to record a qualifying GA launch or closed acquisition in Machine Identity, Service Identity or Agent Identity. The current baseline is four TOP-11 vendors with a qualifying Machine or Service Identity event.
• Between 29 July 2026 and 31 December 2027, I expect PQC to move more slowly as a standalone security-product category: fewer than four TOP-11 vendors should record a qualifying GA launch explicitly positioned around PQC migration or crypto-agility.
• By the end of 2028, I expect Data Protection & DSPM to reach at least five TOP-11 vendors, with at least three of those qualifying events explicitly tied to AI data flows, AI applications or data used by AI systems.
• Over the same period to 31 December 2028, I also expect DSA to remain the broadest TOP-11 Action cluster, with at least five vendors recording further qualifying acquisitions in analytics, correlation or Security Operations capabilities.

The same Action filter should be used when these forecasts are revisited: closed acquisitions by closing date, generally available products confirmed by public vendor disclosure, counted by distinct companies rather than announcement volume. Anyone re-running that count on the same eleven vendors at the stated dates should arrive at the same answer I would.

Two factors outside vendor strategy could move these numbers on their own. A regulatory mandate could pull PQC migration forward. Consolidation inside TOP-11 itself would redistribute events rather than create them, because the sample is fixed. I have deliberately not built scenarios around either. The point of a falsifiable forecast is that it should be able to fail cleanly.

They are forecasts rather than extensions of the dataset. If the market develops differently, the interpretation should change with it.

8. Practical Conclusion: The Market Supplies the Components, the Organization Builds the Cycle

The market picture above has a practical consequence, although it is not itself a finding of the study.

Security vendors are supplying more of the information needed to understand a situation: telemetry, identity, asset relationships, data context and new AI actors. They are also supplying more ways to analyse that information and more ways to act on it.

What they do not supply automatically is the decision between the two.

A security event rarely determines its own response. The same attack path may justify immediate isolation in one system and additional monitoring in another. The difference may depend on the importance of the asset, the identity involved, the data at risk, existing controls and the operational cost of intervention.

Nor does a decision require a new universal enforcement layer. The action may still be carried out through an NGFW, IAM or PAM system, EDR, a cloud control, SOAR, or an ordinary change process. The useful question is not whether one platform contains all of these functions, but whether the organization can bring together enough context to choose the right action.

There is another step that is easy to lose. Applying a control is not the same as solving the problem.

A blocked account may stop an incident and interrupt a critical process. A network change may reduce exposure and create an availability problem. A stricter policy may work technically while producing so many exceptions that its practical value disappears.

The result therefore has to be checked.

If the action worked, and its side effects were acceptable, the organization has learned something that can be used again. A repeated decision can gradually become a rule, a playbook or an automated response. Automation makes more sense after the conditions and consequences of an action are understood than before them.

That distinction becomes more important as the market moves toward AI-assisted and increasingly autonomous security operations. An automatically generated recommendation and an automatically authorized action are not the same thing. For a well-understood and repeatable scenario the two may eventually converge. For a new or expensive action, there should still be a control point between them.

This is the connection to the SADL cycle used in the earlier parts of the series:

Profile → Assess → Decide → Act → Verify → Pattern

Figure 7. SADL Cycle

I do not treat this cycle as another product layer implied by the market data. It is simply a way to connect capabilities that increasingly exist.

It also does not compete with NIST CSF. CSF describes which functions have to exist; this cycle describes the operational logic of a single decision inside them. Compared with a generic OODA loop, the difference is that Verify and Pattern are treated as explicit steps rather than as something that happens informally after the fact.

An organization does not need to begin by redesigning its entire security architecture. One recurring decision is enough: isolate an endpoint, block a service account, remediate an exposure, or respond to suspicious activity by an AI agent. The useful test is whether the organization can assemble the necessary context, make the decision, execute it, verify the result and retain what it learned.

The market can provide the components for that process.

It cannot decide how an organization should put them together.

9. Conclusion

The two samples do not describe the same market in the same way.

Large platforms have moved broadly into AI Security. Exposure Management remains much more specialist-led. DSA is broad in both samples but develops through different mechanisms. Identity shows a new concentration around non-human actors. Data Protection & DSPM and PQC are visible for different reasons, but neither follows the same path as the first three.

That is the main result of Part 3.

It does not show that mature controls are becoming less important. The Action filter deliberately misses much of the development that happens inside established Network, Endpoint, Cloud and Application Security products. Nor does the study measure what customers have already adopted.

What it does show is where new observable vendor activity is accumulating: increasingly around telemetry, analytics, identity, exposure, data and AI context that sits across several security domains.

This is consistent with the argument developed in Parts 1 and 2, but it is not proof of it. NGFW remains an enforcement point. The change is that more of the information required to decide what that enforcement point should do is being produced elsewhere.

The market is making a more connected security decision process technically possible.

Building that process remains the organization’s job.

The previous parts: “Part 1: The Evolution of the NGFW Market — Drivers, Trends, and Architectural Consequences” and “Part 2: NGFW Vendor Moves as Signals of an Architectural Shift”

All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.

More Data

Supporting appendix with the Broader Sample composition, Action taxonomy and a summary of the Narrative, conference, Expo and patent source sets is available on GitHub.

All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.

Data current as of July 2026.

Originally published on HackerNoon: [link]

In the first part of this article (Part 1: The Evolution of the NGFW Market — Drivers, Trends, and Architectural Consequences), I argued that five major trends — AI, SASE, Identity, Cloud, and Data Security Analytics — are gradually shifting the center of gravity in security architecture away from the perimeter and toward data, context, and decision-making. In that logic, NGFW does not disappear, but its role changes: it becomes one of the enforcement mechanisms within a broader distributed architecture.

This second part continues that line of thought. Its purpose is not to compare vendors in the traditional sense, and not to identify “leaders” and “laggards” as an end in itself. Instead, I use vendor strategies, acquisitions, and domain expansion as observable market signals that help reveal a deeper architectural shift. The question is not which company has the most complete portfolio, but what the movement of the market itself tells us about the kind of security architecture that is beginning to emerge.

In this article, SADL is used as a working architectural hypothesis rather than a formal market category or product class. The point is not to identify who “builds SADL,” but to examine why current market movements increasingly make such a layer necessary: once security decisions depend on data, context, behavior, and cross-domain signals, isolated controls are no longer sufficient on their own.

To test whether this architectural shift is real — and not just a narrative — I needed a way to read vendor behavior systematically. The methodology below is designed for exactly that purpose.

Methodology of the Analysis

The analysis is structured around the five transformation domains discussed in Part 1: AI, Identity, Cloud Security, SASE, and Data Security Analytics. These domains are used not as separate markets to be catalogued, but as lenses through which a broader architectural shift can be observed. Vendor activity within them is examined because it makes that shift visible in concrete form — through acquisitions, product expansion, integration patterns, and strategic emphasis. The set of global vendors included here is therefore not intended to produce a comprehensive ranking of the market, but to provide a representative sample of the forces currently shaping the evolution of security architecture through the firewall market and its adjacent domains. Companies from Asia were not included in the sample.

1. Recognized industry leadership
   The vendors regularly appear in reports by the Big Four — Deloitte, KPMG, PwC, and EY — as well as in research by Gartner, Forrester, CyberRatings, Miercom, NetSecOPEN, G2, and other analytical organizations.
2. Significant global market share
   These vendors hold a substantial share of the global NGFW market, both in revenue and in the number of installations.
3. Influence on technological trends
   These are the vendors that shape the industry’s development, set standards, and move the market forward.

The vendor set used in this analysis includes:

• Palo Alto Networks
• Fortinet
• Check Point
• Cisco
• Sophos
• Forcepoint
• Zscaler
• WatchGuard
• SonicWall

In my view, this sample provides a clear picture of where the market is heading and how the leading companies see their role in it over the coming years.

How Vendor Activity Is Interpreted in This Analysis

The purpose of this framework is not to assess the technical depth, completeness, or product quality of each vendor’s individual solutions. It is used more modestly: to interpret externally visible signals that indicate whether a domain appears strategically important for a vendor and how actively that vendor is moving into it. In other words, this is not a product ranking model. It is a way to read market behavior as evidence of broader architectural change.

Four levels of domain presence are used: L0 through L3.

• L0 — No presence / No data
• L1 — Intent / Announcement / R&D / Low or early-stage participation
• L2 — A product or solution exists, but participation in the domain is limited or incomplete
• L3 — Full presence in the domain / Strong and recognizable solutions / A strategic player helping define the domain

L1, L2, and L3 are not development stages through which a vendor “progresses.” They represent different types of participation signals and are assessed cumulatively. The assessment is based exclusively on open and externally observable signals.

Each level is evaluated using a weighted signal model that considers strategic declarations, engineering activity, commercial products, production deployments, integrations, M&A, and presence in analyst frameworks. The full signal model with individual criteria and weights is provided in the Appendix at the end of this article.

M&A Analytics and Deal Maps

When analyzing the strategies of major vendors, the most objective source of information is not public statements, but concrete actions — especially mergers and acquisitions. M&A activity shows where vendors are investing, which capabilities they are building, and which segments they view as strategically important over the next several years.

This transformation is particularly visible through their M&A activity.

The infographic below presents acquisitions made by leading companies in 2024–2025 and highlights the key directions of their strategic development.

The data was compiled from open sources, including vendor websites, media outlets such as CRN, CTech, SecurityWeek, and LinkedIn, as well as financial and industry publications such as MarketScreener, Forrester, and Crunchbase News.

As of the beginning of 2026, several additional deals had already been announced but were not included in this analysis.

M&A is used here as a directional signal. It shows where vendors expect future architectural value to concentrate, not whether integration depth or execution quality has already been proven.

Domain Signals Through Vendor Activity

Before turning to the domains, one clarification is necessary: vendors are not the subject of this analysis, but one of its lenses. Their acquisitions, product expansions, integrations, and omissions matter because they make architectural pressure visible. What follows is therefore not a comparative ranking, but a domain-by-domain reading of market signals. The question is not whether security functions are expanding into adjacent domains — that is already clear — but what that expansion implies for how security decisions are formed.

AI

The AI Security domain is still taking shape. New areas and categories have emerged within it that do not fit neatly into traditional models of network and application security.

AI provides a particularly clear illustration of how vendors can build their strategies in a new and still-forming market. In this domain, market stratification is already becoming visible: on one side are companies investing in their own analytical core and dedicated products; on the other are those limiting themselves to declarations or isolated participation in specific technologies and subdomains.

It is worth noting that the AI Supply Chain direction is, in many respects, closer to companies operating in the DevSecOps domain than to vendors traditionally focused on NGFW.

The AI domain provides a useful starting point because it shows especially clearly how market expansion into adjacent areas creates pressure for a new security decision-making model.

Palo Alto and Check Point treat AI Security as a strategically important domain — one they appear to view as capable of delivering long-term competitive advantage. Their strategy goes beyond simply adding isolated AI-related functions to existing products and services and is built around several core principles:

• protecting AI as a standalone object in its own right: models, agents, data, and pipelines;
• integrating AI signals into a unified analytics and policy management framework;
• using M&A as the primary mechanism for accelerating development.

These companies do not treat AI as a marketing add-on to NGFW. Instead, they view it as a new component of the SADL layer — one focused on decision-making, risk assessment, and dynamic access control. In this paradigm, NGFW is firmly established as a policy enforcement mechanism operating on decisions formed by AI- and data-driven analytics.

Fortinet, Sophos, Forcepoint, and Zscaler have only partial presence in the AI domain. As a rule, their presence is built on existing product lines — DLP, Web Security, Data Protection, and Data Analytics — and extended through AI-oriented features in adjacent areas.

This approach allows vendors to demonstrate market presence relatively quickly. However, it also creates an architectural limitation: AI is used as an overlay on top of existing products, or as an enhancement to them, rather than as a new and independent decision-making layer. As a result, the benefits of AI more often remain confined to local control mechanisms rather than becoming a genuinely new and autonomous decision-making layer.

Cisco, consistent with its traditional development model, has entered this space through the acquisition of Robust Intelligence. The company is actively signaling its intentions, although these have not yet fully matured into something more substantial.

SonicWall and WatchGuard are not represented in the AI Security domain. For vendors in this position, a strategic risk remains: as AI workloads grow and LLM-based services become more widespread, their NGFW solutions will increasingly operate in environments where key decisions are made outside their control — at the level of cloud AI products and external analytical systems.

AI is the first domain in which it is no longer enough simply to “have a product.” Without an internal analytical core, context management, and data integration, it becomes impossible to:

• properly assess the risks of AI interactions;
• manage access policies for models and agents;
• adapt network controls to the behavior of AI services.

In the context of AI, NGFW becomes part of a broader architecture:

• it provides telemetry;
• it integrates with AI- and data-driven analytics to enable deeper process awareness;
• it applies dynamically generated policies.

AI is the first domain where the line between “having a feature” and “participating in the decision-making layer” becomes unmistakable. Vendors with an internal AI analytical core — their own models, context pipelines, and risk engines — are building a clearer path into SADL: AI signals can feed decision logic, and decision logic can return adaptive policies. Vendors that treat AI primarily as a feature overlay on existing products remain more limited, because their AI outputs are less likely to shape cross-domain decision-making. Over the next few years, this difference is likely to become operationally meaningful — not as a distinction between “better” and “worse” firewalls, but between architectures in which AI meaningfully contributes to decision-making and those in which it remains confined to local product logic.

SASE

The SASE domain has reached maturity: vendors are represented across all or most of its key areas. An analysis of their positions within the domain reveals several distinct strategic approaches.

Forcepoint continues to focus primarily on SWG, with only limited participation in the other areas. In other words, it remains within its established niche and core competencies.

WatchGuard and SonicWall are only partially represented in the domain. At the same time, over the past several years they have expanded both their participation and their coverage across SASE-related areas within their product portfolios, including the addition of SWG functionality. This points to an effort to catch up with the market leaders.

Fortinet, Palo Alto, Cisco, and Check Point are building out their presence across all major SASE directions, positioning themselves as providers of end-to-end solutions. These vendors are seeking to control the entire chain of security services and network access.

Zscaler demonstrates an alternative approach: the company has deliberately chosen not to develop SD-WAN, instead concentrating on SWG, CASB, ZTNA, and SSE, where it holds leading positions (L3). Rather than building its own SD-WAN capabilities, Zscaler relies on integrations with partner solutions — a strategy that allows it to focus resources on strengthening its advantages in cloud security.

From the perspective of NGFW evolution, several points stand out:

• native support for SASE functions — NGFW must provide SWG, CASB, ZTNA, SD-WAN, and SSE capabilities either natively or through integration with other solutions;
• openness to integrations is essential, and Zscaler illustrates this especially clearly. In practice, few organizations rely on a single vendor for all SASE components;
• NGFW must provide high-quality APIs and integration mechanisms for third-party SASE services, enabling the construction of hybrid best-of-breed architectures.

SASE is not SADL — it is the delivery architecture for access and policy. But it generates the raw context without which SADL cannot function: who connects, from where, through which path, to which service. Vendors controlling the full SASE stack — Fortinet, Palo Alto, Cisco, Check Point — gain an advantage in signal completeness: every component feeds telemetry directly into the decision-making layer. Yet Zscaler’s deliberate absence from SD-WAN shows that owning the stack is not the only viable path. By investing in open integrations, Zscaler achieves comparable contextual depth for SADL without building every component itself. The implication is architectural: SADL does not require a data monopoly. It requires signal coherence — the ability to join data from multiple sources into a unified decision context, regardless of who owns each component.

Cloud

The Cloud domain is mature: its key areas have long since taken shape, and vendors have already had time to reassess their strategies and adjust their plans for operating in this space.

Palo Alto, Check Point, and Fortinet are the leaders in cloud security, with coverage across all five core areas of the domain: CSPM, CWPP, CIEM, KSPM, and DSPM. Of the three, Palo Alto appears to place somewhat greater strategic emphasis on the domain than the other two. Fortinet significantly strengthened its position through the integration of Lacework in 2024, gaining full-fledged CWPP, CIEM, and KSPM capabilities. Check Point relies on its CloudGuard platform, along with technologies acquired through M&A.

Zscaler is a strong player, present in four of the five areas, with the only gap being KSPM at the L3 level. It still trails the leaders in the overall depth of participation, but it demonstrates some of the most advanced CIEM capabilities thanks to the strategic acquisition of Trustdome.

Forcepoint is a narrowly specialized vendor with a presence in two areas: CSPM and DSPM. This positioning reflects the company’s core strength in Data Loss Prevention: DSPM is a natural extension of its DLP expertise into the cloud context. Its absence from CWPP, CIEM, and KSPM is explained by its focus on data protection rather than infrastructure or workload security.

WatchGuard is an SMB-focused vendor with limited presence in two areas — CSPM and CWPP, both at the L2 level. Its cloud security capabilities are implemented as additional functionality within its core Total MDR product, rather than as a standalone CNAPP offering. This positioning reflects a strategy of providing baseline cloud security mechanisms for small and mid-sized businesses.

Cisco is in the process of a strategic withdrawal from cloud-native security. The official discontinuation of Panoptica in 2024 led to the loss of its presence in CIEM and KSPM. Its remaining fragmented coverage — CSPM, CWPP, and DSPM at the L2 level — is based on legacy solutions such as Secure Workload (formerly Tetration) and basic Cloud Posture modules within Cisco XDR. Its current position reflects the absence of long-term investment in cloud security and a shift in strategic priorities.

SonicWall has no meaningful presence in the cloud security domain (L0 across all areas). The company remains focused on traditional network and endpoint security for the SMB segment. Cloud-related components in its portfolio, such as Cloud App Security, amount to SaaS Security / CASB with DLP, but do not cover the core cloud-native security areas: CSPM, CWPP, CIEM, KSPM, or DSPM.

From an architectural perspective, limited participation in cloud security increasingly creates a blind spot in the decision-making layer. SADL requires visibility into infrastructure posture, workload behavior, entitlement chains, and configuration drift. Without cloud telemetry, decisions formed at that level become materially less complete: the network remains visible, but containers, serverless functions, and ephemeral workloads do not. Cisco’s withdrawal from cloud-native security illustrates this risk particularly well. When a vendor exits a domain, it loses not only a product category, but also part of the context on which future decisions depend. For customers, the practical implication is straightforward: evaluate not only current product coverage, but also where your vendor continues to invest — because that investment shapes how complete its future decision-making context is likely to be.

Identity

Until recently, this domain remained outside the focus of most of the companies covered in this analysis, with only a few exceptions. It is a mature domain: its solutions and market participants have been shaped over many years, during which deep expertise was accumulated in cryptography, IAM protocols, and compliance. The space has traditionally been dominated by established players such as CyberArk, Okta, Microsoft, and others.

High regulatory requirements — including SOC 2, ISO 27001, and FedRAMP — create additional barriers to entry for new players. Implementing solutions in this domain usually takes considerable time, not so much because of the technical deployment itself, but because of the need to fine-tune customer processes in each individual case. All of this has made entry into the domain economically difficult to justify for new vendors.

Palo Alto (through CyberArk) had almost no meaningful presence in the domain before the acquisition, but afterward it immediately became a strategic leader in the Identity domain, with full coverage across all five areas: IAM, IGA, PAM, IdP Security Posture, and ITDR.

Cisco is a leader in several areas — IAM, IdP Security Posture, and ITDR, thanks to its acquisitions of Duo Security in 2018 and Oort in 2024 — but it has no presence in IGA or PAM.

Fortinet and Zscaler have only partial presence, but they have strong identity-related components that extend their core products, such as SSE and firewall platforms. Their strategy is to expand the functionality of existing products through identity capabilities.

For Check Point, WatchGuard, and Sophos, identity-related functions are embedded into their existing solutions and only partially cover the required functionality. These vendors are following a path in which part of the identity problem is addressed through integration with other vendors rather than through proprietary products and platforms.

SonicWall has only minimal presence in the domain, limited to managed ITDR.

Forcepoint, as a data security vendor, does not participate in the Identity domain.

Based on the data above, several distinct vendor strategies become visible:

• M&A — acquiring established identity vendors in order to enter the domain quickly, as in the cases of Palo Alto and Cisco;
• Strategic partnerships — working with mature players in the domain through OEM integration or co-selling models;
• Organic growth — long-term investment in building proprietary identity products, which is the slowest path because of the high barriers to entry and the long time horizon involved.

A decade ago, the industry debated whether firewalls needed application awareness. Those that were slow to add it found their competitive position weakened considerably. Identity is following the same arc — but with higher stakes, because it changes the quality of SADL itself. As long as decisions are formed on the basis of IP addresses and network parameters, SADL operates with limited, low-resolution context. The moment identity data enters the picture — who is acting, from which device, with what entitlements, in what behavioral context — the resolution of SADL decisions changes fundamentally. This is why M&A activity in this domain should be read not simply as portfolio expansion, but as investment in the quality of context available to the decision-making layer. Vendors with limited identity capabilities do not merely lack another product category; they operate with lower-resolution context, and lower-resolution context narrows the quality of the decisions that can be formed above it.

Data Security Analytics

In this article, Data Security Analytics is treated as the analytical foundation beneath SADL: it provides the collection, processing, correlation, and interpretation of data on which higher-level security decisions depend.

This domain plays a defining role in decision-making. Vendors have assigned it different levels of priority and taken different views on how necessary it is to cover all of its areas — something that becomes clearly visible in the analysis below.

Palo Alto and Fortinet hold leading positions across all areas of the domain, owing both to their own products and to the investments they have made.

Cisco has discontinued a number of its products and solutions in the DSA space, announcing end of sale and no replacement for some of them. In the areas that remain, however, Cisco still appears as a vendor helping shape the direction of the market, largely due to the capabilities it gained through the acquisition of Splunk.

Check Point has traditionally been one of the key players, although some areas were not further strengthened through additional acquisitions.

Sophos and Zscaler, by contrast, appear to be focused primarily on the STO and MDR/XDR segments.

WatchGuard and SonicWall can be classified as niche players in this domain. They have traditionally covered only those areas directly related to their core products, without attempting to expand their presence across the full spectrum.

Forcepoint is comparatively less visible in this domain than its competitors, and it is the only vendor in the group that is not represented in XDR/MDR.

The areas within the Data Security Analytics domain, when integrated with NGFW, create a synergistic effect that significantly expands an organization’s ability to protect against, detect, and respond to threats:

• XDR enriches NGFW solutions with threat intelligence and initiates automated containment when threats are detected.
• SIEM transforms isolated NGFW events into correlated chains for identifying multi-stage attacks.
• SDP provides long-term storage and supports threat hunting based on historical NGFW telemetry.
• DRA uses traffic data to build attack paths and prioritize remediation efforts.

The accumulated history of NGFW events becomes the foundation for ML models capable of detecting zero-day attacks through anomalies, identifying slow attacks, forecasting the likely direction of an attacker’s actions, and automating rule tuning while balancing security and performance.

DSA is the only domain among the five that does not merely contribute signals to SADL — it provides much of the analytical foundation on which SADL depends. AI describes model behavior, SASE maps access paths, Cloud captures infrastructure posture, Identity identifies the subjects of action. Each provides context. But it is DSA that binds these signals into a unified analytical picture, transforms scattered inputs into correlated chains, and produces the decision logic itself — risk scoring, attack path modeling, behavioral baselines, and policy recommendations. Without a strong DSA position, a vendor may collect signals from every domain and still lack the ability to turn them into decisions. This is the difference between collecting signals and having the analytical infrastructure to act on them. Vendors without DSA are not just missing a product line — they remain limited in their ability to operate at the SADL level, regardless of how many other domains they cover.

Impact of Trends on Companies

The following section briefly outlines how the five domains translate into practical organizational changes. Readers familiar with these effects from Part 1 may wish to proceed directly to the Conclusion.

The domain-by-domain analysis above shows how vendors are positioning themselves relative to SADL. But the same trends that drive vendor strategy also reshape the organizations those vendors serve — manifesting as concrete changes in architecture, processes, and operating models. Below is how this happens in practice.

AI

Leading companies are already applying these technologies in their day-to-day operations, and the range of use cases is extremely broad. As a result, organizations inevitably face new categories of tasks related both to the use of models and to their protection.

The following workstreams typically emerge:

• Local models and data privacy. Companies must decide which data may be sent to cloud-based models and which must remain confidential. This leads to the emergence of local LLMs or hybrid approaches: a local model for sensitive data combined with external models for broader, cross-industry tasks.
• Working with cloud models and controlling information flows. Even when local models are in place, companies continue to use global LLMs for quality and speed of innovation. This indicates a need to filter the information sent to the cloud (AI Gatekeeping) and to monitor potential channels of knowledge leakage.
• Model operations and lifecycle management. In practice, it quickly becomes clear that models must be updated, tuned, retrained, and monitored. This creates demand for specialists capable of maintaining AI infrastructure, as well as for MLOps processes.
• Building expertise and accumulating practical know-how. Organizations that begin experimenting earlier gain a noticeable advantage: they accumulate datasets, develop a better understanding of model behavior, and build expertise in managing AI-related risks. Late adopters will be forced to catch up.
• Balancing autonomy and security. Companies must define their own principles for what remains local, what is sent to the cloud, and how quality and risk control will be maintained across both environments.

Through these steps, a new AI operating architecture begins to take shape — one that combines local models, cloud services, control mechanisms, and model lifecycle support processes.

SASE / ZTNA / SSE

The transition to SASE / SSE / ZTNA models changes the way organizations approach access control and the behavior of network infrastructure. This leads to a set of typical organizational and technical effects.

The most common changes are:

• The distinction between “inside” and “outside” is disappearing. The access model becomes the same whether employees are in the office, at home, on a business trip, or connected through a partner network. In practice, this drives the adoption of unified policies and reduces dependence on the traditional perimeter.
• A requirement for transparency and minimal user involvement. The shift to ZTNA forces companies to rethink client access: most solutions must operate automatically, without manual tunnel selection, VPN choices, or route configuration.
• Increased pressure on traffic management infrastructure. SASE and SD-WAN distribute entry points, introduce dynamic routing, and require optimal path selection. As a result, companies increasingly begin to treat connectivity management as a service.
• Network policies become more complex because they must account for context. Static IP-based rules are no longer sufficient; they must now be supplemented with contextual attributes such as the user, device, risk level, and location. This affects the entire existing access model.
• Growing infrastructure requirements. To implement SASE/ZTNA successfully, organizations often need to refresh network components, simplify topology, and increase the level of automation.

SASE / SSE / ZTNA are the natural result of a changing environment: companies arrive at these technologies organically as soon as they begin supporting distributed teams and cloud applications.

Cloud

Working with cloud services brings not only new opportunities, but also the need to adapt architecture and processes. In companies, this almost always gives rise to a common set of challenges:

• Handling variable and unpredictable workloads. Cloud environments make it possible to scale services according to demand and business needs. This changes the approach to system design: architecture becomes dynamic, and security must adapt to an ever-changing environment.
• Rapid launch of services and experiments. Teams no longer wait for infrastructure. New development cycles emerge, along with persistent temporary environments and “hypothesis-testing” models. Security must integrate into these processes automatically.
• The emergence of services unavailable on-premises. Companies gain access to GPU clusters, large-scale storage systems, distributed queues, functions, and container platforms. This lowers the cost of experimentation and accelerates development, but also creates a need for visibility and control.
• The need to control a distributed architecture. Dozens of services, APIs, and microservices now reside in the cloud and communicate with one another while bypassing the traditional perimeter. This requires a reassessment of security models and the adoption of tools specifically designed for cloud environments.
• Hybrid models and a new infrastructure economy. Most companies move toward a hybrid model: some services run in the cloud, while others remain on local infrastructure. This changes the requirements for network connectivity, observability, and the integration of access and control policies.

Cloud is not a story of “better” or “worse.” It creates a fundamentally different operating environment — one that demands adaptation and architectural change.

Identity

The shift in security focus from network parameters to identity leads to fundamental changes in access management. In companies, this typically manifests itself in the following ways:

• Stronger authentication mechanisms and minimization of privileges. Multi-factor authentication, temporary access, role-based models, and automated privilege provisioning become foundational elements. Organizations need the ability to monitor changes continuously.
• Growth in the number of machine and service identities. Applications, containers, services, and microservices acquire identities of their own. Their number grows faster than the number of human users. Managing them manually becomes impossible, making automated oversight essential.
• Context-based decisions: moving from IP addresses to dynamic attributes. Access rules are increasingly built around risk levels, device types, behavioral profiles, time of operation, geography, service type, weighted combinations of factors, and the broader set of identifiers. This forces companies to rethink the architecture of their security policies.
• Automation of identity-related threat detection. Phishing, stolen tokens, and compromised keys all require ITDR tools capable of analyzing entity behavior.
• Seamless work with both external and internal participants. Collaboration with contractors, temporary teams, and partners creates a new set of requirements for access security: it must be frictionless, yet controlled.

Identity is becoming the architectural element that connects the user, service, device, context, and data — and this is changing the fundamental principles on which security policy is built.

Data Security Analytics

In the context of all the trends discussed above, Data Security Analytics acts as the layer where data, context, and decisions converge. It is here that signals from AI services, identities, cloud environments, and network telemetry come together to form a unified model of risk and behavior. As a result, the impact of DSA on companies is expressed not through the deployment of yet another tool, but through a change in the very logic of security management.

The shift from SIEM to broader data analytics forces companies to rethink how they work with events, assets, and risks. The most typical effects are:

• The focus shifts away from rules and toward behavior models, risk matrices, and regulatory compliance. Security is no longer just a set of correlation rules. Behavioral models, risk matrices, asset context, and regulatory requirements come to the forefront. Analysis now covers not only events, but also the relationships between them: infrastructure, data, and changes in the attack surface. This requires new data sources and new analytical competencies.
• It is impossible to cover the full spectrum of tasks using only internal resources. Even large companies tend toward a hybrid model: an internal team combined with external specialized teams such as MSSP, SOC, MDR, and analytics services. This makes it possible to close expertise gaps and scale without proportionally increasing internal headcount.
• A continuous cycle of “observation → interpretation → improvement” emerges. Data analytics is not a project with a fixed endpoint, but an ongoing process. Effectiveness comes from accumulating data, interpreting results, and continuously adapting models and processes to a changing threat environment.
• There is a critical dependence on the quality of knowledge about one’s own assets. Without an up-to-date and interconnected view of infrastructure, applications, data, and the changes within them, it is impossible to assess risks correctly and identify complex threats. Asset management becomes one of the foundations of security analytics.
• Data Security Analytics becomes a foundational component of the operating model on which the SADL layer depends. Organizations must rethink their processes, metrics, areas of responsibility, and tools. Security ceases to be a separate function and becomes part of the lifecycle of data and IT services.

As a result, Data Security Analytics requires systematic, long-term work: its effect appears only through the combination of data, expertise, continuous improvement, and coordination between technical and business teams.

Conclusion

The firewall market is no longer evolving around the firewall as a self-sufficient center of security architecture. What we see instead is the gradual formation of a distributed model in which decisions depend on data, behavioral patterns, identity context, cloud posture, and analytics across multiple domains. In that model, NGFW remains important, but its role becomes more specific: it acts as one of the enforcement mechanisms rather than the place where architectural logic is defined.

The diagram below is a simplified representation of the layered model discussed in Part 1: signals accumulate upward through data, context, and analytics, while governed decisions are formed above and then enforced through distributed controls.

The broader significance of the trends discussed in both parts of this article lies not simply in the expansion of vendor portfolios, but in the fact that modern security increasingly depends on the ability to combine heterogeneous signals into a coherent decision process. AI, SASE, Identity, Cloud, and Data Security Analytics do not just represent adjacent markets or additional product categories. Together, they point to a structural shift in how security decisions must be formed.

In this sense, SADL is not presented here as a finished market category or named product class, but as an architectural necessity that emerges when isolated controls can no longer make sufficiently informed decisions on their own. Once security depends on the correlation of telemetry, context, behavior, and risk across domains, some form of decision-making layer becomes unavoidable — whether organizations explicitly recognize it or not.

In that sense, the main point of this analysis is not that vendors are already “building SADL” as a clearly defined object. The point is that the market itself is producing the conditions that make such a layer necessary. Vendor strategy matters here not because it allows us to declare winners, but because it exposes where the architecture is under pressure to evolve.

The shift described in this article is therefore deeper than the evolution of NGFW. It is a shift from security as a collection of controls toward security as a process of governed decision-making. And if that shift continues, then the real architectural question for the coming years will not be which individual control becomes stronger, but how organizations combine data, context, and analytical logic into decisions that can then be enforced consistently across a distributed environment.

The practical question this analysis leaves every security leader with is straightforward: look at your current architecture and ask — where are decisions actually being made? If the answer is “inside individual products, based on their own data,” then SADL is not a hypothesis for you. It is a gap.

Disclaimer

All arguments, conclusions, and assessments in this article reflect my personal analytical perspective. The material has been prepared exclusively on the basis of publicly available sources, including vendor materials, analyst reports, industry publications, and public news. These views do not reflect and should not be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is analytical and educational in nature and contains no internal or confidential information.

Data current as of December 2025.

Originally published on Medium: [link]

Appendix: Signal Model

How Vendor Activity Is Interpreted in This Analysis

The following criteria were used to assess vendor presence across the five domains analyzed in this article. The weighted model serves as an internal consistency aid and should not be read as a formal ranking.

The purpose of this framework is not to assess the technical depth, completeness, or product quality of each vendor’s individual solutions. It is used more modestly: to interpret externally visible signals that indicate whether a domain appears strategically important for a vendor and how actively that vendor is moving into it. In other words, this is not a product ranking model. It is a way to read market behavior as evidence of broader architectural change.

Universal Criteria for Assessing Vendor Presence in a Domain

Four levels of domain presence are used: L0 through L3.

• L0 — No presence / No data
• L1 — Intent / Announcement / R&D / Low or early-stage participation and involvement
• L2 — A product or solution exists, but participation in the domain is limited or incomplete
• L3 — Full presence in the domain / Strong and recognizable solutions / A strategic player helping define the domain

To differentiate between these levels, each is assigned a weight: L0 = 0, L1 = 1, L2 = 3, L3 = 6.

L1, L2, and L3 are not development stages through which a vendor “progresses.” They represent different types of participation signals and are assessed cumulatively. Even in a fully established domain (L3), the presence of L1 and L2 signals strengthens the assessment of the domain’s resilience and strategic importance.

The assessment is based exclusively on open and externally observable signals. The methodology does not attempt to evaluate internal development quality, actual investment volumes, or the real commercial performance of a vendor’s solutions in each domain.

Signal Model Used in the Analysis

• L1.1 Strategic declaration of the domain
  (announcements, roadmap, presentations, references in strategy materials) — 2
• L1.2 Engineering activity
  (job openings, R&D publications, GitHub activity, patents, engineer talks) — 2
• L1.3 Practical validation
  (preview, beta, PoC, pilots) — 2
• L2.1 A commercial product exists that covers part of the domain — 3
• L2.2 A confirmed source of technology that enabled entry into the domain
  (M&A / strategic partnership / internal product build)
  (counted only if at least one of the following criteria is also met: L2.1, L2.4, or L2.5) — 3
• L2.3 Limited marketing activity
  (isolated case studies, blogs, webinars, or talks, without large-scale campaigns) — 3
• L2.4 Confirmed production deployments
  (customer stories, reference architectures, customer presentations, partnerships) — 3
• L2.5 Partial integration with other vendor solutions
  (core product stack / ecosystem / key product line) — 3
• L2.6 Irregular product releases — 3
• L3.1 The product or product line fully covers the domain — 6
• L3.2 Regular releases and active marketing support
  (excludes L2.6) — 6
• L3.3 The product is integrated with the vendor’s other solutions/products
  (excludes L2.5) — 6
• L3.4 Deployment scalability
  (multiple industries, multiple countries/regions, integration into core processes)
  (excludes L2.4) — 6
• L3.5 Presence in analytical market models
  (counted only if at least one other L3 criterion is present) — 6
• L3.6 Long-term strategic investment in the domain
  (M&A, business unit, R&D center, multi-year investment) — 6

The weighted model is used only as an internal consistency aid within the analysis. It should not be read as a formal ranking or as a claim about the technical quality of any vendor’s solutions. Its purpose is simply to make differences in strategic visibility across domains easier to interpret.

Vendor score / Maximum possible score × 100%

In this article (Part 1 of 2), I analyze how and why this is happening: which architectural shifts have already taken place, which directions have become defining, and what role NGFW occupies in the emerging security landscape.

This text will be valuable for IT and information security architects and engineers, domain and product leaders responsible for network security and platform solutions, as well as professionals working with NGFW projects and architectures.

Context for the Analysis

Over the past two years, the pace of change in the network security market has accelerated.

The mass transition to remote work, the rapid proliferation of cloud architectures, and the surge in development of Artificial Intelligence (AI) have created a combination of factors that has led to an accelerated transformation of both the role of NGFW and the entire network security domain.

In this part of the article, my focus is on architectural trends and factors that are reshaping the role of NGFW and shifting the centers of decision-making within security architectures.

Core Idea

Below are the key drivers behind the firewall market transformation in recent years.

Under the influence of these factors, two types of companies are increasingly visible in the market:

Universal companies — large vendors developing end-to-end solutions ranging from network security and cloud platforms to analytics and identity management.

Niche / specialized technology companies — teams that focus on deep expertise within one or several domains, such as (Cloud-Native Application Protection Platform (CNAPP), API Security, AI Security, etc.). These companies survive and succeed through rapid adoption of modern approaches, deep specialization in narrow areas, and collaboration with other ecosystem participants.

The Main Trends — in One Sentence

• NGFW has lost its role as the center of the security architecture — decision-making is shifting to the analytics level (Security Analytics Decision Layer (SADL)), and the firewall is now one of the policy enforcement points.
• AI has created a new domain, changed the nature of threats, reduced the value of traditional signature-based mechanisms, strengthened the role of context, and is reshaping established approaches.
• Secure Access Service Edge (SASE) / Security Service Edge (SSE) / Zero Trust Network Access (ZTNA) have integrated security and access control into the cloud, making the perimeter dynamic and distributed.
• Identity is becoming the foundation of security policy, shifting the focus from network parameters to entity attributes and risk levels.
• Data Security Analytics (DSA) consolidates knowledge, provides analytics, and stores all security events, forming the foundation for decision-making.

The market is constantly evolving: to remain a leader and compete successfully in the global market, companies must be capable of operating across multiple domains — from Cloud to AI and Identity — or deliver deep expertise and strong scenario implementation in narrow subject areas.

The Evolution of the Firewall

Within this article, I use the term Security Analytics Decision Layer (SADL) to refer to the layer of the security architecture where decisions and control actions are generated based on data, context, and behavioral models.

SADL is a conceptual architectural layer where security decisions are made independently of any specific vendor or component implementation. In essence, SADL can be seen as the “brain” of modern security architecture.

In this article, I examine current security trends through the lens of firewall evolution, as the development of firewalls clearly illustrates how security architecture models have evolved over the past decades.

The evolution of the firewall is, above all, a transformation of architectural models. At each stage, NGFW reflected the technological realities of its time — evolving from fixed perimeters and static packet filtering to application-level inspection, integrated security platforms, and distributed protection mechanisms across cloud and container environments.

The diagram below illustrates the key stages of this evolution.

The modern firewall acts as a policy enforcement point, executing policies defined at the SADL level while taking into account context, risk, and behavioral signals.

Below are the main technological domains in which NGFW becomes just one component of a broader security architecture:

• Cloud security and protection of cloud applications
• Container security
• Web / API security
• SD-WAN and connectivity management
• Endpoint / client security
• AI security and behavioral analytics
• Identity security / Identity Threat Detection and Response (ITDR)
• Data Loss Prevention (DLP), sandboxing, and other protection mechanisms operating at different layers

However, functions represent only half of the picture.

The other half consists of services and analytics that effectively replace the traditional “central firewall” model:

• Security Operations Center (SOC) as an operational function
• Extended Detection and Response (XDR) / Managed Detection and Response (MDR) as layers of visibility and correlation
• Data Security Analytics (DSA) as the foundation of SADL, providing context for decision-making
• Big Data as the domain of accumulating all necessary information
• Observability as the basis for behavioral analysis of systems
• Threat Intelligence as a dynamic threat model

It is services that provide the context on which modern security policies rely: risk level, behavior, identity, data type, and the degree of trust associated with an entity.

Artificial Intelligence (AI) and behavioral analytics further accelerate this shift. Signature-based IPS, DLP, and AV modules are no longer the primary line of defense — instead, they serve as data sources for hybrid models focused on context and behavior.

NGFW remains an important component of the modern security architecture, where protection mechanisms are distributed across cloud environments, network perimeters, endpoints, analytics platforms, and identity management systems.

The transition toward SADL emerged as a response to these changing conditions. It became possible to consolidate previously fragmented solutions not merely at a logical level, but within a unified core that enables correlation, knowledge enrichment, and a shared decision-making framework.

Industry Trends

The trends discussed below were identified based on observable changes in the industry, as well as on the extent to which vendors themselves actively invest in and position their capabilities within these domains.

In general terms, the structure of domains within modern security infrastructure can be represented as shown in the infographic above.

The technologies and directions within each domain are presented at a high level based on my analytical perspective to provide a general view of the landscape. The list is not exhaustive and can be further expanded and refined.

Artificial Intelligence (AI)

By 2024, it had become clear that AI capabilities were turning into a mandatory element of virtually every IT and cybersecurity product. At that time, however, AI was often perceived as a marketing trend, and its real practical value remained uncertain.

Over the past year, the situation has changed dramatically: AI has evolved into a distinct security domain with its own objectives, risks, and approaches, different from traditional security segments.

At the same time, cybersecurity vendors working with AI have themselves become targets of protection: their models, agents, processing pipelines, and infrastructure components are exposed to the same threats from which they aim to protect their customers.

AI also introduces a new attack surface, adding another layer on top of traditional network and application layers — models, data, and behavioral interactions.

Key technologies and domains in AI Security:

• AI Threat Protection — protection of Large Language Models (LLMs), agents, and AI applications (LLM / GenAI runtime security)
• AI Supply Chain Security / Model Integrity — protection of model training pipelines, distribution mechanisms, and update processes
• AI Data Security — prevention of data leakage through LLMs and AI agents; protection of Personally Identifiable Information (PII), Protected Health Information (PHI), and other sensitive data
• AI Identity Security — management of digital identities for models, agents, and services (machine / agent identity)

Why AI has become a standalone trend:

• AI has become a major focus of the market: investors expect growth in demand and revenue, while customers expect AI to expand their capabilities.
• AI/ML initially served as a differentiator for startups but has now become a baseline capability expected in most products.
• Properly integrated models can automate a large portion of routine operations and significantly reduce response times.
• The emergence of new AI-related risks has forced vendors to rapidly address issues of security, integrity, and availability — effectively creating an entirely new market within just a few years.

Impact and challenges for NGFW:

• NGFW must be able to detect and classify traffic related to AI services (LLMs, agents, API gateways) and incorporate this context into access control policies.
• Security policies must account not only for session parameters but also for the operational context of AI agents and models — including data types, service criticality, and the trust level of sources.
• NGFW must integrate with the broader AI security ecosystem, receiving signals from systems responsible for protecting models and data and incorporating those signals into network policy enforcement.

SASE / SSE / ZTNA

The emergence of the SASE / SSE / ZTNA domain is the result of the convergence between networking and cloud security technologies, including:

• Secure Web Gateway (SWG)
• Zero Trust Network Access (ZTNA)
• Software-Defined Wide Area Network (SD-WAN)

These technologies have been combined into a unified architectural model that provides secure access control and protection beyond the traditional network perimeter.

This trend developed gradually over time and became firmly established with the widespread transition to remote work and the migration of services to cloud environments.

Key technologies and domains:

• ZTNA 2.0 / Private Access — a zero-trust access model for users and devices
• Secure Web Gateway (SWG) — web traffic inspection, filtering, and protection against phishing and malicious resources
• SD-WAN — intelligent connectivity and traffic management across distributed infrastructures

While the broader SASE ecosystem includes additional technologies, SWG, ZTNA, and SD-WAN define its practical boundaries by addressing three core functions: client access, traffic control, and managed connectivity.

Why SASE / SSE / ZTNA became a lasting trend:

• Organizations require secure access to cloud services across a wide range of scenarios.
• Users must be able to work from anywhere with reliable and secure network connectivity.
• The ability to dynamically manage service availability and routing based on context has become critical.

Impact and challenges for NGFW:

• NGFW becomes part of the SASE architecture as a policy enforcement point and a source of telemetry, gradually losing its role as the central entry point to the infrastructure.
• The role of traditional VPN continues to decline: remote access increasingly relies on ZTNA, while branch connectivity is increasingly implemented through SD-WAN.
• Application-level inspection and encrypted traffic analysis become mandatory capabilities — NGFW must understand services and applications, not just protocols.

Identity Security / Identity Threat Detection and Response (ITDR)

Until recently, identity-related technologies were primarily viewed as infrastructure components rather than a distinct strategic trend.

In 2025, the situation changed significantly following Palo Alto Networks acquisition of CyberArk, one of the global leaders in privileged access management and machine identity security.

This deal has major implications for the market, as it brings together two major domains — Identity and Security — within a single ecosystem, creating strong momentum for a shift toward identity-centric security models.

This may represent a forward-looking move by a major market player seeking to gain strategic advantage in the upcoming architectural transformation.

Many security vendors already rely on identity signals (device ID, IoT device profiles, user accounts), but identity may now become the foundational model for security policy and one of the central elements of modern security architecture.

A new approach to policy definition may emerge — one where rules are defined based on entities and their attributes rather than static network parameters. Similar approaches have long been used in anti-fraud systems, where decisions depend on combinations of dynamically calculated attributes.

Key Identity Security / ITDR domains:

• Identity Threat Detection & Response (ITDR)
• Machine / Service Identity Security
• Identity Governance & Administration (IGA)
• Privileged Access Management (PAM)

Why this has become a major trend:

• The identity technology market has grown sufficiently to attract major cybersecurity vendors.
• Almost every organization already uses at least part of the identity stack, creating natural demand for consolidation and expansion.
• Without understanding the origin, trust level, and behavior of an entity, it is impossible to ensure effective security.

Impact and challenges for NGFW:

• IP-based policies no longer reflect reality. In cloud, containerized, and service mesh environments, IP addresses change dynamically or may be abstracted behind multiple infrastructure layers.
• NGFW must operate with real-time identity context and make decisions based on dynamic entity attributes rather than static network parameters.
• Security decisions must incorporate more contextual information: who interacts with the data, how it is used, and under what conditions.

Entity attributes may include device type, trust level, role, behavioral characteristics, risk score, service affiliation, workload type, and other contextual signals.

Machine identities are growing exponentially: each service may rely on multiple keys, tokens, certificates, and service accounts — many of which become potential sources of security incidents.

Cloud

Cloud architectures have become a defining factor not only in terms of service placement, but also in reshaping traffic patterns. A significant portion of interactions now occurs within cloud environments and no longer passes through the traditional network perimeter. This significantly reduces the role of the traditional perimeter security model.

For most modern security products, including firewalls, cloud capabilities are no longer optional — they are a requirement. Protection is needed not only for the “corporate network segment,” but also for distributed applications, data, and services operating in dynamic cloud environments.

Key technologies and domains in Cloud Security:

• Cloud-Native Application Protection Platform (CNAPP) — protection of cloud-native applications
• Cloud Security Posture Management (CSPM) — configuration management and policy compliance monitoring for cloud infrastructure
• Data Security Posture Management (DSPM) — analysis and management of data-related risks
• Cloud Infrastructure Entitlement Management (CIEM) — management of identities, permissions, and privileges in cloud environments
• Container / Kubernetes / extended Berkeley Packet Filter (eBPF) Security — protection of containers, clusters, and workloads
• API Security — protection of application programming interfaces

Why Cloud has become a dominant trend:

• Cloud platforms enable rapid deployment and scalable business growth.
• The number of services deployed in cloud environments continues to increase.
• Distributed architectures improve system reliability and availability.
• The variety and capabilities of cloud services — including Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) — provide extensive opportunities for experimentation and innovation.
• Initial data processing is significantly easier and faster in cloud environments, allowing only valuable information to be exported to on-premises storage.

Impact and challenges for NGFW:

• The perimeter in cloud environments becomes dynamic — fixed boundaries disappear, and control points are distributed throughout the infrastructure itself.
• Traffic inspection must occur as close to the data and workloads as possible, within the same environment where processing takes place (e.g., service mesh, eBPF-based mechanisms).
• A substantial portion of modern traffic never leaves the cloud: service-to-service, API-to-API, and container-to-container interactions dominate. As a result, NGFW sees only part of the overall communication landscape and must integrate into the infrastructure rather than remain at its edge.
• NGFW must take cloud context into account — object type, service type, namespace, identity, and other attributes — since these parameters determine policy decisions in cloud-native architectures.

Data Security Analytics (DSA)

Data Security Analytics (DSA) is one of the key sources of signals and analytical models for SADL, but it is not SADL itself. SADL represents a higher architectural layer that consolidates DSA with other data sources and enables unified decision-making.

In the domain of security event analytics, another evolutionary shift has occurred. The role of the traditional Security Information and Event Management (SIEM) system has declined — it is no longer the sole architectural center of security analytics.

Most attacks are not detected through static correlation rules. As a result, analytical approaches beyond traditional SIEM capabilities are required, including:

• Behavioral modeling
• Risk context analytics
• Dependency and relationship analysis
• Automated anomaly detection
• Event progression prediction

As a result, SIEM has become one of the components within SADL — the decision-making “brain” that evaluates multiple signals and determines control actions based on behavioral models defined by operators.

Major vendors are building portfolios of analytical services that may be embedded within Security Operations Centers (SOC), integrated directly into security products, or delivered as standalone analytical platforms.

In this model, the value of NGFW is determined by its ability to provide high-quality telemetry to these analytical ecosystems.

At the same time, smaller players continue to succeed in this domain — outcomes often depend not only on the products themselves but also on the expertise of the teams delivering the services.

Key technologies and domains in Data Security Analytics:

• Data Risk Analytics / Exposure Management / Attack Surface Analytics — analysis of risks, attack surfaces, and asset visibility
• Security Telemetry & Observability — collection, aggregation, and interpretation of low-level telemetry signals
• Global SIEM / Log Analytics / Big Data Security Analytics — unified layers for telemetry processing and multi-level security analytics
• Extended Detection and Response (XDR) / Managed Detection and Response (MDR) / Threat Detection Analytics — behavioral analytics of devices, users, and services

Impact and challenges for NGFW:

• The role of the firewall in Data Security Analytics is defined not by traffic filtering capabilities, but by the quality of telemetry and contextual data it can provide to analytical systems.
• Integration with analytical platforms becomes essential — competitive advantage increasingly belongs to solutions that integrate seamlessly into data collection pipelines and dynamic policy enforcement mechanisms.

The Concept of the Security Analytics Decision Layer (SADL)

To better understand the place and role of the Security Analytics Decision Layer (SADL) within modern security architecture, the simplified conceptual reference model below illustrates its structure.

The model shows how information from multiple sources passes through several processing stages, becomes enriched with context, undergoes deeper analytical processing, and ultimately converges within the SADL core — the central decision-making layer.

From this level, fully formed policies and control actions flow downward to enforcement points (including NGFW, which represents only one of many execution points).

Brief Description of the Layers (Bottom to Top)

Data Level

Sources of raw data, events, and telemetry: NGFW (flows, sessions, applications), Threat Intelligence, Asset Inventory, AI runtime environments, Cloud logs (Kubernetes (K8s), Cloud Infrastructure Entitlement Management (CIEM), Cloud Security Posture Management (CSPM)), Identity systems (Identity and Access Management (IAM), Identity Provider (IdP), Privileged Access Management (PAM)), Endpoint Detection and Response (EDR) / XDR, and others.

This is the foundational layer where signals from all infrastructure components are collected.

Context Level

Context enrichment and entity resolution.

Entities may include: User, Device, Workload, Service, Data Object, Credential, Session.

This layer identifies subjects and objects, applies temporal context, and enriches signals with behavioral and environmental attributes.

Analytics Level

Deep analytical processing and risk scoring.

This layer includes: User and Entity Behavior Analytics (UEBA), anomaly detection, partial risk scoring, attack path modeling, event correlation, predictive analytics

At this stage, raw data is transformed into meaningful threat signals and analytical insights.

SADL Core Level

Consolidated decision-making.

Key functions include: composite risk engines, compliance analysis, business impact assessment, policy logic evaluation, feedback and learning mechanisms

This layer builds a unified risk picture and produces adaptive decisions — not simply allow or deny, but context-aware policies that account for business priorities and regulatory requirements.

Orchestration Level

Execution orchestration and automation.

Through APIs and automation engines, decisions are translated into low-level commands delivered to enforcement points such as NGFW, ZTNA, SWG, EDR, and others.

Key Principles of the Model

• SADL is not a product, platform, or vendor ecosystem.
  It is an abstract architectural layer that exists above individual components and remains independent of specific suppliers.
• All enforcement mechanisms (including NGFW) connect to SADL as execution points.
  Decisions are formed at the SADL level rather than at the network perimeter or within isolated security products.
• Information flow is bidirectional: telemetry and signals move upward for analysis, while policies and commands flow downward for enforcement.
• Feedback and learning close the loop. The system continuously improves by learning from real events and operational outcomes.
• Data Security Analytics (DSA) represents one of the key analytical engines and signal sources feeding SADL — but it is not SADL itself. SADL functions as the higher-level architectural layer that consolidates multiple analytical domains.

This conceptual model explains why, in 2025–2026, NGFW is no longer the central element of security architecture, but rather one of many enforcement points responsible for executing policies formed at the SADL level.

This architectural approach enables the transition from static rule-based security models toward dynamic, context-driven protection suitable for distributed and cloud-native environments.

Interim Conclusions

We are at a point where the traditional network security model is evolving under the pressure of growing scale and the increasing diversity of modern architectures.

Practices that emerged over the past 10–15 years — from the concept of a unified network perimeter and segmentation to NGFW-centric security architectures — are no longer sufficient in a world defined by cloud computing, distributed applications, SASE, identity-centric security models, rapidly expanding AI ecosystems, and the growing influence of Data Security Analytics.

In Part 2, I will continue analyzing these trends through the lens of how NGFW vendors themselves are adapting to these changes. I will show how leading vendors simultaneously become both the result and the driver of this transformation — and how their strategic decisions shape the future structure of the market and ultimately affect end customers.

All reasoning, conclusions, and assessments presented in this article reflect my personal viewpoint. The material has been prepared exclusively based on publicly available sources (vendor materials, reports from analytical agencies, industry publications, and open news sources). These views do not reflect and cannot be interpreted as the official position of any organization with which I am currently or have previously been affiliated. The article is purely analytical and educational in nature and contains no internal or confidential information.

Data current as of December 2025.

Originally published on Medium: [link]