December 2025.

In 2024–2025 alone, the major vendors covered in this analysis committed tens of billions of dollars to acquisitions — and almost none of that capital was aimed at building a better firewall. It went toward AI, identity, analytics, cloud security, and adjacent areas. That pattern reveals something more important than any individual product announcement: the firewall market is no longer evolving around the firewall itself.

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.

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%