Competing with layer zero in cybersecurity

Exploring the idea of a “layer zero” - why it matters, what makes it powerful, and how security startups can strategically position themselves around it.

I am not aware of anyone who has previously attempted to define the concept of layer zero in security. Chances are, you will be able to point out many holes in this idea, but having seen how the industry operates and how the products are built, I strongly feel the concept of layer zero needs to exist. It explains with incredible clarity how security leaders should be thinking about coverage, how founders need to approach building in security in order to win, and how investors should be evaluating startups.

---

This issue is brought to you by… Chainguard.

The Cost of CVEs Report 2025

How much do CVEs cost your business?

Managing CVEs are costly in a variety of different areas. To measure this cost, and the return on investment organizations can expect when utilizing outsourced solutions for CVE management, Chainguard interviewed several industry leaders and quantified the amount of money these organizations unlock in areas like cost savings, increased revenue, faster innovation, and decreased risk.

---

---

Definition of layer zero

For the longest time, I believed that security is fundamentally a property of technology itself, not merely a standalone product. While we tend to define security as a market, with vendors, tools, and platforms dedicated solely to protecting people and organizations, another way to look at it is to treat it more like reliability or quality: an emergent trait of how a system is designed, built, and operated. Generally speaking, I think most in the industry would agree that tools can do a good job enforcing security policies or monitoring for issues, but they can’t successfully retrofit security onto a system that wasn’t architected with it in mind. This is why security efforts that happen too late in the lifecycle often feel brittle, unintuitive, expensive, and incomplete.

If we follow that logic, then the entities best positioned to deliver real security are the ones building the core technologies. A cloud provider is logically in the best place to solve cloud security; an operating system vendor is closest to solve endpoint security; an email provider sees everything that flows through their infrastructure so they should be in the best position to solve email security; an identity provider already governs user access so they should be able to take care of identity threat detection and response effectively. These foundational providers own the systems that define how security boundaries are created, how access is enforced, and how data flows, so they have the ability to bake security in. It is these providers that I define as layer zero.

Layer zero refers to the foundational layer of infrastructure and technology that other tools depend on. It’s where control points often emerge - identity platforms, cloud service providers, and operating systems. These are not just passive infra providers; they actively shape the rules of engagement for all other tools. For those that own layer zero, adding security is often just an architectural decision (a toggle, an API extension, a bundle, etc.), while for everyone else, namely the vendors operating on top of these platforms, delivering security becomes a negotiation with the underlying layer. That’s the power of owning the foundation, and the challenge for everyone who doesn’t.

The layer zero advantages

The layer zero players have a strong set of advantages that often enable them to win against stand-alone security companies.

First of all, layer zero providers sit directly on top of the control planes that define how systems operate - identity, compute, networking, data access, and so on which gives them privileged visibility and enforcement power that external vendors simply can’t replicate. For example, an identity provider knows exactly who is logging in, from where, and with what context, before any downstream system even sees the request, while a cloud provider can observe workload behavior at the hypervisor level. This proximity enables more precise security decisions and makes it easier for layer zero players to intervene early before issues escalate.

Second, because layer zero providers already operate within the core infrastructure, their security offerings require little to no integration effort. There are no third-party agents to install, no new data pipelines to configure, and no new vendors to onboard. Security becomes a native part of the workflow, often turned on with a single toggle. For enterprises under pressure to reduce complexity and vendor sprawl, this ease of adoption is a major advantage and a barrier for outside vendors trying to compete on feature depth alone.

Then, there’s the trust factor. I often talk about the critical role trust plays for cybersecurity companies, and when it comes to layer zero, trust is a given. Customers are already relying on layer zero providers to run critical parts of their business, so there’s inherent trust in their brand, infrastructure, and uptime. When a cloud provider, for example, offers a security product, customers often assume it will “just work” with the rest of their environment. This leads to fast, default adoption, especially in greenfield environments or among teams that prioritize convenience and alignment over customization. That initial foothold can then be expanded into adjacent areas of security over time.

Another critical factor is the economic bundling power. Layer zero providers can bundle security features with their core services, often at a lower marginal cost than any standalone competitor could match. These offerings don’t need to be priced aggressively because they’re subsidized by the broader platform spend. In many cases, customers don’t even compare them to third-party tools, they’re simply included, oftentimes for “free”. This bundling creates powerful lock-in effects and makes it difficult for external vendors to justify a separate line item, even when they offer more advanced capabilities. Microsoft has done a great job in this with their E5 licenses.

Layer zero providers have a huge roadmap leverage and ecosystem control power. Because they define the interfaces that other vendors rely on (APIs, telemetry streams, data schemas, etc.), layer zero providers have structural control over the pace and direction of innovation. They can introduce new capabilities before others, restrict access to critical signals, or shift pricing models in ways that force downstream vendors to adapt. This leverage often goes unnoticed until it’s used, but it can impact every security vendor building on top of someone else’s foundation.

With all these advantages combined - visibility, integration, trust, bundling, and leverage - layer zero providers are well-positioned to expand horizontally into other security categories. They don’t need to be best-in-class; they just need to be close enough to the customer’s core workflow that switching costs are too high. Over time, this leads to consolidation: platforms that started in infrastructure or identity gradually absorb security functions that used to belong to independent vendors. In the long run, being the platform often beats building for the platform.

Layer zero disadvantages

It wouldn’t be fair if we only looked at the advantages layer zero platforms get to enjoy since each of them also has several disadvantages, including the following:

• For most layer zero providers, security is not the primary product, it’s an add-on. This can lead to slower innovation, limited features, and lack of depth compared to vendors focused solely on solving complex security problems. This is exactly what gives a chance to “best of breed” security startups.

• Because the security offerings of layer zero providers are meant to work broadly across the entire customer base, they’re often overly generic, one-size-fits-all products. Enterprises with unique environments or edge cases (and let’s be honest, that’s most companies out there given how unique everyone’s environments are) may find the built-in tools insufficient or inflexible.

• Layer zero solutions often function as black boxes. Customers may struggle to customize detection logic, extend functionality, or integrate with internal systems - areas where dedicated security platforms typically excel.

• When the same provider is both the infrastructure host and the security monitor, there’s an inherent tension and a conflict of interest of some sort. Some organizations hesitate to trust CSPs or IDPs to detect and report on their own misconfigurations or failures.

• Relying on a single platform for both infrastructure and security increases dependency and over time leads to the ecosystem lock-in. This tight coupling can make migrations, audits, or multi-provider strategies more painful, reducing architectural flexibility and forcing companies to stick with solutions that don’t really address their problems well.

• Layer zero providers tend to prioritize scale and stability, which can delay their ability to react quickly to niche, novel, or fast-evolving attack vectors. Niche, “best of breed” security vendors often outperform them in speed and specialization.

Competing with layer zero

Understanding layer zero and mapping value prop against its reality

I don’t think anyone can define any rules for startups dealing with layer zero: they dictate the rules of engagement, and the rest of us have to deal with that. However, I think it may be helpful to get some sort of a framework to reason about this.

When startups think about building on top of layer zero, the first question to ask is whether that foundational layer is consolidated or fragmented. In highly fragmented ecosystems like SaaS, where each provider handles access, logging, and security differently, there’s enormous value in abstracting away the mess. Startups that offer multi-provider orchestration, unified visibility, or policy normalization can create order out of chaos. This becomes especially compelling in environments where the sheer number of vendors, and their inconsistent security models, create operational sprawl.

Another signal to evaluate is API maturity. Many layer zero platforms offer APIs, but not all are well-documented or stable. While understanding the lay of the land is important, it’s hard to come up with a recommendation for what to do because there are at least two ways to see it. For example, when there’s no easy way to integrate fragmented telemetry sources, it can be super hard to build a security platform, but at the same time, it may create a natural opportunity to add value by building a telemetry normalization layer, enriching it with context, and making it usable by security teams or other platforms. Over time, this can evolve into a security data layer that improves downstream detection, automation, and auditability. Think about a solution like Forward Networks: I can’t even imagine what it takes to be able to pull configurations from different kinds of network devices that don’t talk to one another, all use different standards, etc., but if you can do it, it creates the kid of moat that nobody else can come close to.

The next dimension is how seriously the layer zero provider takes security. If security isn’t core to their business (and often it isn’t), there’s a clear opportunity to go deeper. Startups can deliver best-of-breed tooling: think advanced data loss prevention (DLP) for SaaS apps with no native controls, or posture management for the cloud that goes deeper than the CSPs native tools ever will. Even when the provider does invest in security, their roadmap pace matters: many layer zero platforms move slowly, leaving room for startups to be more responsive to emerging threats, regulatory changes, or industry-specific requirements.

Cross-provider inconsistency is another powerful vector. If one cloud or IDP provider handles IAM completely differently than another, that asymmetry becomes a wedge. Startups can build unified policy engines, cross-cloud governance layers, or access management orchestration that simplifies life for customers operating in multi-cloud or multi-IDP environments. The same logic applies to the center of gravity in the platform: some layer zeros are user-centric (identity), others system-centric (cloud), and others data-centric (SaaS). Knowing where control lives helps define whether your startup should focus on users, infrastructure, or sensitive data as the core object of control.

What’s equally important is how customers feel about their products. Where there’s frustration, blind spots, alert fatigue, and security friction, there’s room for startups to create user-facing value. Dashboards, delegated workflows, and compliance tooling that bridges across systems can make the lives of security, IT, and GRC teams easier. Success here also depends on how open the platform is to integration and distribution: if it has a robust partner ecosystem or marketplace (like AWS or Okta), startups can go deep on native integrations to gain trust and adoption, but if the platform is closed or competitive, then startups have focus on surface areas that don’t rely on internal blessings to function.

Finally, it's critical to identify the strategic blind spots of the layer zero providers, like areas they deliberately avoid. Okta, for instance, historically avoided securing non-federated apps, which created an opportunity for companies like Cerby. These blind spots are prime territory for startups to build complementary tooling that solves problems the platform won’t touch. If the provider is likely to enter your space, the best bet is to build something so deep, verticalized, or operationally embedded that it wouldn’t make sense for the layer zero platform to replicate, or even better, something that enhances their platform’s own value, making you a welcome extension rather than a threat. In general, I think it’s a pretty bad idea to build something that threatens layer zero or impacts their core business models. Eventually, they will retaliate, and when they do, it can put the startup out of business. A good example here is ad blockers: when browsers make money when people click on ads, believing anyone can build a business blocking their revenue generation channel is simply not smart. Google let ad blockers run for a while, and then it made changes to extensions that essentially put an end to their existence.

Facing layer zero in different segments of security

Identity security

Identity is a foundational layer where control over access naturally extends into security. Originally connectivity tools, identity providers like Okta and Entra ID have become security gatekeepers because access is a single chokepoint, and once you’re the IDP, you can build IGA, enforce policy, and run analytics on top. From a layer zero standpoint, identity is highly consolidated and sticky since most companies only have one IDP, and it serves as the source of truth. APIs are relatively mature, and vendors like Okta have broad ecosystems, but the space is slow-moving and politically sensitive, especially after breaches and outages. Security startups here can add value by targeting areas where the IDP is either not solving the problem at all (e.g., non-federated access), too rigid (e.g., custom policy flows) or too weak (e.g., non-human identity). The best wedge is often via complex identity sprawl that IDPs can’t cleanly manage, and where reducing complexity and managing identity risk across environments create room for the focused play.

Network security

As a layer zero, the network layer has historically been quite centralized but now it is in transition. Many organizations still have on-premises networks, especially in regulated or hybrid enterprises, but cloud and edge computing have fragmented the picture. Getting data from the network gear is very hard because legacy vendors make integration very painful. Layer zero in network is often vendor- and hardware-bound, which makes it much easier for someone like Cisco to add security as a feature on top of their offerings. At the same time, few enterprises only have network devices from one vendor so startups can add value by addressing multi-vendor sprawl, particularly in large organizations with a lot of legacy network equipment. I think companies like Tufin have done that pretty well.

Cloud security

Cloud providers are now the underlying network and compute layer, and competing with them means going against their distribution, telemetry access, and pricing power. As a layer zero, cloud is highly consolidated and vertically integrated because CSPs own the platform, the security tooling, the APIs, and data workflows. They offer rich APIs, but pricing and access models create asymmetric competition: GuardDuty, for example, gets flow logs “for free,” but a startup doing cloud detection would need to either get the customer to pay for VPC flow logs, or deploy agents which come with a lot of friction.

Layer zero in the cloud is privileged because cloud providers set the rules and reap the margin. The best startup opportunities are in cross-provider, multi-cloud security. Each cloud handles IAM, networking, encryption, and policy differently, and by sitting on top and normalizing policy or telemetry, startups can reduce multi-cloud operational burden, and provide a uniform security experience, something players like Wiz, Upwind, and Sysdig have done pretty well.

Application/product security

In application and product security, the control layer is the development platform where the code is written. I think what makes this area unique is that we might be living through the change in layer zero. For the longest time, GitHub and GitLab were able to embed security features directly into the dev workflow: scanning, SBOMs, secrets detection, etc. These offerings were far from being “best of breed”, but for many companies, they were good enough.

Today, where developers spend most of their time is changing, and so layer zero for security is moving from repositories like GitHub to generation engines like Cursor. It’s hard to predict what’s going to happen in this space because while it’s obvious that more and more code will be generated by AI, it’s not clear who will own code security. Logically, code generation apps will need to show that they are generating secure code, or else companies will not be happy to adopt them. On the other hand, it’s also unlikely that these new layer zero players will be able to solve the problem in its entirety. AppSec has always lagged behind developer workflows, but now with AI-assisted coding that may (at least in theory) change.

Endpoint

In endpoint security, layer zero are OS vendors. For the longest time, third-party players thrived because built-in tools were weak, but that seems to be changing. Not only has Microsoft turned Defender into a very solid offering (that’s the feedback I’ve been hearing anyway), but it is also changing the attitude towards third-party agents. While in the past, antitrust pushed Microsoft to make kernel-level APIs open, following last year’s CrowdStrike outage, it now has a strong argument to tighten access. Apple’s OS control has been making third-party security innovation nearly impossible for quite some time. All this means innovating on the endpoint is getting harder: the OS owner will always have the easiest path to deep visibility and control, and they are increasingly more aggressive about restricting that access.

Layer zero on the endpoint is completely consolidated. Microsoft and Apple own the platform, APIs, telemetry, and distribution, kernel access is shrinking, and API control is weaponized so privileged access to telemetry is becoming a moat. The most viable startup strategies seem to be those that operate at the edge of the OS like device trust or cross-device compliance policy layers although I’ve also seen some prevention companies. Endpoint sprawl across personal and corporate devices creates an opportunity to build lightweight overlays that don’t depend on kernel access but still deliver value (e.g., secure sessions, data controls, or identity-aware execution, likely powered by eBPF).

Browser

Browser is emerging as an unexpected but powerful layer zero that governs how users access applications, what policies are enforced, and what data can move where. While mainstream browsers like Chrome and Firefox sit at this chokepoint, they are fundamentally consumer products with ad-based business models, which makes them structurally incompatible with enterprise security needs. For years, I believed that Google or Mozilla would eventually release their “enterprise” versions and crush any startup trying to build a secure browser. Then Google released one and I realized that I was wrong, because my original assumption missed two key dynamics: business model and go-to-market motion. Google doesn’t sell to enterprises in the way Microsoft or AWS does. Chrome is free, ad-funded, and optimized for scale, and not enterprise control. More importantly, Google has never been good at enterprise sales, so the chances are pretty low that it will be different with the enterprise browser (we’ll see what happens with Wiz but that’s an entirely different story).

What makes browser as layer zero so unique is that it’s changing how the enterprises access the work itself. As SaaS replaces on-prem apps and the browser becomes the new OS, the shift mirrors what happened in networking and cloud over the past decade: SASE replaced hardware firewalls, cloud absorbed the network layer, and now, the browser is becoming the new delivery point for security and productivity policy.

Sometimes there’s no layer zero

While I think it’s important that founders understand the dynamics surrounding layer zero, I think it’s equally important to understand that not every area of security has one. A great example of a large critical market segment that doesn’t have layer zero is the Security Operations Center (SOC).

SOC is unique because it doesn’t own any infrastructure, control planes, or foundational systems. Instead, it sits above them, aggregating telemetry from the real layer zeros like cloud, identity, endpoint, network, etc. That aggregation role introduces opportunity: while individual control planes are increasingly vertically integrated and vendor-consolidated, SOCs remain horizontally oriented. This means startups can build value by normalizing signals across fragmented environments (e.g., multi-cloud, multi-IDP, multi-endpoint), enriching them with context, and improving detection and response. The fact that SOCs operate downstream from layer zero tools gives them a broad lens and allows them to correlate what no single layer zero sees in isolation.

Another example is data. Data security is uniquely chaotic because data flows across apps, clouds, endpoints, and users. There’s no single control plane for data, so the opportunity is endless but fragmented - any startup in data is essentially chasing data and trying to detect, classify, and protect it across formats and environments. Unlike identity or network, data doesn’t sit at a chokepoint; it leaks, copies, syncs, and transforms. Customer expectations are also changing: when DLP was new, startups could focus on one domain (network DLP, endpoint DLP, cloud DLP, etc.) but now that the market has matured and the data moves fluidly, it’s hard to sell a product to CISOs that “will protect data here, but not there.”

The layer zero in data is nonexistent and highly fragmented. There’s no dominant platform, no stable API layer, and no standardized interface. Every integration is bespoke, which means that the surface area is huge, but so is the work required to manage it. Startups win here by building synthetic control planes, pulling together signals from SaaS, cloud, network, and endpoints to create a unified data graph. The sprawl makes multi-environment policy enforcement valuable, especially in verticals with sensitive or regulated data. As AI models start generating and consuming more proprietary content, there’s a new kind of layer zero emerging, a model-level data access, which may create fresh opportunities in data lineage, leakage prevention, and provenance assurance. Frank Wang recently published a good article about data security.

Closing thoughts: working with layer zero, not against it

I don’t generally like sensationalist and clickbait-like statements but I don’t think I can avoid making one in this context: many startups have died because they tried to fight with layer zero, so it’s generally a very bad idea to do that. It comes down to the simple truth that any security startup attempting to build a product that makes it harder for Google to make money on ads, has a high likelihood of getting killed. It may not happen immediately, but it will happen eventually if it becomes a real threat to layer zero (or makes some product managers really mad). The same is true for any security product that bricks an operating system or makes it harder for Microsoft to sell its E5 licenses; any network security solution that makes it hard for Cisco to sell its networking equipment, and most definitely any cloud security startup that makes it hard for cloud providers to make money on compute. This doesn’t always mean it’s not worth trying, but it’s important to understand the core business of the layer zero platform.

The emphasis is on the “core business” because every layer zero provider is inherently in the state of "coopetition" (cooperation and competition at the same time) with its partners. CSPs, for example, are both selling their own CSPMs primitives say, GuardDuty), and solutions from independent vendors that compete with them (say, Wiz). That is totally fine because to CSPs, cloud posture management is not their core business (in fact, they need customers to feel more secure so that they consume more cloud services).

---

If you like my blog, please subscribe & share it with your friends. I do this in my free time, so seeing the readership grow helps me to stay motivated and write more. I don’t send anything except my writing and don’t sell your data to anyone as I have better stuff to do.

If you are a builder - current or aspiring startup founder, security practitioner, marketing or sales leader, product manager, investor, software developer, industry analyst, or someone else who is building the future of cybersecurity, check out my best selling book, Cyber for Builders.

If your company is interested in sponsoring Venture in Security, check out Sponsorships. Thank you!