There’s an old story about a group of blind people who come across an elephant for the first time. Since they can’t see it, each of them tries to understand what it is by touching a different part. One person grabs the trunk and says the elephant is like a snake, another feels a leg and says it’s like a tree, a third touches the ear and thinks it’s like a big fan, and someone else holds the tail and says it’s like a rope. Each of them is sure they are right, because what they feel is real to them, and they definitely are, even if they don’t fully realize that each of them only has one part of the story. I’ve seen different versions of this story; in some, people start arguing and fighting over who is right, and in others, they work together to complement each other’s learning and perspectives.

This issue is brought to you by... Island.

Say Yes to AI—Without Leaking Your Data

Employees are already using AI tools, whether you’ve approved them or not. The real risk isn’t AI itself. It’s sensitive data slipping into prompts with zero visibility or control.

Island AI Protect secures AI at the point of use: the browser. It monitors every prompt and response in real time, blocking or redacting sensitive data while giving security and IT teams full visibility into AI usage.

No bans. No friction. Just safe, governed AI adoption.

Watch how AI Protect works in action

I am sure you already understand where I am going with this, and if you do, you are probably almost right. I say “almost” because there are two ways in which this story manifests itself in security.

Image Source: Sketchplanations

Our individual backgrounds define how we see security

There are many things about cybersecurity I find fascinating, but one of the biggest is that, as an industry, we can’t agree on what security is, how to do it well, or even what matters most. I’ve realized that this isn’t random, and everything comes down to where people come from. How someone sees security is largely defined by the roles they’ve held, the kinds of companies they’ve worked in, and what they’ve been responsible for.

A big reason for this, I think, is that very few people actually go to school to study security in a formal way. That’s very different from other fields, where everyone spends a few years building the same foundation at school before starting to work. Sure, people pivot careers everywhere, but most accountants study accounting, most biologists study biology, and so on (I haven’t checked the data, so take this as anecdotal, but it generally holds up). In security, there isn’t much of a shared baseline. People come in from all walks of life, learn on the job, and only later pick up more standardized knowledge through certifications or experience. That’s what makes our industry so diverse, but also why perspectives we hear can vary so much from one person to another.

While everyone’s experience is definitely unique, I think you can often tell how someone thinks about security just by understanding their background. It’s not a perfect rule (people are more complex than that), but I think I can say that more often than not, these generalizations are at least somewhat true.

Six examples of how our backgrounds inform how we see security

Security leaders with a background in software and security engineering

Security professionals and leaders with a background in software engineering tend to see cybersecurity as a technical problem that can be solved with better systems, better design and architecture, and more consistent processes.

Former engineers turned security leaders tend to see security as something you can build and improve through better systems. They think in terms of architecture, automation, and fixing problems at the source, which is why their teams are often more engineering-driven. They are more likely to build their own detections, create internal tools, and design systems that are secure by default. In tech companies, especially, where customers often ask how their data is protected, CISOs sit closer to revenue than in most other industries, which is why when you hear someone talk about security as a competitive advantage, they’re often coming from tech background. Not surprisingly, many companies in the Bay Area, and tech companies more broadly, hire heavily from this pool of candidates.

Security leaders with a background in IT

Security professionals and leaders with a background in IT and infrastructure security often come from much more complex environments than their software engineering peers, where security is a part of keeping the business running. They know that not every company is a software company, and that sometimes you have to secure what you have because you don’t have the luxury of rebuilding the entire infrastructure from scratch. They focus on managing systems, controlling access, patching vulnerabilities, minimizing downtime, and designing processes that enforce consistency at a large scale. This may sound less exciting than building new tools, but it’s exactly what their companies need to stay secure. When you’re dealing with 5,000 to 50,000 employees across different states or countries, each with its own constraints, security becomes less about having a flashy solution and more about maintaining visibility, control, and reliability across a very large and complex environment.

Security leaders with a background in law enforcement

Security professionals and leaders with a background in law enforcement often approach cybersecurity through the lens of investigation and accountability. They are used to thinking in terms of cases, i.e., what happened, who was involved, and how to put together a clear story from incomplete information. This often (but as I’ve said, not always) influences how they build security programs, with a strong emphasis on visibility, detection, and understanding events after the fact, not just preventing them upfront. They tend to be especially strong in areas like incident response, forensics, and insider threat detection. There’s a good number of ex-FBI and ex-police security leaders, and from what I’ve seen, they are very strong when it comes to bringing structure and rigor to investigations, asking the right questions, and making the organization truly understand and learn from security incidents.

Security leaders with a military background

Security professionals and leaders with a military background often think of security as a matter of defense strategy, planning, and execution. They focus on protecting critical assets, preparing for different attack scenarios, and making sure the organization can respond in a structured and coordinated way. There is a large number of ex-military CISOs, and if there’s one thing I’ve seen many of them have in common, it’s their ability to invest heavily in preparation before something goes wrong, and always having a solid plan in place. CISOs who are ex-service members are especially strong at building disciplined programs with clear roles, defined processes, and strong communication. I’ve seen several times that when incidents happen, they are the best to bring structure and make sure everyone knows what to do and how to move forward without chaos.

Security leaders with strong experience in compliance

Security professionals and leaders with a compliance background tend to think in terms of building comprehensive risk management programs, aligned with frameworks relevant to their organization. They like to make sure that at any time, the organization can show that it is doing the right things, has the right controls, and that all of the security efforts map to some objective requirements. I’ve noticed that CISOs who spent some time in GRC are especially strong at building documented, repeatable, and defensible programs.

Security leaders with experience in law

Even though there aren’t as many lawyers pivoting careers in security, I have met a few. Based on what I’ve seen, they tend to look at cybersecurity through the lens of risk, responsibility, and consequences. The people I’ve talked to seem to focus a lot on liability and making sure the organization is protected when things go wrong, and care a lot about liability exposure, contractual obligations, and minimizing legal and financial risk.

Each of them is right, and they are all wrong

There is most definitely an infinite number of ways we can categorize people’s backgrounds. Some start in a security operations center, others as auditors, and some, such as George Kurtz, founder & CEO of CrowdStrike, as Certified Public Accountants. The examples I mention here are just the ones that come to mind as I am thinking about people I’ve met, but they are in no way exhaustive. I have, for example, met a former HR who became a CISO (such a fascinating journey!).

The most important part is that, depending on people’s backgrounds, they see cybersecurity differently. Ask a former engineer, and they’ll talk about systems, architecture, and how things break; ask someone from compliance, and they’ll focus on controls, frameworks, and audit readiness; ask someone with a military or intelligence background, and they’ll think in terms of adversaries, detection, and response under pressure. Each person in security comes with a completely different mental model. So who’s right? They are all right, and they are all wrong at the same time. Like in that old story about the blind people and the elephant, each perspective is important, but none of them sees the whole picture.

There’s no single right way to secure a company, because there’s no single definition of what needs to be secured

The second dimension we need to keep in mind is that every company has different security needs. The way you would secure a B2B SaaS platform is very different from the way you would secure a bank with 1,500 branches all over the U.S., which, in turn, is very different from how you’d secure an international cruise line, or a firm that manufactures dental implants, or a hospital… When you pause for a moment and think about it, I am sure it will make sense, but way too often we as an industry conveniently forget about this reality. There’s no single right way to secure a company, because there’s no single definition of what needs to be secured. Every industry comes with different infrastructure, every company is at a different stage of maturity, and everything considered, you truly need to understand where they are to suggest that they need to do something. Which brings us exactly where we started - that Blind Men and the Elephant is the story of cybersecurity.

It’s a mistake to believe that any one view about security is enough, or that any one approach is the right way to secure every company. Real security comes from understanding the system, the business, the risks, and the tradeoffs as a whole, and figuring out what is appropriate for this specific environment at this specific stage, with these specific constraints, etc. It’s all these nuances that make specific controls very effective or utterly useless.

In the end, cybersecurity is about seeing enough of the elephant to make the right decisions, and making sure you focus on your own elephant, and not on the stories about elephants you’ve been hearing from others.

For founders, all this means that they really need to understand what problems they are solving and for whom, before approaching CISOs. More importantly, we as an industry should really keep in mind that panels and talks about “how everyone should do security” are pretty unhelpful. I am hoping that we will see more panels with diverse perspectives - diverse in terms of the kinds of businesses people are securing. When you have a panel of 4 SaaS CISOs, you won’t get as much of a different perspective as when the 4 people on the panel come from very different environments (one from SaaS, one from regulated industry, one from OT-heavy environments, and so on).

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share

Subscribe now

But that wasn’t all. Even though my most valuable part of the week was spent with customers and prospects, I did get to spend an hour and a half on the Expo floor. What I saw there was very different from what I’ve seen before. All that combined with my conversations with CISOs made me realize that this year’s RSAC was different from events I’ve been to in the past.

In this piece, I am sharing the main conclusions I walked away with from this year’s RSAC.

This issue is brought to you by... Tines.

Inspiration from Druva, PathAI, and more in this practical GRC guide

GRC today is more complex, and more critical, than ever. Between increased regulations across the board, data management and privacy concerns, siloed ownership, and time and resource constraints, it’s no wonder 46% of security leaders say spiraling regulatory complexity keeps them up at night.

In this practical guide for security teams, learn how your team can overcome the challenges of today’s fragmented, manual GRC processes. Get access to four opportunities for immediate impact, get inspiration from teams at Druva, PathAI, and more, and learn how you turn GRC from a checkbox into a strategic advantage.

Get the guide

Let’s skip over the usual stuff

Yes, the Expo floor is busy. Yes, there are many new companies. Yes, the industry is going through consolidation. Yes, not everyone can make it. Yes, we do have a lot of tools. Yes, some companies are not clear about what problems they are solving. Yes… You get the point. All these takes are not wrong, but it’s like going to Walmart and complaining that there is too much stuff on the shelves to choose from. Sure, but is that a bug or a feature? If you just need a loaf of bread, maybe it’s better to go to a neighborhood grocery store.

Yes, the RSAC floor is a lot, but similar to how you would approach Walmart (or any other big box retailer): you either go there with a shopping list so that you only buy what you need to buy, or you go there to see what’s available on the market. If you do the latter, better give your wallet and phone to your spouse so that you don’t end up walking away with stuff you never knew you needed.

I continue to be convinced that we need more founders brave enough to tackle problems that have previously been seen as unsolvable, that consolidation is an ongoing process, that just about every industry has become more crowded and more competitive, and so on. If you are a regular reader of Venture in Security, you know that I have several articles about each of these topics, and that I often try to remind folks that many things can be true at the same time, and that most people (be they CISOs, founders, investors, industry analysts, etc.) are just trying to do their best and succeed at their role.

With this out of the way, let’s talk about the takeaways.

Here are my unexpected takeaways after attending RSAC 2026

CISOs’ AI concerns today are grounded in reality

It hasn’t been long since the time when everyone was talking about how “Deepfakes are going to become every CISO’s #1 concern by 2025,” but guess what - it’s 2026, and it’s safe to say that this has not happened yet. This is just one example, and I am sure each of us can come up with a long list of these doomsday scares that didn’t materialize.

Every security leader I talked to at RSAC shared security concerns that are grounded, realistic, and pragmatic. It was not about “AI causing chaos” or “every employee using deepfakes” (not in my discussions anyway). I saw CISOs worried about the fact that they don’t fully know where their company’s data is going because of the number of AI tools employees are using to be more productive (you know, the usual shadow IT problem, now described as shadow AI). I saw CISOs realizing that attackers can now use AI to do reconnaissance at scale, and to find and exploit gaps in fundamental controls (identity, vulnerability management, etc.) that they simply had no manpower to manage at scale.

It wasn’t long ago that no one could cut through the noise, but now things feel back to normal. Going into the event, I expected fears of an AI “armageddon” to dominate the conversation, but that never materialized. It looks like AI is becoming a part of everything, and we’re slowly moving on from treating it as something new.

There’s a lot of excitement about using AI to solve old problems

A couple of RSACs ago, every mention of AI came with a sense of dread. The narrative was overwhelmingly negative - attackers would use AI to get better at breaking in, employees would misuse it, and things would go very wrong everywhere all at once.

This year felt very different because the tone shifted from fear to possibility. There was real excitement around how AI could finally help solve problems that have been stuck for decades. Take my experience at the CrowdStrike, AWS, and NVIDIA accelerator, where I presented as one of the finalists. The company that took the top spot - Jazz Security - is using AI to tackle DLP. Not exactly the most sexy space, and one the industry has struggled to get right for years, but now, for the first time, it feels like we might actually have a shot at solving it.

When I spoke with CISOs, the excitement around AI was everywhere - AI for pentesting, AI for identity, AI for exposure management, AI for the SOC, AI for vulnerability management, etc. Across the board, the theme around AI was not about replacing engineers, but about using it to finally solve problems that have been unsolvable for years. That’s exactly where I personally believe the real opportunity lies, so seeing the industry align around that mindset was really encouraging.

Security startups are doing a better job with messaging

About 20 minutes into my journey on the Expo floor, I started to feel like something was off. I couldn’t figure out what was going on until it hit me: I was able to understand what most of the companies were actually doing!

For the first time, I found myself reading taglines and thinking, “Ah, I actually get what they’re trying to say.” It made me realize that most security companies were never trying to be confusing on purpose, they just struggled to clearly communicate their story. LLMs are making it much easier for technical founders to explain why their features matter and what problems they solve, while also helping non-technical marketers better understand and articulate what the product is actually built to do.

Interestingly enough, I think startups are doing a better job at messaging than large companies. I don’t know why that is, but if I had to guess, I’d say that it’s probably because of two reasons. First, the bigger the company, the more people are involved in approving every message, and the more people you add, the more the outcome starts to feel like a watered-down version that makes everyone kind of happy. What begins as something clear and specific, like “we back up your data so you can recover from ransomware”, somehow turns into “resiliency at the speed of light,” and you’re left wondering what that actually means. Second, larger companies have broader product portfolios, and that makes people want to come up with a single tagline that describes everything they do. In reality, that’s incredibly hard, so more people get pulled in, more opinions are added, and you end up right back at the same diluted, overly abstract messaging.

The real competition is not other vendors, it’s doing nothing

Most security teams I spoke with aren’t actively doing POCs with 10 vendors that solve the same problem. Instead, tost of the time they’re deciding whether to even prioritize the problem this quarter (or this year, or ever, really). Basically, the biggest blocker for cybersecurity startups isn’t budget, it’s buyer attention.

This isn’t in any way a new phenomenon, but nowhere is it as clear as when you are looking at cybersecurity buyers trying to find the few things they actually care about on the Expo floor. There are many loud voices on LinkedIn saying that because of AI, security teams are now building products themselves instead of buying them, but when you listen to CISOs, it becomes clear that for many problems, they simply do nothing (and for some really good reasons).

My biggest takeaway: security leaders are going back to fundamentals

There are many takeaways from this year’s RSAC I would like to discuss, and there are many things I am reading from others that I don’t quite agree with. My biggest takeaway from RSAC 2026 is that security leaders are going back to fundamentals.

What I saw at this year’s RSAC is that more and more CISOs are refocusing on the basics. The last few years proved that what gets companies breached aren’t some novel zero days or AI-driven threats, but weak fundamentals. After decades of tool sprawl, overlapping categories, and being pulled in random directions by every new trend, there’s a growing realization that the real gaps were never about needing more cool tech. I heard it over and over again that teams are doubling down on asset visibility, tightening identity controls, cleaning up access policies, enforcing least privilege, and getting serious about operational rigor. Things like patching, vulnerability management, access reviews, and other boring areas are what actually gets people to spend time and money because that’s what real problems actually are. There’s also a shift in mindset - instead of asking “what new tool should we buy?”, the question is increasingly “are we actually using what we already have the right way?” Instead of adding more layers, teams are trying to simplify, consolidate, and make their environments understandable again.

AI is part of this story, but not in the way people expected a year ago. Instead of replacing fundamentals or replacing security engineers (good luck with that!), AI is becoming a way to finally execute on the fundamentals at scale. This focus on fundamentals is what I discussed on Illumio’s podcast right before RSAC, and it is what I expect to see more of as we go further.

My biggest prediction is this: once the hype settles, the industry will keep moving back toward fundamentals, and we’ll see that trend accelerate over the next few years. It’s the right direction, because most breaches don’t come from sophisticated zero-days or intricate attack chains. They come from much simpler failures like default credentials that were never changed, assets that no one even knew were still out there, temporary exceptions that became permanent without anyone noticing, and similar “boring” problems. The rest is just marketing.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

*I am using Gartner in this article as a way to generalize about “industry analyst firms”; you can substitute Gartner with Forrester or any other of your favorite companies.

This issue is brought to you by... Endor Labs

Discover security that scales with AI-driven development.

AI is accelerating how engineers ship code, but security reviews aren’t scaling with it. AURI by Endor Labs changes that: autonomously surfacing business logic risks and the “unknown unknowns” that manual review and traditional AppSec testing miss. Discover security that scales with AI-driven development.

Learn More

It’s not the industry analysts’ job to come up with winning startup ideas

There’s one mistake I see over and over in our industry: people assume that an industry analyst’s job is to predict the future. This is not at all the case. Let me explain.

Firms like Gartner make the majority of the money from serving enterprises, and despite what some people in our industry assume, their role extends far beyond recommending security solutions. In fact, Gartner isn’t usually an expense that comes out of the CISO budget, and CISOs are just one of the many kinds of executives that rely on their offerings. While Gartner does sell vendor subscriptions, it is generally a smaller area of their focus. The majority of their time is spent working with the enterprises, helping them navigate complex challenges surrounding different kinds of large-scale transformations, advising them on making hard decisions, and so on.

Given the types of customers Gartner serves, its coverage tends to be very well-researched, and some might even say somewhat conservative. Gartner analysts aren’t jumping on random trends or new ideas - they are looking for patterns, and the evidence that some of the customers out there have bought into the new idea. In other words, Gartner’s job isn’t to predict trends or predict what categories of products are needed on the market. Instead, their job is to declare trends that are already unfolding, and declare which problems they are hearing from customers will need new solutions.

Let me be very clear: all the analysis out there can be very helpful to understand where the market is moving. However, it’s important to keep in mind that these reports don’t predict the future; they declare things that are already happening or that someone would like to happen. It is not the job of the analyst firms to identify opportunities for startups to pursue: as we’ve established, they work for the enterprises or existing vendors, and not for future founders.

Even more critically, I think founders need to know how to properly read analyst reports so that they don’t become harmful to them. This isn’t because the reports are wrong, it’s because they’re too high-level. Firms like Gartner serve enterprises in just about every industry vertical, in most countries, and with different tech stacks. When a founder reads that “Fortune 500 companies need a different approach to data loss prevention”, they have to keep in mind that “Fortune 500 companies” won’t become their customers. Their targets are going to be much more specific - “Financial institutions between 15,000 and 25,000 employees who use AWS as their primary cloud and who do not have a third-party DLP solution” (or something like that - something very, very specific, and not “Fortune 500 companies”).

Trends don’t “just happen”; someone makes them happen

Here’s the main point about trends: trends don’t “just happen”; someone makes them happen. One wise person once told me that there are three types of people: those who make things happen, those who let things happen, and those who wonder what just happened.

I am sure someone can point to exceptions (there are always exceptions), but in the majority of cases, things happen because someone works really hard to make them happen. Was there a trend where companies were migrating to the cloud? Of course, but people didn’t just wake up one day and say, “We need to move to the cloud”. Cloud service providers invested a lot in marketing their approach. Investors at venture firms started betting on founders embracing the new approach. Service providers educated their customers about the benefits of the cloud compared to data centers. Someone inside the company became interested in the opportunity and decided to explore how these potential benefits would manifest themselves inside the organization… Eventually, too, the pandemic did more to convince companies to embrace the cloud than all consulting firms combined. Things happened because many, many people in different capacities and roles worked hard to make them happen.

When you see an analyst firm or some market insider say that they see a “trend”, it means someone (likely a few founders) is working hard to make this trend a reality.

It’s not the CISO’s job to know what they need

Another common misconception I often hear is that winning ideas come from asking CISOs what they need. I know it may be counter-intuitive to suggest that this is a bad approach (after all, don’t we have to be customer-focused?), so hear me out.

I strongly believe the cybersecurity industry is blessed with a great number of innovators and people truly passionate about the future of our industry. We are used to taking it for granted that security leaders and security professionals are usually happy to share their perspective on problems or help founders refine their ideas. If you have never worked in another industry, you’ll probably not be able to fully grasp how rare and amazing this is.

At the same time, talking to CISOs about their problems does have its limitations. ”We don’t know who discovered water, but we’re certain it wasn’t a fish”. These words by Marshall McLuhan have critical lessons for cybersecurity founders who think they can just ask CISOs what they need and go build that. Security leaders have a lot of problems, experiences, and perspectives, but it’s not their role to articulate them in a way that makes it obvious what needs to be built. Founders can’t just take orders from CISOs - they need to take in all that knowledge, experience, and perspectives, and envision a better future.

The key in these conversations is to dig deep to understand the problems, not to look to CISOs to shape the idea of a solution. Another important bit is to ask about the specific problems they are dealing with themselves, not for what they hear from others, or ideas for what they would like to exist. As Steve Jobs once said, “It is not the customer’s job to know what they want”. In the end, founders have to understand the problem space in depth, but it is their responsibility to synthesize the data, make sense of all the learnings, and to decide what to build. This brings me to the most important message of this article.

It’s the founders’ job to understand the problem, envision a better future, and make it a reality

I have previously talked about customer and problem discovery, so I won’t dive into that here. In general, I don’t think there have been many billion-dollar companies in cyber where founders would just look at trends or ask CISOs about their problems and voila - they got a winning wedge. It is simply not how it works. Okta struggled for a number of years and nearly went under before the product took off. CrowdStrike had to educate the markets about nation-state attacks at a time when most assumed that they were protected because they had McAfee. Jay Chaudhry, founder of Zscaler, explained on Inside the Network that when he pitched for the Zscaler idea, 9 out of 10 prospects would say they are not interested. Despite all that, he pushed through by inverting the reality and saying, “Well, this means that 1 out of 10 is to say yes”. As a side note, the reason I find Jay’s story so fascinating is that in 2026, most founders would have killed any idea 9 out of 10 CISOs said “No” to. Sticking with it requires the power of vision and conviction.

It’s not enough for the founders to understand what the problems are. They have to process all the competing insights, immerse themselves in the problem space, but then they have to put forward a perspective. They have to take a stance and envision a better future. This vision cannot simply be the result of a collection of feature requests. This vision cannot be simply an outcome of Gartner research. It has to be their insight, their perspective, and their bet. Every startup is a bet on a vision of the future that does not yet exist. It is the funder’s job to make this vision a reality.

At the core of every company is a bet - a bet that a better feature isn’t just possible, that it absolutely needs to happen. Sometimes, people hit it big, stars align, and tailwinds are so strong that it feels like things just happen. Most of the time, however, things happen because someone makes them happen. Or, in other words, it’s the founders’ job to understand the problem, envision a better future, and make it a reality. As Jobs said, “It is not the customer’s job to know what they want”.

Image Source: Navigating the Security Technology Landscape

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share

Subscribe now

This issue is brought to you by… Axonius.

51% of Security Teams Are Losing Critical Context

Most cybersecurity programs are rich in visibility — and struggling to act on it. So what separates the teams that actually move the needle?

Axonius partnered with the Ponemon Institute to find out. The 2026 Actionability Report reveals how top security teams turn data into decisive action. Only 45% consolidate exposure into a single source of truth. 51% lose critical context during remediation. 37% are still stuck in manual workflows.

The best teams have solved these problems, and this report shows exactly how.

Get the Research

Cybersecurity is breaking all records

If you have been following the news over the past several years, you know that cybersecurity has been exploding in growth. Let this sink in:

• Google’s largest-ever acquisition is a security company (Wiz).

• ServiceNow’s largest-ever acquisition is a security company (Armis).

• Mastercard’s second-largest ever acquisition is also a security company (Recorded Future).

• Cisco’s largest-ever acquisition is a security company (sure, not pure-play but cyber is a huge part of their business - Splunk).

If these aren’t the signs that something is changing, then nothing is. However, just looking at these figures won’t do them any justice without the surrounding context why we’re seeing what we are seeing. Let’s have a quick look at several different cases to understand how every platform company is becoming a security company.

Every platform company is becoming a security company: eight brief case studies

Case one: Google

Google’s largest acquisition ever is a security company, Wiz, purchased for $32 billion. That alone is remarkable, but it becomes even more impressive when you look at Google’s broader M&A history. Out of more than 260 acquisitions, only 65 had disclosed prices, and across those deals, Google spent nearly as much on just three cybersecurity companies (Siemplify, Mandiant, and Wiz, $37.9B combined) as it did on the other 62 disclosed acquisitions combined ($41B). This number is mindblowing.

Here’s a great chart that puts Google’s acquisition themes into perspective:

​

Source: FourWeekMBA​

What’s driving this shift is simple: Google is no longer just an advertising company, it is an enterprise cloud company competing with AWS and Microsoft. In the enterprise world, security is foundational, so if Google wants large organizations to run critical workloads on Google Cloud, it has to be able to offer first-class security capabilities natively. Acquiring companies like Mandiant and Wiz allows Google to instantly strengthen its credibility with CISOs and security teams, something that takes decades to build organically (and frankly, something that Google hasn’t been able to do on its own).

There is also a strategic platform play behind these acquisitions. Cloud platforms increasingly compete not just on compute and storage, but on the ecosystem of capabilities that sit on top - identity, observability, compliance, and security. By integrating security deeply into its cloud platform, Google can make its infrastructure stickier, (hopefully) attract security-conscious enterprises, and compete more directly with Microsoft, which has successfully turned security into a massive multi-billion-dollar business attached to its cloud. Moreover, having Wiz in their portfolio strategy gives Google deep visibility into customer deployments across other clouds. In that sense, cybersecurity isn’t just a product category for Google, it’s becoming a core pillar of its enterprise strategy.

Google’s competitors in the cloud space, Microsoft and AWS, have had a different approach to cybersecurity M&As. AWS acquired Sqrrl and harvest.ai in 2017, but didn’t do anything afterwards. Microsoft, on the other hand, has had a cyber acquisition spree between 2020 and 2022 but hasn’t done any new M&As since then (it bought CyberX in 2020, RiskIQ, CloudKnox, and ReFirm Labs in 2021, and Miburo in 2022). This does make sense if you consider that the way these two hyperscalers go to market is different as are the advantages that make them leaders in the cloud world.

Case two: ServiceNow

ServiceNow’s largest acquisition ever is also a security company, Armis, acquired for $7.75 billion in cash.

ServiceNow built its empire by becoming the system of record for enterprise workflows, from IT and HR to customer support, and increasingly operations across the entire organization. Once you own the workflows that run the enterprise, security naturally becomes part of the conversation. Every incident, vulnerability, asset, configuration change, and compliance process ultimately turns into a workflow.

ServiceNow is betting on what I call the “workflow gravity” effect - the fact that ServiceNow has become an enterprise “system of action” with unified data and AI experiences built into workflows. This is an incredibly powerful position because once a company owns where work flows, it gets the ability to influence and eventually own how decisions are made. ServiceNow’s bet is so interesting that I wrote an entire dedicated deep dive about it: ServiceNow is betting on “workflow gravity” to win against the platforms of Palo Alto, CrowdStrike, Cisco, Zscaler, and Microsoft.

If you look at this chart by CB Insights, it becomes clear that ServiceNow has its hands in virtually every enterprise workflow:

Source: Jason Saltzman on LinkedIn

And yet, it is clear that a company best known for owning enterprise workflows is increasingly becoming a cybersecurity company. This ambition is why ServiceNow paid so much for Armis, and also why it acquired Veza in a $1 billion deal around the same time.

Atlassian, which competes with ServiceNow with its Jira offerings, hasn’t been a significant player in the cybersecurity space. The company has largely missed the opportunity to dominate developer security (which it definitely had the chance to do) or to capitalize on its dominance in the developer and IT workflows space (unlike ServiceNow). It has made some deals, like its acquisition of Borneo in 2025, but it never truly played big in the cybersecurity market.

Case three: Mastercard

Mastercard’s second-largest acquisition in history also happens to be a cybersecurity company, Recorded Future, for which in 2024 the company paid $2.65B. This move, which surprised a lot of people, showed how financial networks think about security. Mastercard isn’t just a payment processor, it operates one of the largest global transaction networks. For them, protecting that ecosystem from fraud, cybercrime, and nation-state threats is critical to the business. By bringing Recorded Future’s intelligence capabilities in-house, Mastercard can better detect threats targeting banks, merchants, and payment infrastructure across its network. At the same time, it could even allow Mastercard to expand its security offerings to financial institutions and enterprises, basically turning cybersecurity into both a defensive capability and a new growth business built on top of the company’s global data and network visibility.

For Mastercard, Recorded Future most definitely wasn’t its first step into cybersecurity. Before investing nearly $3 billion in security, the company has made a long list of smaller acquisitions, including Ethoca (2019), RiskRecon (2019), and Baffin Bay Networks (2023).

Mastercard also isn’t the only payments network that has acquired or partnered with cybersecurity and fraud prevention companies. Visa, for example, bought Featurespace (2024) and CyberSource (2020, acquired in a transaction worth $2 billion), and in 2020 it invested in Very Good Security.

Case four: Cisco

Cisco’s largest ever acquisition is also a security company, Splunk, for which it paid $28 billion. Sure, some may argue that Splunk isn’t a pure-play security company, but given how much of their business comes from security, I’d say it is a security company.

When I looked at how, in some 20 years, over 200 companies in cyber consolidated into just 11, I pointed out that if you asked most people in security who the biggest acquirer of cybersecurity companies is, the answer would almost certainly be Palo Alto Networks. That makes sense since the company has been pushing the consolidation narrative (or, as they call it, “platformization”) harder than anyone else, and we’ve seen that they have brought together over 30 players. However, while Palo Alto may be the most visible acquirer, it’s not the biggest. That title belongs to Cisco, which has absorbed more than 40 (!) security companies over the past two decades.

Source: 20 years of cybersecurity consolidation: how 200 companies became 11

Cisco’s strategy here is deeply tied to its evolution as a company. For decades, Cisco dominated networking infrastructure, but as the industry shifted toward cloud, software, and observability, simply selling routers and switches was no longer enough. Security became the natural extension of Cisco’s position in the network: if you sit in the data path, you are uniquely positioned to detect threats, analyze behavior, and enforce policy. By acquiring Splunk, Cisco effectively adds one of the most powerful data and analytics platforms in security to its portfolio, allowing it to combine network telemetry, security signals, and observability into a single platform.

More broadly, Cisco’s history of acquiring over 40 cybersecurity companies reflects a long-standing belief that networking and security are inseparable. From firewalls and cloud security to identity and zero trust, Cisco has spent two decades building a massive security portfolio around its network footprint. To them, security is not just an opportunity to upsell customers who are already relying on Cisco for their networking needs, but also a way to reinvent the business and position it for the future.

Subscribe now

Cases five, six, seven, and eight

There are many, many more cases we can look at when a company that isn’t known as a cybersecurity player acquires a security startup. Here are four more just to give you some examples:

• Mitsubishi Electric acquired Nozomi Networks for $1 billion to strengthen its capabilities in securing industrial and OT environments. By acquiring Nozomi, Mitsubishi can embed security directly into the increasingly interconnected industrial systems it sells to factories, energy systems, and critical infrastructure.

• HP acquired Bromium to use security as a selling point for its devices. Bromium pioneered isolation that protected users from malware by containing threats inside micro-virtual machines. By integrating this technology into HP laptops and workstations, HP could make security a native feature of the device instead of relying on third-party security products.

• Hewlett Packard Enterprise (HPE) acquired Axis Security. The acquisition helped HPE move deeper into the convergence of networking and security (Axis’s zero-trust network access tech fit naturally into HPE’s broader strategy around Aruba).

• Apple acquired mobile security firm AuthenTec for $356 million. AuthenTec’s expertise in fingerprint sensors allowed Apple to develop and integrate Touch ID, starting with the iPhone 5S, offering a secure, intuitive authentication method.

Different motivations, the same outcome

Every single one of the companies I mentioned here has different reasons to get into cybersecurity. For Google, for example, cybersecurity is a way to assemble a differentiated cloud offering so that it can more confidently compete with AWS and Azure. For ServiceNow, cybersecurity is a way to capitalize on the “workflow gravity” effect and its position as the owner of enterprise workflows. For Mastercard, cybersecurity is a way to protect its business-critical operations, prevent disruptions, and reduce the amount of money it needs to pay to bad actors. For Cisco, cybersecurity is both a way to further capitalize on its deep embeddedness into the enterprise infrastructure and a way to reinvent the business and position it for the future. This list can go on and on.

Regardless of the motivations, the outcome is the same: every significant B2B company is becoming a security company. Security is no longer a standalone category reserved for specialized vendors, it has become a foundational capability expected from every enterprise platform. If you operate critical infrastructure, host enterprise data, run workflows, or power digital payments, customers expect you to secure it by default. This shift is slowly changing the cybersecurity industry. Instead of security being purchased exclusively from dedicated security vendors, it is increasingly embedded into the platforms enterprises already rely on. The result is a world where cybersecurity is both its own massive market and a horizontal capability that every major B2B company must build, buy, or partner to deliver.

What cybersecurity startup founders should keep in mind

For founders of cybersecurity startups, this changes the strategic landscape. On one hand, the bar is higher than ever: if a platform vendor can ship a “good enough” native security capability, a standalone product has to be substantially better to justify its existence. Many of the point solutions have been struggling with this. At the same time, there’s a massive opportunity to build the innovation layer that large B2B platforms will eventually integrate, partner with, or acquire.

In other words, the future of cybersecurity startups is increasingly connected to the ecosystems of large B2B platforms, not just security products. Founders may still look at the usual suspects like Palo Alto Networks, CrowdStrike, Zscaler, Fortinet, and Check Point as natural acquirers, but as I’ve discussed here, the list of potential buyers is expanding far beyond the traditional cybersecurity industry. The past several years alone have shown how aggressively companies like ServiceNow, Google, and Mastercard are investing in security, and I am pretty sure we will see more of that in the decade to come. For founders, that means thinking differently about where their company fits in the broader technology ecosystem. The most successful cybersecurity startups won’t just build tools for security teams; they will build products that become strategically important to the platforms where core business actually happens.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

It just so happens that many of the people arguing that AI will push companies to build security tools in-house instead of buying from vendors are friends of mine. They’re smart, thoughtful people; I simply happen to respectfully disagree with their perspective. In this piece, I will explain why I disagree and why we’re nowhere near the time when companies will just start building their own security tools. At the same time, I do think that security teams should definitely be building one particular kind of tool internally (but these aren’t really a replacement for cyber vendors).

This issue is brought to you by… Varonis.

AI adoption doesn’t have to equal risk expansion.

AI doesn’t operate in isolation. It connects to the same data, permissions, and identities your security strategy already struggles to govern. That’s why AI security isn’t about the model; it’s about the data that fuels it. Discovery alone isn’t enough when copilots and agents can retrieve sensitive data in seconds.

Varonis helps organizations apply real controls to AI risk by understanding what information AI systems access, enforcing guardrails across data and identities, and preventing exposure before damage is done. Don’t settle for point solutions that address isolated risks. Start securing everything you build and run with AI today.

See Varonis in Action

A few simple reasons why most companies will not build their own security tools (and they shouldn’t)

Expertise required to build products

The number one reason why most companies are not going to build their own security tools is a lack of engineering expertise. I know this sounds counterintuitive in a world where so many suggest that software can write itself, but hear me out. I have been a product leader for many years before I became a founder, and I’ve seen many, many times that there is a huge difference between writing code and building functional products. Software that can withstand real-world enterprise environments isn’t some random CRUD (create - read - update - delete) apps. Security tools in particular require deep domain knowledge, architectural rigor, performance optimization, edge-case handling, and the ability to operate across messy, heterogeneous environments. You don’t get that for free with Claude Code.

AI makes writing code super quick, but it makes skills like systems thinking and architecture more critical than ever. What AI doesn’t do is magically give companies years of accumulated understanding about enterprise networks, identity models, logging pipelines, compliance nuances, or operational workflows. That expertise still has to come from somewhere, and most companies don’t have senior engineers sitting around waiting to reinvent what security vendors have already spent a decade refining.

What I think AI is going to do is deepen the divide between engineering-centric security teams and everyone else. If you’re a Bay Area-style, product-driven company that already has strong security engineers building internal tooling, AI is going to amplify that big time. It will let your team prototype faster, build internal tools faster, automate many more workflows, and so on. If you work at companies like OpenAI, Anthropic, Google, Airbnb, Canva, Figma, Notion, Uber, Reddit, or Discord, where engineering is the DNA of the organization, you should 100% be building much more now with AI than ever before. I think that when it comes to these companies, my friend Frank Wang is right that they are going to build a lot in-house.

For the rest of the world, if building security products in-house wasn’t realistic yesterday, AI won’t magically make it possible tomorrow. Companies that didn’t have the engineering talent aren’t going to suddenly build their own tools because the three SOC analysts they can afford to hire now have Claude. Companies that were under a lot of regulatory pressure yesterday surely aren’t going to see that pressure go down today. I can keep going with these examples, but that’s not the point. Will AI expand the percentage of companies that can build security products? Definitely. If I were to guess, I’d think that instead of 1-2% of companies that number will grow to 4-7% but it’s not going to be 70% or even 30% (I’m pulling those figures out of thin air (nobody has hard data) but I’m willing to bet the real number sits in the single digits).

​All this makes me think that while some security tools can definitely be built internally, security teams are less likely to build those that are technologically complex, that need to operate at a large scale, process a lot of data, require agents, etc.

Expertise required to secure the company

If finding engineering talent is already incredibly hard, now consider how hard it is to find senior security talent. There’s a lot of talk about how there’s the so-called “cybersecurity talent shortage”, but both the people who claim that security is oversaturated and people who say that we need 4 million (or whatever the number is now) security engineers are all wrong. I explained what’s actually going on years ago. It’s pretty simple: there are too many people in cyber looking for entry-level jobs, and very few senior professionals.

The people who deeply understand detection engineering, incident response, cloud security and engineering, identity (I mean deeply - like being able to find an attack path by hand), network exploitation, compliance requirements, and adversary behavior are extremely rare. Most security tools, whether they are focused on prevention, detection, response, remediation, or recovery, essentially “encode” the expertise of a small number of highly specialized researchers and engineers, and then distribute that knowledge to hundreds or thousands of customers. In a sense, security vendors industrialize very limited expertise, turning scarce security talent into software.

Obviously, this model is not perfect. The logic security vendors build can be generic, it can miss the nuances of individual environments, and so on, but what it does really well is deliver the kind of expertise to the end customers that most would never be able to afford and/or attract on their own.

Now imagine for a second what would happen if every company started trying to build security tools internally. Instead of several thousand vendors competing for the top 1% of security engineers, we would have tens (or hundreds?) of thousands of enterprises all trying to recruit, retain, and manage their own in-house detection engineers, cloud security architects, threat hunters, and security platform builders. The math simply doesn’t work because there is not enough security expertise. Contrary to popular belief, AI is not going to change that.

All this makes me think that while some security tools can definitely be built internally, security teams are less likely to build those that require specialized security expertise.

The cost of building is going down, but the cost of ownership is not so much

Another important reason why companies won’t start building their own tools is the cost of ownership.

AI is truly reducing the upfront development cost, but in no way is it changing the equation around the total cost of ownership. I totally get why people are so excited about building with AI, but building software isn’t just about launching new cool features fast. It’s also about maintenance. Who is going to update integrations when APIs change? Who is going to refactor the system when there’s too much tech debt? Who is going to debug it at all times? AI is going to increasingly take care of more and more of these tasks, but humans will still be required to make things work at enterprise scale. Every software vendor has to deal with on-call rotations, documentation, knowledge transfer, feature requests, bug fixes, scaling infrastructure, compliance, audits, and retraining models, and the long tail of maintenance is usually much more expensive than the initial cost of building.

Buying software is about buying a lot of intangibles that come with it, like reliability, security, being able to pass complex audits across jurisdictions, operational resilience at scale, partners they can trust when something breaks at the worst possible moment, etc. All these things have to be considered when companies get too excited about building things internally, and most teams will decide against it as soon as they see how big the gap between the cost of building and the cost of maintenance actually is.

All this makes me think that while some security tools can definitely be built internally, security teams are less likely to take a stab at building tools where the total cost of ownership is very high (this applies to a lot of security products because most products need constant updating to stay effective).

Liability is playing a critical role in build vs. buy decisions

When companies build software internally, they own the consequences of things not going well. If something breaks, or when an incident happens (be it an outage or a security breach), there’s no vendor contract to lean on, and no shared responsibility model. It’s entirely on them to deal with whatever happens.

For a lot of the areas of enterprise, the risks are acceptable. Say, if a marketing team wants a dashboard to track how their campaigns are doing, it can make sense to build a tool that pulls from internal CRM data and shows it in a nice UI. Or, say a human resources team is spending too much time dealing with PTO requests - that, too, can be automated internally.

Security is a different beast because it is directly connected to compliance, regulatory requirements, customer trust, and brand reputation. Few CISOs are going to sleep well if their already under-resourced teams start vibecoding their own security tooling, both because that can increase the probability of a breach, and because it can make compliance a nightmare. Auditors may not accept “we built it ourselves” as proof of control and start asking for documentation, testing, change management, and independent validation. When that happens, an internal tool quickly becomes a liability instead of an advantage.

Another factor people are forgetting in these discussions about vibecoding is insurance. Cyber insurance underwriters don’t just ask whether a company “has security”; they ask what tools the company is using, whether they’re industry-recognized, whether they’re maintained, audited, supported, and so on. Even if they don’t ask these questions upfront, if a large enterprise gets breached, and it turns out that critical security controls were replaced with internally built tools instead of dedicated vendors, that can create serious complications, and in some cases, it could even invalidate coverage. Bottom line, liability concerns are an important factor to consider. For a tech company that just needs SOC 2 to sell to enterprises, it may not matter as much, but publicly traded companies or especially those in regulated industries surely have more to lose.

All this makes me think that while some security tools can definitely be built internally, security teams are less likely to build those that can expose them to liability and have the potential to create issues with regulators, auditors, or insurance companies.

Tools built internally usually lack industry-level intelligence

As I have said, products built by security vendors can offer somewhat of a generic coverage, but sometimes that is a feature, not a bug. Vendors get to see patterns (attack techniques, misconfiguration trends, exploit chains, false positive patterns, real-world breach data, etc.) across many different environments. That kind of visibility creates a network effect, and the more customers they get, the better their detection logic, threat models, and defensive playbooks become.

An internal tool only sees one environment, so even though at some companies it can be super tailored to what they think they need, it is always going to lack breadth compared to something built by a vendor servicing many customers. Internal tools don’t get the benefit of having shared intelligence or even lessons learned from incidents that happen at other companies. For security products this is a huge gagp because exposure to many examples of “badness” is a requirement for truly comprehensive coverage. The detection know-how of CrowdStrike or Palo Alto can only really be replicated if a company can see that many environments at the same time, and I don’t think anyone can truly replicate that inside a single enterprise, no matter how big or mature that enterprise is.

All this makes me think that while some security tools can definitely be built internally, security teams are less likely to build those that benefit from industry-wide network effects and that would be of limited value without them.

Two bonus reasons why CISOs should not be rushing to build their own security tools

It will really complicate hiring and new employee onboarding

Security teams are always resource-constrained and can’t afford to have new analysts or engineers spend months just learning internal systems before contributing. When new people join the company, they need to ramp quickly and start delivering value on day one.

When companies use standard tools, onboarding is much faster because new hires will often already know the tools they’ll be using or can rely on existing documentation and vendor support. Custom-built tools, on the other hand, tend to have much worse documentation, rely on tribal knowledge, making hiring harder and onboarding longer since no one comes in with existing experience in your internal custom stack.

You have to build your own integrations

No security team can just use a single tool to do everything it needs in one place. Inevitably tools sprawl, and all these SIEMs, EDRs, CSPMs, DSPMs, clouds, IdPs, vuln scanners, ticketing platforms, etc. have to talk to one another. Maintaining integrations is a lot of work, and while we have to admit many cyber vendors don’t always do a great job here, when you build your own tools, integration becomes 100% your problem.

If you build custom tools, you own every connector. AI can help write them, but APIs change, auth breaks, vendors update endpoints, and you end up having to maintain plumbing instead of improving your company’s security. I personally don’t think this is a good use of security teams’ time but I am sure there are plenty of people who will disagree.

Security teams will be building a lot of their own glue and productivity tools (and they should)

To summarize, I don’t think security teams are going to be able to build their own security tools at scale, in particular:

• Tools that are technologically complex, need to operate at a massive scale, process a lot of data, require agents, etc.

• Tools where the total cost of ownership is very high (this applies to a lot of security products because most products need constant updating to stay effective).

• Tools that require specialized security expertise.

• Tools that can expose the company to liability and/or can create issues with regulators, auditors, or insurance companies.

• Tools that benefit from industry-wide network effects and that would offer limited value without it.

This leaves one area where I do think we’ll see a lot of tools being built internally. I am talking about tools that make security teams more efficient doing what they are actually spending the most time on every day.

I have previously written that most of the security teams’ work has nothing to do with chasing advanced adversaries. In that piece from several years ago, I explained that “While many people join cybersecurity after being inspired by the idea of hacking, the vast majority of security work is far removed from actively trying to catch adversaries. Working on a cybersecurity team at an enterprise is similar to working on any other team, in that a disproportionately large amount of time is spent on:

• Communication, which includes meetings, sending and responding to emails and messages in Slack or Teams, answering questions, preparing reports and status updates, tracking key performance indicators (KPIs), and coordinating with other departments.

• Cross-functional collaboration, which includes reading and writing documentation, understanding how different departments do their work, coordinating complex initiatives spanning multiple teams, explaining the importance of various controls to employees and functional leaders, and negotiating the minimum realistic security measures.

• Security evangelism, which includes explaining why passwords cannot be saved in the spreadsheet or sent via text (even via encrypted messaging platforms), why service accounts cannot have domain admin rights, why people should use Yubikeys instead of the SMS-based MFA, and the like. Most importantly, all this needs to be done without becoming a bottleneck for people trying to do their work and achieve company revenue goals, and without ruining relationships with everyone at the organization.

• Buying and maintaining security tooling, which includes conducting gap analysis, testing new security solutions, periodically assessing the implementation of existing security tools, addressing issues surrounding configuration, and deciding which policies are appropriate to be implemented in what parts of the environment.

• Resource planning, which includes negotiating budgets and headcount, justifying investment in specific areas of security, structuring, organizing, and re-organizing teams, and working with human resources and recruiters to develop hiring and employee compensation plans.

• Training and onboarding, which includes reading and writing documentation, and guiding new employees to get up to speed with how things are done at the organization.

Many would argue that these things are boring, but such is the nature of office jobs, and work in general - a lot of what we do are mundane tasks that just need to get done and not the most exciting initiatives that use all of our skills and abilities. Every office job has a part that lives in Excel spreadsheets and PowerPoint presentations.” - Source: Most of the security teams’ work has nothing to do with chasing advanced adversaries

This is the stuff that security teams should be automating, all this undifferentiated heavy lifting as Amazon would call it. I firmly believe that unless you’re one of the top 1% of the engineering-driven security teams, things like prevention, detection, response, and recovery are better left to security vendors. Where building stuff with AI comes in for building the glue, the tools that automate everything between. It’s about automating workflows, automating work, and increasing productivity.

In the past, security teams were limited to the capabilities of their Security Orchestration, Automation, and Response (SOAR) platforms, but now they can surpass what these platforms were able to offer. The opportunity today isn’t to get rid of the core security vendors and replace them with vibecoded solutions; it is to build custom productivity tools to make security teams more effective.

Increasing personal productivity and eliminating glue work is where security teams should focus their AI-driven automation efforts. Doing this well requires deep knowledge of internal processes, procedures, and all the shortcuts and edge cases that exist in a real environment - context no external vendor can fully replicate.

At the same time, security teams shouldn’t try to rebuild mature products that require a lot of engineering expertise, security know-how, or that benefit from network effects just to “save money”. Maintaining any meaningful in-house tool almost always costs more than paying for a subscription once you factor in engineering time, upkeep, and ongoing improvements. Let’s be honest - we’ve seen how this plays out before with scripts. What starts as a quick productivity win slowly turns into another brittle system to maintain. The real opportunity for savings and impact lies in automating what’s truly unique to the organization: its unique systems, workflows, and institutional knowledge.

Update: After publishing this article, my friend Guillaume Ross sent me a note that summarizes things better than I ever could: “Shell scripts are now very easy to build, but building a data lake is not. Sure, Bay Area-style security teams can now build anything, but others are probably better off using Claude Code to generate SOAR playbooks, parse logs, or create detections as code. They should stay away from trying to build anything serious that collects a lot of data and requires infrastructure.”

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

This issue is brought to you by… Tines.

Where does AI fit in modern automation?

Human-led. Rules-based. LLM-powered agentic systems. Each promises efficiency. Each has limits. The real advantage? Knowing when, and how, to use them together.

The teams pulling ahead aren’t betting on a single model. They’re architecting a custom mix of all three.

On March 12th, join Tines and The Hacker News for a webinar exploring how to strike the right balance between approaches for your org, and scale AI adoption without sacrificing control or security.

Register Here

What Claude Code Security is and is not

Let’s start by taking a quick look at what Claude Code Security is and is not. If you haven’t read Anthropic’s announcement, I recommend you check it out. Essentially, Claude Code Security “scans codebases for security vulnerabilities and suggests targeted software patches for human review, allowing teams to find and fix security issues that traditional methods often miss”. Basically, Anthropic is saying that it will be able to truly understand the codebase and provide patches that people will be able to reliably accept. This part is important because there are many security startups focused on suggesting patches, so Anthropic is betting that it can do it as a part of its experience (which obviously makes sense), and that it can do a much better job than any of the add-ons (which again, I don’t see why it wouldn’t be able to).

If you know security and understand what kinds of capabilities we are talking about here, you have probably realised that, at the very fundamental level, Anthropic just announced a potential solution to application vulnerabilities that are currently being discovered with SAST scanning and such. Without a doubt, this can be a huge step forward, and it can help application and product security engineers find and fix vulnerabilities before the code is shipped, without having to chase down developers and convince them that they should care. Unless you are a founder focused on better code scanning to find vulnerabilities and help security teams fix them (i.e, unless Claude Code Security is coming to eat your lunch), Anthropic’s announcement is great news. However, in the grand scheme of things, it is addressing a very, very small (even if very important) slice of security.

​Security is about much more than finding vulnerabilities in code. Think about all the work that happens outside of the code repository, like:

• Managing identity sprawl and privilege risk (dealing with over-privileged users, stale accounts, unmanaged service identities, etc.)

• Detecting active exploitation attempts when they happen (detecting suspicious login patterns, unusual device activity, abnormal traffic flows, and so on)

• Enforcing network segmentation and egress controls (dealing with flat networks, exposed services, uncontrolled outbound access, etc.)

• Preventing cloud misconfigurations (flagging public storage buckets, overly permissive IAM policies, disabled logging, etc. - stuff CSPMs have been doing for a while)

• Protecting secrets and machine credentials (hardcoded tokens, shared API keys, long-lived certificates, and other things NHI startups have been tackling)

• Maintaining infrastructure integrity (i.e., dealing with configuration drift, unauthorized changes, unmanaged shadow infrastructure, etc.)

• Monitoring third-party and supply chain access (vendor VPN access, SaaS integrations, unmanaged OAuth applications, bring your own cloud, and so on)

• Automating compliance and preparing for audits (evidence collection, tracking risk acceptance, etc.)

• Responding to incidents across environments (taking actions to contain threats, revoking access, cross-system investigations, and other aspects of incident response)

• Restoring systems and operations after incidents or failures (all the stuff that can be bucketed under “cyber resilience”, such as environment rollback, data recovery, service re-deployment, etc.)

Claude Code Security, even if it works perfectly well, isn’t going to solve all these problems. This brings me to the main point: most of cybersecurity is here to stay, and AI will only make it grow faster and bigger than before.

Most of cybersecurity is here to stay, and AI will only make it grow faster and bigger than before

If we agree that the overwhelming majority of cybersecurity has nothing to do with code security, then it should be clear that in no way is Claude Code Security threatening companies like Palo Alto Networks, CrowdStrike, Zscaler, Okta, Cloudflare, and others that have had their stock price drop following the announcement. However, I’ll go further and say that for most companies in cyber, AI isn’t a threat but a real opportunity.

For decades, one of the biggest factors that would limit the ability of attackers to target companies has been the lack of resources. In other words, they simply didn’t have the time, talent, or ability to look everywhere at once. It’s not a secret that if you look beneath the surface, every single company is a mess on the inside, but because of how complex the environments are and how much time it takes for attackers to do reconnaissance, oftentimes what actually keeps companies from getting breached is the lack of resources on the attacker side.

With AI, that is soon going to go away. Attackers are not bound by corporate governance or acceptable-use policies deciding which models can or cannot be deployed. They will use every model available, every autonomous agent, every form of automation that allows them to enumerate infrastructure, map dependencies, generate exploits, and test hypotheses at a scale that was previously impossible. The cheaper LLMs become, the lower the cost of attacking will be, and the higher the volume of attacks is going to become. This shift is going to fundamentally change the economics of defense. When attackers gain near-unlimited reconnaissance and experimentation capacity, companies won’t be able to rely on reactive security. Very soon, hoping that vulnerabilities and misconfigurations remain undiscovered will stop being a strategy (let’s be honest, this is exactly what most companies are relying on today, and it’s kind of working).

As AI models get better and cheaper, I think companies will be forced to start fixing a lot of the problems they could previously just hide. When this happens, we will see massive growth across exposure, identity security, infrastructure security, and many other areas that are foundational to enterprise security.

AI will also expand cybersecurity by dramatically increasing the surface area that needs to be protected. Whether enterprises end up deploying AI agents themselves (most of them probably won’t do that for a while) or buying off-the-shelf tools that help with different use cases (seems more likely IMO), all the copilots, automated workflows, and model integrations are expanding the attack surface area pretty significantly. Whether these problems will get addressed by the existing solutions or we’ll see new vendors (I don’t have a horse in this race, so thinking it will be a mix of both), someone will have to protect AI deployments. That, in turn, will create more demand for cybersecurity.

We have seen this movie before

If you’re still skeptical about cyber surviving the new AI wave, consider that we have seen this movie before. Think back to the early days of cloud adoption, when most people thought that hyperscalers would effectively “solve security.” Standardized infrastructure, managed patching, and centralized controls were supposed to reduce risk and simplify operations. Instead, cloud removed friction from building and deploying software, and that acceleration changed the entire technology landscape. Development cycles compressed, infrastructure became ephemeral, and teams got the ability to spin up resources instantly without centralized oversight. That velocity created entirely new problems: CI/CD pipelines introduced software supply chain risk, infrastructure-as-code led to configuration drift, containers created runtime visibility challenges, and identities multiplied across humans, workloads, and APIs. Cloud didn’t just create the CSPM market; it basically led to an explosion of adjacent markets, including CIEM, container security, secrets management, SaaS security, Zero Trust networking, and many, many more. SaaS adoption alone (also enabled by the cloud) scattered data across hundreds of vendors and forced companies to rethink access control, governance, and third-party risk from the ground up.

I think that AI will follow the same pattern, but likely faster and on a larger scale. Already today, AI dramatically lowers the cost of building software and automating manual work, which means companies will deploy more systems, integrate more tools, and automate more workflows than ever before. The flip side of that is that every AI assistant becomes a new identity with permissions, every model integration becomes a new data exposure pathway, and every automated workflow becomes a potential attack surface. Just like cloud created entire categories to manage visibility, posture, and identity sprawl, AI will drive demand for both things we can think of now (model governance, agent identity security, data lineage protection, and all the other exciting stuff people are talking about) and plenty of problems we can’t even imagine.

The biggest lesson from cloud, in my opinion, is that increasing the speed of innovation does not reduce security needs; it multiplies them through second- and third-order consequences. AI is not going to kill cybersecurity, it will expand it across layers we are only beginning to recognize today. Obviously, when that happens, the market will grow massively.

Vibecoding isn’t going to kill security tools either

Another mistaken belief that I see spreading in the industry is that cyber is going to die because enterprises are going to be so empowered with AI that they will simply vibecode their own tools. Rather than re-explaining what I’ve tried explaining several times, let me just share what I recently shared on LinkedIn.

​

Source: my LinkedIn

I continue to stand by every single word here. AI is a game-changer because it accelerates how quickly we can build and ship new products, but speed is not the same thing as replacing the underlying systems that enterprises depend on. Large organizations don’t buy “features”, they buy outcomes. Buying software is about buying a lot of intangibles that come with it, like reliability, security, being able to pass complex audits across jurisdictions, operational resilience at scale, partners they can trust when something breaks at the worst possible moment, etc. If these intangibles weren’t so important, most companies would just be using open source (let’s be real, there’s an open source version of every single billion-dollar company out there).

The importance of these intangibles doesn’t go down just because code can be generated faster, I’d actually argue it goes up quite a bit. Now that everyone can ship software super fast, it becomes more, not less important that customers can actually rely on their partners.

Security has always been about continuously raising the bar for the attackers, as every time our defenses improve, bad actors find new ways to get in. Even if we eliminate entire classes of known vulnerabilities (which, by the way, we have been doing for decades), the ecosystem will change and attackers will find new weaknesses to exploit as they have done in the past. The real opportunity with AI isn’t in pretending that it somehow makes foundational infrastructure become obsolete (because it simply doesn’t), and not in hoping that we can just vibecode tools (because we can’t, without getting squashed by the complexity and edge cases at scale). The real opportunity is in using AI to navigate the operational complexity that makes security so hard in the first place.

Claude Code Security will still cause collateral damage

I have repeated several times in this piece that the cybersecurity industry is safe for now. That said, Claude Code Security will absolutely cause collateral damage. If a frontier AI lab can natively understand a codebase, detect vulnerabilities, and propose patches inside the same environment where code is getting written, the standalone value proposition of “we scan your code and suggest fixes” becomes very hard to defend.

SAST has always been the most obvious adjacency for AI labs. It’s actually pretty simple: whoever generates code will be able to absorb things like QAing that code and securing that code. This is great news for both security teams, who will no longer need to chase down devs to fix stuff, and for engineers, who can just accept a suggested autofix without having to think about security. Once vulnerability detection and auto-remediation are embedded directly into the development workflow, the appsec market will quickly start to look commoditized (I think it already does). The differentiation that many appsec tools rely on (better detection engines, smarter prioritization, cleaner reports) will become less compelling when the platform writing the code can also reason about and fix it. I have recently seen a few appsec companies known for building scanners come forward with messages that “Claude Code Security is a great thing for the industry,” but I don’t think anyone inside these companies truly believes that it is good for their business (they are right, though - it is great for the industry!).

Let me be clear: I don’t think that Claude Code Security means that application security disappears completely, even though the shape of it will change. If baseline code quality improves and common classes of vulnerabilities are prevented or auto-patched before pull requests are even merged, founders in appsec who built companies around identifying and auto-fixing code flaws will have to have some serious conversations at the board level.

I am by no means an appsec expert, but it’s becoming clear to me that while SAST scanners will be fading away, there are two kinds of new appsec products that are starting to take off. One is the new breed of product security tools that started to emerge in recent years. Companies like Prime Security, Clover Security, Seezo, and others (please do forgive me, founder friends, if I missed your company, these are just examples that came to mind) are just some examples of players for whom Claude Code Security isn’t going to be a threat. The other category of tools that are getting a lot of attention are runtime security solutions like Miggo, Oligo Security, Raven, and others (same disclaimer to founder friends applies). James Berthoty of Latio is a big supporter of runtime security, so I suggest you check out his thoughts if this is an area you are interested in.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

When people in the industry talk about many companies, it’s either innovative startups or powerful incumbents with unmatched distribution that get discussed. And yet, in the past five years, I recall having only one conversation (yes, one!) about what was once one of the most consequential giants in cybersecurity: RSA Security. This is a huge miss because, as you will see today, RSA Security, through its alumni, spinoffs, and the sheer impact it had in all areas of cyber, continues to influence the direction of security. That is exactly what this article is about.

This issue is brought to you by… Endor Labs

Ship secure code by default, whether it’s written by humans or AI.

Discover how to secure modern software in the age of AI with A Practical Guide to AI and Application Security. This essential resource demystifies how AI generates code, where the most critical risks emerge, and what AppSec leaders must do to protect AI-native development workflows.

Whether you’re tackling vulnerable dependencies, architectural risks, or integrating security earlier in your SDLC, this guide equips you with practical strategies to balance productivity and safety. Get actionable insights that help your team stay ahead of AI-driven threats and confidently secure code from the first commit to production.

Get the Guide

A brief history of RSA Security

RSA Data Security was founded in 1982 by three MIT cryptographers, Ron Rivest, Adi Shamir, and Leonard Adleman (the name “RSA” comes from the first letters of their last names). These three people, whom you don’t hear much about, invented what is now known as the RSA public-key cryptography algorithm, an algorithm that became one of the foundational technologies of the modern internet. RSA made encryption commercially viable during a time when the idea of secure internet communication itself was still pretty theoretical. RSA software libraries enabled secure web traffic, VPNs, email encryption, and financial transactions. Basically, their tech became embedded everywhere, from browsers to banking infrastructure all over the world.

RSA’s biggest commercial breakthrough came with the introduction of SecurID, a hardware token that generated one-time passwords for multi-factor authentication. RSA Data Security didn’t invent this product. Instead, in 1996, the company was acquired for $250 million by Security Dynamics which was in the business of making SecurID. Following this acquisition and integration of the RSA algorithms with the SecurID token, SecurID became the standard for enterprise authentication, used by governments, banks, and Fortune 500 companies. This acquisition was so consequential that in 1999, Security Dynamics announced it would be taking the name of its well-known subsidiary, RSA Data Security, and becoming RSA Security. For many organizations, RSA became synonymous with authentication itself.

RSA Security heavily leveraged M&As to expand into new areas and to acquire technologies it needed. Between 2001 and 2006, it bought and integrated several companies: Xcert International (digital certificate-based products for securing e-business transactions), 3-G International (smart card and biometric authentication products), Securant Technologies (identity management), Cyota (online security and anti-fraud for financial institutions), and PassMark Security (online banking authentication).

(As you can clearly see, these were the times when high-res logos weren’t a requirement).

Following its own acquisition spree, RSA Security itself became an acquisition target. On September 14, 2006, RSA stockholders approved the company’s acquisition by EMC Corporation for $2.1 billion. At the time, EMC was best known as a storage infrastructure giant, but it recognized early that securing data would become just as important as storing it. RSA became EMC’s dedicated security division and a cornerstone of its broader vision to help enterprises protect information across increasingly distributed and connected environments. Under EMC, RSA expanded far beyond its original authentication roots. It built a broad enterprise security portfolio that included identity and access management, security information and event management (SIEM) through NetWitness, governance, risk, and compliance via Archer, and fraud and risk intelligence platforms. RSA evolved from a cryptography leader into one of the most comprehensive enterprise security providers, serving governments, financial institutions, and large enterprises worldwide. Its technologies became deeply embedded in security operations, compliance programs, and authentication workflows across critical infrastructure.

RSA’s trajectory shifted again in 2016 when EMC was acquired by Dell Technologies in the largest technology merger ever ($67 billion!). RSA became part of Dell’s family of companies, alongside VMware and other infrastructure businesses. While RSA remained a respected name, it operated within a much larger corporate structure where security was only one part of a broader infrastructure strategy. That, however, didn’t last long as in 2020, RSA was spun out of Dell and acquired by Symphony Technology Group (STG), returning to independent ownership. This marked a symbolic full circle for a company that had helped define the cybersecurity industry decades earlier.

Some of today’s cyber giants were once members of the RSA family

Some of today’s cyber giants come from the RSA family, which includes communities, companies, and people.

RSA Security created the industry’s defining conference

March 15, 2022, marked the rebirth of the RSA Conference as a fully independent business. Originally started back in 1991 by RSA Data Security, RSA was once a small, specialized cryptography conference focusing on digital signature standards. Over the next three decades, it grew alongside RSA Security itself, following the company through its acquisitions by EMC Corporation and later Dell Technologies. In 2022, Crosspoint Capital, a PE firm focused on cyber and infrastructure software, acquired a significant interest in the conference and started operating it as a separate business.

Today, RSA Conference stands as the industry’s “town square”, a neutral gathering place where security leaders, practitioners, founders, investors, analysts, and policymakers come to shape the future of our industry. What started as a niche cryptography event a long time ago has now turned into something much larger - a place where people get to grow their careers, where startups first present their innovation to market, and where the direction of the entire industry takes form.

Enduring players that were once part of RSA Security

A number of companies that continue to play a significant role in their market segments were once part of RSA Security, including Archer, NetWitness, and Outseer.

Archer

Archer has been focusing on helping enterprises manage governance, risk, and compliance (GRC) since 2001. When most organizations relied on Excel spreadsheets, email, and fragmented workflows to track risk and compliance, Archer launched a centralized platform that essentially became an operating system for GRC. The product made it possible for large enterprises to map controls, track regulatory requirements, manage audits, and demonstrate compliance across complex environments.

RSA acquired Archer in 2010, recognizing that GRC was becoming a huge need at large enterprises. Under RSA, Archer became one of the most widely deployed GRC platforms in the world, particularly in highly regulated industries like financial services, healthcare, and government. Fundamentally, Archer became a system of record for enterprise risk, deeply embedded in how organizations understood and managed their risk and compliance (I described it as one of the “control points” in cyber).

In 2023, Archer was spun out as an independent company under Symphony Technology Group, also coming full circle and becoming an independent company. It’s hard to believe that, still today, 25 years after its founding (think about that for a second), the Archer platform remains one of the most trusted and widely deployed solutions for enterprise risk management and regulatory compliance, used by many of the world’s largest organizations. There are cohorts of new startups trying to go after GRC, some agentic and others not, but neither of them has so far been successful in taking on Archer at large enterprises at scale.

NetWitness

In April 2011, EMC Corporation acquired NetWitness, a network security analytics company led by Amit Yoran, a visionary security executive the industry tragically lost last year. EMC integrated NetWitness into its security division, RSA, combining NetWitness’s network visibility and packet analysis with RSA’s SIEM to provide a comprehensive threat detection and response. This acquisition ended up playing a much bigger role in the history of RSA Security. Amit Yoran, once NetWitness CEO, in October 2014 was named president of RSA, a position he held until he became CEO of Tenable in 2017. Although we lost Amit to cancer, he will always be remembered as one of the leaders who was deeply passionate about security and people in it.

In 2025, PartnerOne, an enterprise software conglomerate, acquired NetWitness from RSA, bringing things full circle and turning it into an independent company once again.

Outseer

The origins of Outseer go back to RSA’s Fraud and Risk Intelligence division, which focused on protecting financial institutions from online fraud, account takeover, and unauthorized transactions. As banking and commerce moved online in the 2000s, fraud quickly evolved far beyond simple credential theft into sophisticated, multi-stage attacks. RSA developed advanced fraud detection tools that analyzed user behavior, device fingerprints, network attributes, and transaction context to detect suspicious activity in real time. Under RSA, this business became one of the most widely deployed fraud and authentication platforms in the global financial sector. In 2021, Symphony Technology Group spun out RSA’s Fraud and Risk Intelligence division as an independent company and rebranded it as Outseer.

Companies that could have become a part of RSA Security but didn’t

While these are some of the better-known acquisitions and spinouts, in an alternate universe, RSA’s legacy could have been even more impressive. I’ve heard from multiple people that RSA Security once considered acquiring companies like Splunk and SailPoint, among others, though for various reasons those deals never materialized. Had they happened, the trajectory of the cybersecurity industry (and my “20 years of cybersecurity consolidation: how 200 companies became 11” article) might have looked very different.

Subscribe now

The most impactful part is the generation of leaders that RSA Security helped raise

The most impactful legacy RSA Security left behind is the generation of leaders it helped raise. Different people are a part of this “mafia” network in different ways. For example,

• Art Coviello, Jr. is now a Managing Partner at SYN Ventures, following a two-decade career as an executive at RSA, including ten years as CEO and five additional years as Executive Chairman.

• Ann Johnson is now a Corporate Vice President at Microsoft, following nearly fifteen years in executive leadership roles at RSA, most recently serving as Vice President of Global IPV and Global Accounts.

• Rohit Ghai is now CEO of Barracuda Networks, following over a decade and a half as CEO of the Division of Dell Technologies, and then CEO of RSA Security.

• Mark Thurmond, once SVP of Worldwide Sales at RSA Security, is now a Co-CEO at Tenable.

• Ash Devata, who is now CEO of GreyNoise, had a ~7-year run at RSA Security, culminating in the Head of RSA Solutions role.

• Dino DiMarino, once VP at RSA Security, is now CEO at AppViewX.

• Dave DeWalt, who would go on to become CEO of McAfee, CEO of FireEye, and then founder & CEO of NightDragon, was Executive Vice President and President of Customer Operations for EMC.

Plenty of people went on to eventually start their own companies, some a while ago and some pretty recently. The list includes -

• Rob Davis, CEO and Founder of Critical Start

• Aditya Narayana, Co-Founder of Mirror Security

• Jessica Alexander, Founder and CEO of Skematic, former VP of Sales at CrowdStrike

• Nadav Cornberg, CEO of Eve Security

• Dana Wolf, Co-Founder and CEO of YeshID

• Muli Motola, Co-Founder and CEO at Acsense

• Austin McDaniel, Founder and CEO of Good Code

• Brad Taylor, Co-Founder and CEO of PROFICIO

• Rob Black, Founder and CEO of Fractional CISO

• Mark Jones, Founder and CEO of BlackLake Security

• Peter Goldstein, Co-Founder and CTO of Valimail (now a part of DigiCert)

I am sure there are many more notable people, not all of whom are founders (after all, there are many, many ways to achieve impact in cybersecurity).

Closing thoughts

Cybersecurity is full of mafias. I have previously discussed a few of them in my other articles:

• The power of Check Point mafia, the impact of Foundstone, Juniper Networks & Cisco on the industry, and the origins of cyber ecosystems

• Splunk, Okta, Cylance, Palo Alto, CrowdStrike, and Zscaler mafias in cybersecurity

• Follow the people: @stake, NetScreen, IBM, Israel Defense Forces and the US Armed Forces mafia networks in cybersecurity

• Get ready for Wiz mafia to forever reshape the future of cybersecurity

RSA Security has given a raise to its own mafia. While the RSA Security’s booth is no longer the most prominent both at the conference it is named after, its impact lives on, through people, companies, and of course through the RSA Conference community it created.

Some in the industry still remember the three people - Ronald Rivest, Adi Shamir, and Leonard Adleman - who started RSA Data Security some 44 years ago. For their contributions, in 2002, they all received the Turing Award. The one other person to remember is Jim Bidzos, the original creator of the RSA Conference. Bidzos served as president and CEO of RSA Security from 1986 to 1999, and it was under his leadership that the RSA Conference was first started. Decades later, the event continues to grow beyond what Jim (or anyone else) would have ever imagined.

I’ll see you at RSAC 2026 in March!

Stop by my session, too (I am speaking), or come say hi at my book signing and grab your copy of “Cyber for Builders” (right after my session on Tuesday, March 24th at 11am at RSAC Bookstore).

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

This issue is brought to you by… Prophet AI.

The Economic Fix for the SOC: AI-Driven Autonomy with Human Guidance

Security leaders know current SOC unit economics are unsustainable. Hiring more analysts cannot scale to meet the volume of modern alerts, and legacy automation tools are often too rigid to maintain. Prophet Security offers a different path: AI-driven autonomy that elevates the role of the SOC analyst.

Prophet AI functions as a virtual SOC analyst, autonomously investigating alerts with the same depth, quality, accuracy, and transparency as your best SOC analysts. By handling the high-volume investigative grunt work, Prophet AI allows you to transform your SOC operations from one where analysts are consumed by repetitive tasks to one where they can focus on high-impact, low-volume AI-validation, threat hunting, or detection engineering.

Learn More

I think most of us feel Dug’s pain, and, unfortunately, we have to go through this Groundhog Day what feels like every single week. I most definitely agree with the sentiment Dug expressed, but I don’t agree with the analogy. It took me a while to realize why that is the case, so in this issue, I am talking about reasons why it doesn’t make any sense to draw parallels between safety and security.

The well-loved seatbelts analogy is sadly not relevant

People in security absolutely love to bring up the story of how seatbelts redefined road safety (if you’re not sure what I am talking about, here’s an example of how CISA compares its Secure by Design Pledge to the initiatives in the automotive and aviation industries).

The story goes like this. As the car adoption in the US increased in the 1950s-1960s, the number of road fatalities skyrocketed. It soon became clear that the mortality could be greatly reduced by adding safety features to cars, but making it happen wasn’t easy. First and foremost, car manufacturers, including GM and Ford, heavily lobbied against mandatory seatbelts and safety regulations, arguing they were expensive and unnecessary. Drivers, on their part, also weren’t excited about seatbelts because they made them feel uncomfortable. In the end, common sense prevailed, and in 1966-1968, a series of laws were passed that started requiring seatbelts to be installed in all new cars. It was, however, only in 1984 that New York enacted the first mandatory seatbelt usage law. By the end of the 1990s, almost all states made wearing seatbelts mandatory, and today we take seatbelts for granted, thinking that’s how things have always been.

The idea that we can do something similar with security, and have the government legislate everyone to become “cybersecure,” is appealing, as are all sorts of pledges. It would indeed be great if we didn’t have to reinvent the wheel in security, and instead we could borrow from other fields and learn from past successes. Unfortunately, this is quite unlikely to work, and the main reason is pretty simple: safety and security are two very different problems.

Safety and security are two very different problems

Safety addresses a stable, unchanging problem, but security doesn’t

First and foremost, safety controls address a stable, unchanging problem. Let’s take our favorite seatbelts as an example. Seatbelts were designed to address a very specific, very well-defined risk: injury or death during a car crash. There are a finite number of things that need to be considered and tested (things like speed, impact angle, where the passenger is sitting, how tall the car is, etc.). I am not suggesting that accounting for all these factors is easy, but the critical point here is that gravity doesn’t learn or change its methods. The physics are stable, we know pretty well how things are supposed to work, and if we recreate the same environment (which is easy because of the limited number of factors that need to be considered), we’ll get the same result.

Cybersecurity, on the other hand, is nothing like that. Attackers try different methods until something finally works, adapt their tactics, and purposefully look for gaps in security controls. My friend Luigi Lenguito, founder of BforeAI, puts it really well in one of his LinkedIn comments: “Many keep equating security and safety, but they are two very different problems. Safety is finding the root cause, fixing it, and having a safer environment with a tendency toward zero accidents. Security is putting controls and remediation, but meanwhile, new risks arise, so it does not tend to zero because the adversary is motivated to increase the harm and impact. It’s a non-controlled environment.” Basically, wearing a seatbelt won’t trigger a new kind of crash, but a security control often does trigger a new attack path.

I published a relevant deep dive a few weeks ago about how we are actually improving our security maturity, but it’s hard to see that because attackers are also improving their methods: If you ask these two questions, you’re asking the wrong thing. This is precisely the problem as attackers continue to adapt to the controls we put in place.

Image Source: If you ask these two questions, you’re asking the wrong thing

Safety prevents loss of human life and injuries, but most cybersecurity controls don’t

An equally important distinction between safety and cybersecurity is what’s at stake.

When it comes to safety, the concerns usually have to do with human life, or at least well-being. The reason why we spend so much time getting to the root causes of a plane crash is because of how catastrophic and devastating it usually is. We care about car safety, food safety, building codes, etc., for the same reason - because there is a long track record of people getting physically harmed or losing what we as a society can (mostly) agree is the most precious gift we all have, our lives.

Cybersecurity is thankfully not usually a matter of life and death. Despite all the bleak predictions and despite the fact that attackers could very well cause massive loss of human lives, the majority of cyber attacks have been financially motivated. There have, sadly, also been cases when people would get harmed because of ransomware attacks on hospitals, but (again, thankfully) it has not yet become as widespread as some predicted. Not only have most people not heard of the major security breaches, but the vast majority of the population haven’t felt any pain when their own data gets leaked. Here are some of the ways in which an average individual gets affected by security- and privacy-related concerns:

• Someone gains access to their email address and uses it to send spam. While this definitely creates inconvenience, it doesn’t usually lead to irreparable harm to the victims.

• Clicking on some link installs adware on the victim’s computer. In practical terms, this means that once in a while, a person will see some annoying message pop up in the bottom right corner that they will need to close. It’s inconvenient but not deadly.

• It is not uncommon for people to have their credit card data compromised, which typically leads to fraudulent charges on their bank accounts. I had that happen several times to me as well; in each of those cases, the bank will typically issue a new card and refund the lost amount.

I am not trying to underestimate the impact of security incidents on people’s lives. There are indeed cases when families lose all the savings it took them decades to accumulate, and private details of one’s life get leaked, causing irreparable harm and even a loss of life. However, most people think of these stories as anomalies, not something that can affect them personally. It is hard to blame people for this lack of awareness. Although our data is sold for pennies on the dark web, most people never feel the impact of the Uber or Equifax hacks beyond getting a breach notification email and some free identity monitoring solutions that most don’t understand the value of.

Basically, to most individuals cybersecurity breaches are a nuisance, and to most businesses they are, well… the cost of doing business. This can’t be compared to plane crashes or car accidents that often (almost always?) lead to real tragedies and lost lives.

Safety controls are designed to reduce the need for decision-making, but security controls can’t

A seatbelt is a seatbelt, and all people need to do to protect themselves is to wear it. A seatbelt doesn’t have any configurations, doesn’t depend on context, and it works (or fails) the same way every time. The same is largely true for other safety features like airbags, guardrails, or child safety locks. All of them are designed to be passive, predictable, and effective without needing ongoing mental effort from the user. Once safety features are installed, they tend to do their job the same way across millions of identical scenarios. This simplicity and predictability are exactly what made such a huge difference when it comes to physical safety, whether we’re talking about seatbelts, sprinklers, balcony railings, or whatnot. These things just work, and we don’t have to think about them much.

Cybersecurity, on the other hand, is all about context. Every control depends on the nuances of the customer environment, configuration, business processes, data flows, and so on. Not only that, but security controls actively interact with one another, oftentimes in ways people didn’t predict, and a single tiny gap can lead to cascading failures. Implementing a security tool the wrong way can (and does) itself lead to a breach, making it easier for attackers to get in (imagine if wearing a seatbelt increased the likelihood of a car crash). Because security controls are so contextual, whether they end up being helpful all comes down to humans needing to make decisions, find time, and implement 1,000 knobs well that are all interdependent. To be successful in security requires a lot more than following safety protocols. People have to think about tradeoffs, what makes sense in a specific context; they have to follow up, convince others, and maintain ongoing operational discipline, all of which are much harder to get right than wearing a seatbelt.

Safety can be solved through standardization, but cybersecurity can’t

One of the main reasons why safety measures have been so effective is that safety can be solved through standardization. Seatbelts work because the environment is standardized. Each of the 100,000 models of the same car is designed to work the same, roads are designed to work the same, and physics works the same way in Florida as it does in California, or China, for that matter. In a standardized environment, we can be pretty successful in implementing standardized safety measures. Once we know that something works, we can just mandate that this measure be enforced for all similar situations moving forward.

This is not true for cybersecurity. First of all, company environments are deeply heterogeneous; they are always in a state of change, and everything is heavily customized per organization, per application, per workflow, and so on. This is why standardization simply doesn’t work for cybersecurity. Worse yet, standardization itself can become the source of vulnerability. Nothing shows it better than the issues we’ve been seeing with network devices, such as VPNs, when thousands of companies that standardized on the same tool all get breached at the same time when the exploit is discovered in that tool. Getting breached because your firewall has a critical issue is like having 1,000 cars crash on the same day because of the seatbelt design. You can see how the seatbelt analogy just doesn’t work again.

Closing thoughts

I can keep going with the list of reasons why safety and security aren’t comparable. Others seem to be chiming in as well. In the same LinkedIn thread I referenced above, Ivano Bongiovanni made another great comment: “My favorite distinction between safety and security is the one that calls out human intent behind adverse events. Safety: no malicious intent; security: malicious intent. So you can have a safe system that is not secure and vice versa.” Another great point. There are plenty of examples that all lead to the same conclusion: it doesn’t make sense to draw parallels between safety and security, and it’s time to put the seatbelts analogy to rest.

This is both bad news and good news. It’s bad because we might not be able to easily repurpose the model that worked so well for safety to solve cybersecurity problems. But, it is also good because we can avoid the trap of trying to borrow paradigms from slow-moving industrial car manufacturing and airplane production to the iterative and fast-paced world of technology. I think it’s just about time to accept that the best we can do is to continue maturing our defenses so that we can consistently make it harder and harder for the adversaries to achieve their goals. There is no other magic answer.

Oh, and please do check out the episode of Inside the Network with Dug Song - it’s a great one!

Subscribe now

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

We know that there is a lot of nonsense being repeated, and in the past decade, we have started to challenge it. There is now even a dedicated book titled “Cybersecurity Myths and Misconceptions: Avoiding the Hazards and Pitfalls that Derail Us” by Eugene Spafford, Leigh Metcalf, and Josiah Dykstra…The point is, we are moving in the right direction.

There are, however, several myths that are just too persistent, and many years later, they are still widely accepted as truth. In a previous article, I tackled two: that “we aren’t getting any more secure than before” (not true) and that “there are simply too many security tools and we need fewer of them” (also not true). This week, I am taking a stab at another egregious lie - that “most CISOs are really bad at understanding the business, can’t translate risk into business language”, etc.

This issue is brought to you by… Tines.

Everyone’s using AI - So why are workloads still growing?

99% of SOCs are already using AI, yet 81% say workloads increased in the past year.

To find out why teams have yet to unlock AI’s full impact, Tines surveyed 1,800+ security leaders and practitioners worldwide for their biggest Voice of Security report yet.

A few standout stats:

• AI literacy and prompt engineering are the top skills security professionals need

• 44% of security work is still manual

• 87% report board-level attention to cybersecurity has increased in the last year

Get access to the full report here.

Get access to the full report here

Two decades ago, there were few CISOs with a strong track record as business leaders

“CISOs aren’t business leaders”, “CISOs can’t translate risk into business language”, “CISOs talk gibberish, and the board doesn’t understand what they are trying to say.”... All these statements are a part of the same narrative that CISOs are too much into the weeds, which prevents them from being great leaders.

Thirty years ago, in 1995, Steve Katz (1942 - 2023) was named to the newly created CISO role by Citicorp. This was the first time a company hired a dedicated CISO. Over time, many other businesses delegated the responsibility for security to dedicated leaders, elevating them to the role of a C-level executive (at least on paper). Despite what many would assume, this transition journey hasn’t been an easy one. When Steve Katz was invited to step into the CISO role, it wasn’t because Citicorp realized that technology needs to be secured. Instead, around 1994, there were rumors that Citicorp had been hacked, and no one knew whether it was true or not. It turned out that Citicorp’s systems were indeed compromised, and Russian hackers stole more than $10 million from the bank. All this makes it obvious that from the very first day, the CISO role has been designed to take responsibility for some of the hardest problems.

When more companies started hiring CISOs, there obviously wasn’t much of a talent pool of astute business execs with expertise in cybersecurity. On one hand, since the role was new, there were no people who had done it before. On the other hand, since companies had no experience hiring or working with CISOs, they couldn’t clearly frame what was expected of them, and how they could succeed after joining. It ended up being a lot of on-the-job learning experiences on everybody’s part: CISOs had to figure out P&L ownership, strategy, and working with boards, while companies hiring CISOs needed to learn where to draw the line between other roles and that of a CISO.

It didn’t help that different companies had vastly different motivations for hiring a CISO. Some wanted a partner who could advise them on risk and help the business become more resilient, and others just needed someone who could take the blame when things inevitably went wrong. The unfortunate part has been that many of the CISOs hired to act as scapegoats if something fails were given no resources and no executive support to actually make a difference. To put it differently, they were set up to fail. I don’t know how many of the roles at the time fit this description, but I do know well that many security leaders got pretty disillusioned by their early CISO gigs.

People who took CISO roles early on were often getting great promotions, at least in terms of a title (not so much in terms of compensation or responsibility, but that’s a whole separate story). Since most of the newly minted CISOs were experienced managers or directors, getting that “C” in their title was surely a great thing. Were they ready to do these jobs effectively? It’s a rhetorical question, but also, is anyone ever ready? Is a senior engineering manager ever ready to become a CTO? Is a senior finance leader ever fully ready to become a CFO?

The answer in most cases is not, but CISOs indeed had some real work to do. Most had no MBA and no background in business, so there were a lot of gaps to close. If you were to come twenty-five years ago and say, “CISOs aren’t business leaders”, “CISOs can’t translate risk into business language”, “CISOs talk gibberish, and the board doesn’t understand what they are trying to say,” I think most CISOs themselves would agree with you.

Fast forward to 2026, and the world looks very different.

Present-day CISOs are expected to be well-rounded business and technical leaders

It may come as a surprise to some, but a lot has changed since 1994, both in the world at large, and in security in particular. I’ll skip over the internet adoption, social media, smartphones, IoT, cloud, and AI because talking about that would make me sound condescending. However, I do have to point out a few security-related changes:

• Most people who took CISO roles before the year 2000 have either retired or found new careers as risk and strategy consultants, board members, etc.

• Many people who are looking for entry-level security roles today were born after Steve Katz became a CISO

• The infrastructure today looks completely different from what it did back then, the way businesses operate today is completely different from how they did back then, the way people work today is completely different from the way they did back then, and this list can go on forever.

The point is, the world has changed, and the CISO role has undergone a complete transformation.

CISOs today aren’t trying to figure out how to do their jobs - they have all the ingredients to be good at it. CISOs have formal education programs like the one at Carnegie Mellon, they have associations like the Professional Association of CISOs, they have resource hubs like The CISO Tradecraft, podcasts like CISO Series, and a virtually limitless number of other things. I’ve seen plenty of security leaders with an MBA, and many more with masters degrees in security leadership. There are also plenty of incredible books, covering anything from risk frameworks, leadership advice, and management skills (Assaf Keren, for example, recently published Lessons from the Frontlines, and Ross Yong’s book Why Most Budgets Go to Waste was released last year). If two decades ago, there was barely any information about what a CISO role entails, today, security leaders have more advice and resources than they probably need.

CISOs, on their part, are hungry to grow. I see more and more CISOs pursuing certifications like NACD.DC and DDN QTE to prepare for board roles, taking advisory roles with startups and getting involved with nonprofits. Take a look at the number of great CISO events, panels, podcasts, and you’ll see people who are eager to do more.

Then, there is executive and board support, a critical ingredient for any CISO to do their job. Obviously, it would be an overstatement to say that every security leader has what they need to be successful; in practice, things are pretty far from that. There are still plenty of organizations out there that view the CISO role as a liability shield, and there are still many companies that don’t want to truly invest in security, or don’t have any desire to do the hard work that maturing defenses actually is. All that said, a growing number of companies recognize the importance of security and dedicate the resources to do it well. In addition, in many organizations, CISOs have earned the ability to work directly with the board, which further elevates their impact.

When I am talking about all these changes, I don’t mean that business majors are doing MBA to become CISOs; I am talking about seasoned technologists looking to grow as leaders. Present-day CISOs are expected to be well-rounded business and technical leaders; just being good at either business or technology is no longer enough.

Most of the present-day CISOs are already well-rounded business and technical leaders

Subscribe now

The reason why I get so frustrated when I hear that CISOs are “too technical, too much into the weeds” or “unable to talk to the board” is the fact that these statements are rooted in the past that is long gone. The overwhelming majority of the present-day CISOs are pretty well-rounded business and technical leaders.

Think about security budgets for a second. We live in a world where every dollar invested in security competes with growth initiatives like sales, marketing, and engineering, all the while security continues to be viewed as a cost center with an asymmetric downside. Yet despite all this, many CISOs still get budgets approved for new tools, hiring more people (though this one is trickier), and making sure that critical areas like endpoint, cloud, identity, and network have solid coverage. Do you really think that when the CFO & CEO are deciding where to allocate budget, and the CISO ends up getting the money, it happens because the CISO just bamboozles them with technical jargon and some CVE-2024-XXXX speak? If you actually think that, I think you need to think twice. Every dollar invested in cyber is a dollar not invested in growth, expansion, and other strategic, revenue-generating activities. I would argue that any CISO who can get their executive team bought-in to fund new security initiatives, when everything is about cost-cutting and top-line growth, is a master communicator, negotiator, and evangelist.

Then there is the whole topic of working with the board. Everyone walking into the boardroom for the first time, be they CEO, CTO, CRO, or CISO, will have a lot to learn about what boards care about and what they don’t care about. Are there no CTOs who walk into the room expecting that they’ll be asked about their roadmap, only to instead end up having to talk about how the upcoming product is going to impact the company’s margins? Of course there are. Are CISOs making the mistake of assuming that the board wants to hear more about the work of security teams than it does? I am sure some are. And yet, contrary to popular beliefs, CISOs do not walk into boardrooms to discuss CVE-2024-XXXX (not the CISOs I’ve met anyway, and I have met plenty of them). Instead, they talk about business impact, regulatory exposure, operational resilience, brand and customer trust, and other areas relevant to the board. The idea that CISOs are “too technical” for the board ignores the reality that getting to the CISO role in 2026 requires mastering far more than technical triage.

It’s hard to expect that individual CISOs are going to fix systemic problems of security

It would be an overstatement that all the problems have been solved because they haven’t. Security continues to be hard, and while we had three decades to evolve both the role of the CISO and the mechanics of the industry at large, some problems remain. These are typically systemic issues, and not something we can expect CISOs to solve.

First, there is the fact that many companies truly just want to have a CISO to absolve them of the problems with regulators if something bad happens. I am not suggesting that this happens often, but I have personally met CISOs stuck in roles without any resources or executive support. While I am sure that there’s some 1% of the people who get stuck in these situations because “they are too deep into the weeds” and “they can’t explain the value of security”, the vast majority just get unlucky. Sometimes, convincing language and a strategic mindset are simply not enough (if you’ve been in this situation, you know what I am talking about).

Second, the value of security is objectively hard to communicate because it’s hard to measure. How do we measure risk reduction? How do we explain the ROI and quantify the savings of the attacks that didn’t happen because we had security controls in place? These are rhetorical questions, but when a CISO is working to get the budget for critical initiatives, they are forced to think about this. To be completely fair, it’s not just CISOs that struggle to connect their spend to outcomes. Take heads of people and culture (HR), or marketers who have a hard time attributing any sales activity to the specific initiatives they are driving. How do you quantify “good company culture” or “value of the brand”?

Third, too many organizations hold security leaders to unrealistic standards. Boards want certainty, and executives still measure security success by “no breaches” instead of resilience. Despite the fact that security teams can usually only advise on risk and rarely own the implementation of most controls, CISOs are expected to own the outcomes when those risks materialize. It’s also why posture management tools took off: while CISOs like to say that they are tired of getting more visibility tools, the reality is that oftentimes, all security teams are empowered to do is to get visibility into all the badness (nobody gives security the ability to fix anything directly).

Closing thoughts

While the CISO role has existed for 30 years, and while a lot has changed, some problems remain. We most definitely need to debate these problems and continue maturing our practices. At the same time, it’s really time to retire the lazy idea that CISOs are “bad communicators who don’t understand the business”. We are talking about people who have spent their careers getting to where they are, and they must have mastered some skills beyond triaging vulns and alerts.

The reality is more complicated and much less convenient: security is difficult to measure, difficult to justify, and impossible to “win” in absolute terms. CISOs who survive, and especially those who succeed, do so precisely because they’ve learned how to navigate that complexity. That is what being a business leader in security is all about.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

I am always super excited to hear from my readers, be it through messages or comments on social media, direct replies, or anywhere else. It doesn’t mean that I am great at responding (founder life), but I love a good debate about security. Disagreements are healthy because they mean people are thinking.

At the same time, there are two questions I get asked over and over again that, frankly, after all these years, still frustrate me every single time. Whenever I see them, I can’t help but wonder: How are we still asking these questions? What do we think they add to the conversation?

In this week’s issue, I want to talk about these two questions and why I think people asking them are completely missing the bigger picture.

“... do we really need this many point solutions?”

Every time I talk about the market, celebrate the growth of security startups, or simply mention the fact that Google’s biggest ever acquisition is a security company, someone will always jump in with some variation of the same comment: “Should we really be celebrating that? Why do we need so many point solutions? We need fewer products so that security teams can more easily make sense of the market”.

To be clear, I totally get where that frustration comes from. The market is 100% crowded, security teams are overwhelmed, stretched thin, and constantly bombarded by endless sales outreach. That fatigue is real, but the question if we need more point solutions completely misses the point.

Saying that “we don’t need this many point solutions” ignores a basic understanding of what a market economy is and how it works. People want to have choices, and the market delivers. Nowhere is it easier to see than here in the U.S. Walk into a Walmart and ask whether we need this many brands of toilet paper, ketchup, sausages, or candy. The answer is obviously no (not just because many of these options are legitimately harmful, but also because nobody can tell the difference between 30+ brands of toilet paper by looking at the package). And yet, that answer is completely irrelevant: people want the ability to choose, everyone has slightly different preferences, and we end up where we are.

Here’s an analogy for you. Imagine someone walking into a massive grocery store (Walmart, Target, Costco, or pick your favorite one). The whole experience is not for the faint of heart: there are endless aisles, several hundred different sauces, seventy kinds of pasta, and all kinds of ads playing on large screens. Some of the brands look familiar, often from TV and online ads, but the majority are completely new. The person starts grabbing things that look great - some fancy chicken wing sauce, five pounds of frozen shrimp because it’s on sale, a few protein bars they saw on YouTube, a bag of kiwi because the packaging looks nice, and so on. Some hours later, the person gets home and puts all the stuff on the counter only to realize that they have spent a few hundred bucks, bought a ton of crap, but don’t have anything that adds up to a meal.

Now let’s ask the obvious question: Is the grocery store broken? Should the store carry fewer products? Should it remove half the shelves to make the whole shopping experience feel much simpler? Maybe just have one brand for every product? Wouldn’t just a section with salt and pepper be enough, instead of a whole aisle with spices most people have no idea how to even spell? I don’t know about you, but I don’t think so. The store did exactly what it’s supposed to do: offer choice. The real problem here is that the person went to the store without a shopping list and without a clear plan of what it is they would like to cook for dinner, so instead of buying the ingredients they needed, they bought a ton of crap that doesn’t add up to a meal.

I often feel like this is kind of what we have in security. Way too many people simply can’t find the time to sit down and think strategically about what they need (some also continue to believe that security is a shopping problem), so they end up just reactively buying tools. Obviously, vendors absolutely love that, so they amplify these messages - “just buy X, and we’ll solve all your problems”. The amount of noise is absolutely insane, so it’s not surprising that security teams are overwhelmed. At the same time, the reality is that starting with the market and all the available options is always going to be overwhelming, whether you are shopping for a pack of toilet paper or an EDR. Nobody should be expected to know every tool and what it does, similar to how neither of us truly knows the difference between every kitchenware brand.

Starting with clarity about the problems the company is trying to solve and the criteria it truly cares about makes the whole experience of choosing the right partner much easier. When the security team gets enough resources and space to think strategically about what it is trying to do, many problems go away. This makes me think that the real issue in the industry is not that there are “too many point solutions”, it’s that most security teams are so overwhelmed that they can’t even find time to think about strategy, or what tools would best support that strategy.

Until we solve this problem, there is one shortcut that I think can help. I think that the easiest way for security teams to figure out if they should talk to a vendor is to ask themselves - Can this vendor help us with essentials? Can it help us improve the basics? The hard truth is that most companies get breached not because of some zero-day, nation-states, blockchain, or AI-powered attacks; they get breached because of the basics. It’s always some unpatched server that wasn’t on the inventory list, some orphaned account access that didn’t get revoked, some hardcoded credential, some network access exception that didn’t get removed, and other pretty mundane problems. Focusing on what matters alone will filter out 80%+ of the vendors, and do wonders for the organization’s security.

Subscribe now

“...but are we getting more secure?”

I love this one. It usually goes like this: I will say something to the effect that “Over the past decade, we have started to see enterprises invest more into their security” or “I see more and more companies using AI to solve security problems that previously were impossible to solve”, and someone will inevitably show up to ask “...but are we getting more secure?”.

First and foremost, let me answer this once and for all: YES, WE ARE. I think this is the first time I have used all caps in my blog, so that should tell you what I think about this question.

Every year, companies continue to improve their security defenses. Say what you want, but this is happening. There are more companies with an EDR today than there were a year ago. There are more companies using MFA than there were a year ago. There are more companies patching vulnerabilities than there were a year ago. Overall, more organizations have better tooling, better frameworks, more experienced engineers, and far more institutional knowledge than they did 10, 20, or 30 years ago. This list can go on and on.

The question you might be asking is, “So why do we see more and more breaches?” Well, the answer is pretty simple: it’s because the attack surface we have to defend expands faster than anything anyone on the planet can contain.

Over the past several decades, we have seen the attack surface multiply every single year:

• Every year, we are shipping more and more code (this was true before AI, and it is even more true today)

• Every year, IT environments are becoming more and more sprawled, fragmented, and complex (this is true regardless of what you look at - identity, cloud networks, etc.)

• Every year, there are more and more connected devices of all kinds.

The bottom line is that what used to be a handful of on-prem systems is now a constantly shifting mix of cloud infrastructure, SaaS, APIs, identities, remote users, vendors, containers, and ephemeral workloads. Every new layer adds flexibility and speed, but also complexity and exposure.

Let me draw what ends up happening because having a visual in front of us will make explaining this much easier. Here is a picture that captures what’s happening in security, where maturity is going up, and the attack surface is expanding.

Those of you who are very observant will look at this image and say, “How can we be getting more secure if the gap continues to increase?” You are right - the gap between our security capabilities and the attack surface is now the largest it has ever been. This gap is the main reason security teams experience so much pain and suffering, why they feel overwhelmed, and why buying “just one more product” rarely fixes the underlying problems. It is also because of this gap that we keep seeing more and more breaches.

All that said, the world still hasn’t collapsed under the weight of all the breaches despite what some predicted. A lot of the credit for that goes to people working tirelessly to keep us safe, but we cannot ignore the simple fact that defenses have improved dramatically. Security maturity continues to increase, security controls continue to get better, defaults are getting safer, detection is becoming faster, and misses, while still painful, are far more contained than they used to be.

Let’s continue our thought experiment and think about what things could look like if the defenses weren’t in fact improving. The attack surface would continue to expand regardless, and so the gap between the state of security & attacks would be enormous.

All this is to say that if we weren’t in fact getting more secure, things would have been as bad as some people imagine. This, however, isn’t at all what’s happening.

Every year, we continue to mature our defenses, and we cannot forget that security vendors play a critical role in educating the market about different ways of solving problems and providing customers with solutions. If some early adopters didn’t bet on a startup called CrowdStrike in 2011, we would still be using McAfee to secure the endpoints. If nobody worked with a startup called SafeChannel when it started in 2007, there would be no Zscaler (in 2008, SafeChannel changed its name to Zscaler). This list can go on and on. It would be misguided to say that CrowdStrike, Zscaler, Duo, and many other startups didn’t make us more secure because they did.

Here is what it comes down to: attackers are innovating all the time, but 99.999999% of security and IT teams are barely equipped and staffed to keep the lights on, let alone to build their own tools. This is why we do need more startups and more venture capital to go into security.

You are probably still skeptical, thinking, “Sure, we need startups, but we don’t need that many of them!” It would indeed be amazing if we could just get a single company solving a single problem, and they would do it well, but sadly, that is not how innovation works. There is often a cohort of first entrants who work to educate the market about a new threat or a new way of doing things, and then someone else shows up and wins the market that has already been created. Case in point is CSPMs: there was already a decade-long history of attempts at solving the cloud security problem, and a lot of learning about what worked and what didn’t before Wiz was even founded. I will go on the record and say that without the first 10-15 point solutions trying to secure the cloud, Wiz would have never happened.

All this is to say that the answer to both of these questions is a resounding Yes. Yes, we do really need this many companies, and yes, we are getting more secure. That is where I stand and that is what I continue to both see and believe.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

Share Venture in Security

Some people read these events as ServiceNow trying to become a security vendor, but this is not at all the case. Instead, it looks like the company is betting on “workflow gravity” to become a leader in security. In this piece, I am explaining what ServiceNow bet is and why it stands a real chance of becoming a sizable player in cyber.

This issue is brought to you by… Drata.

Real-Time Visibility for Modern Security Teams

In a world where cyber threats evolve faster than manual audits, visibility and automation are key to reducing risk. Drata empowers security and compliance teams to continuously monitor and prove compliance across frameworks like SOC 2 and ISO 27001—without slowing business operations.

Our platform integrates with your existing tech stack to surface real-time risk insights, streamline evidence collection, and eliminate the manual overhead of compliance readiness.

Whether you’re protecting your organization’s reputation or building trust with customers and stakeholders, Drata helps you stay audit-ready and resilient—continuously.

See Drata in action

The concept of workflow gravity effect

To make sense of the strategy ServiceNow is going after, it’s important to understand the concept of workflow gravity and why it matters.

If you have read my previous deep dive about control points, this is going to sound very familiar, but if you haven’t, here’s a quick context. Every function of security has a centralized system where most of the work happens (I call these control points). For example, the entirety of security operations currently lives in a security information and event management (SIEM), while identity governance platforms like SailPoint remain the main operating system for enterprise identity.

Image Source: Owning the control point in cybersecurity

If we take a few steps back and look at the entirety of the enterprise, it’s easy to see that where work happens is largely defined by two factors: data gravity and workflow gravity.

I have previously talked about data gravity, and although years have passed, the idea remains as relevant today as it was then. In simple words, data gravity is what we see when something becomes a system of record for a function, and as more and more data is centralized in a single interface, it attracts even more data, creating a flywheel. Think about any SIEM: the more data a company sends into a SIEM, the more insight it can extract, and the more it makes sense to send other data to the same system. Over time, it becomes possible to add other offerings on top of that data, especially in security, where so much of what we do is just different ways of analyzing and correlating the same data.

Workflow gravity, on the other hand, is when a system becomes the system of action where work happens, and then uses this position to pull other work into the platform. While Splunk has successfully centralized enterprise data, ServiceNow has effectively won the title of becoming an operating system for enterprise IT. In effect, ServiceNow has become an enterprise “system of action” with unified data and AI experiences built into workflows. This is an incredibly powerful position because once a company owns where work flows, it gets the ability to influence and eventually own how decisions are made.

The workflow gravity effect creates a flywheel

One of the things that makes the workflow gravity effect so powerful is the fact that it creates a flywheel.

First, all work is centralized in one place, and all the incidents, changes, approvals, exceptions, tasks, evidence, etc., all of that becomes a record in a single workflow system. The more this system is used, the more context it accumulates. This context comes in all forms - change history, comments, links to additional information, and so on. ServiceNow contains a treasure trove of historical data about everything from who requested what to why a certain person requested access to a new application three years ago. Every action leaves some paper trail, and in the vast majority of large enterprises, all this lives in ServiceNow.

Once a single system accumulates so much business and technical context as well as history of what changed, when, how, and why, it becomes possible to automate triage, routing, prioritization, approvals, and remediation in a way that point tools struggle to do. The more automated it becomes, the more likely it is that anything still operating outside of these centralized systems will be integrated into the same workflow, as that’s where most of the work already occurs.

Cybersecurity is a perfect target for workflow gravity

Cybersecurity has three characteristics that make it especially workflow-native.

First, security is cross-functional by default. Nearly every security function is a part of some business process: cloud security is a function that impacts cloud engineering, application security impacts software engineering, identity security impacts identity and IT, and so on. Consider identity and access management, for example. When a user submits a ticket to request access to some application, someone has to review the request, make sure the policy & risk criteria are met, and then decide if it should be approved. At the end of this process, the user will be granted access, and the whole process will be documented as evidence for an audit.

Second, security is continuous (or rather, it should be continuous, though some companies are still stuck in the mindset of relying exclusively on periodic checks). Using identity as an example, it’s not enough to run quarterly checks to make sure that the right people have the right level of access (though they are still needed); the company needs to make sure that every request is evaluated and the risk implications of every single change are understood.

Lastly, security is a proof-driven discipline. Every single change needs to be documented along with its risk implications, so that the rationale for decisions is captured and stored for audit. The fact that ServiceNow is where workflows live makes it the place where audit evidence lives (this also means that ServiceNow is a treasure trove of data for companies using agents to automate manual GRC work, but that’s a separate conversation).

ServiceNow’s unique strategy of absorbing security categories into a unified “see, decide, act” platform

There is no shortage of companies fighting to win in the lucrative cybersecurity market. Each of the contenders is trying to capitalize on its core advantages:

• Palo Alto started as a firewall company and has now expanded into nearly all areas of security, which, as of recently, following their acquisition of CyberArk, includes identity. At the core, Palo Alto used the generous revenue it generates from its network security business to build an incredibly broad and deep cyber portfolio and push the idea of pjatformization to which the market responded very well.

• Cisco, a company that acquired the largest number of cybersecurity companies, has initially capitalized on its deep roots in the networking space and used cash from networking to fund its expansion in cyber. Today, with the acquisition of Splunk, it also has the data gravity working in its favor. Notably, Cisco’s strategy has always been very different than that of Palo Alto: instead of integrating the acquired companies into a single platform, Cisco likes to give them the freedom to operate independently, but with additional resources of a global powerhouse.

• Microsoft has been highly successful relying on its strategy of bundling to get enterprises to consolidate a wide range of security capabilities with the same vendor that already handles a lot of their IT.

• CrowdStrike has used its leadership in one of the largest cyber markets - endpoint - to also expand into adjacent security categories, and its growth over the past decade clearly shows that that strategy has been highly successful.

• Zscaler, on its part, has relied on its ability to inspect traffic to add a wide range of security offerings and also become one of the top global cybersecurity leaders. Recently, the company has finally entered the security operations space with the acquisition of Red Canary.

Each of the contenders for the title of the winner of the cybersecurity market is leveraging different strengths and taking a different path to the same goal.

ServiceNow stands out as a player with a distinctively unique set of advantages. ServiceNow’s core differentiator is its ability to turn messy cross-team work into structured workflows that can be measured, governed, automated, and secured at scale. Let me be clear though: the fact that ServiceNow has security ambitions isn’t new, as the company has had security operations offerings for years (incident response, vulnerability management, etc.), and it has a strong track record connecting security tools and streamlining response. To date, ServiceNow acquired six companies focused on security, compliance, and risk management: Intréis (2015), Brightpoint Security (2016), Fairchild Resiliency Systems (2019), Mission Secure (2024), Veza (2025), and Armis (2025).

What’s different about this phase of ServiceNow strategy is that instead of integrating with security solutions, the new move is much more aggressive: to acquire control points in security where “visibility + prioritization” decisions start.

The acquisitions of Veza and Armis make this strategy rather obvious, as both of the acquired companies fit the gravity model very well. Identity decisions create constant work, from access requests, access reviews, managing exceptions, and remediation, which is exactly the space where Veza has been playing. From the security standpoint, the answer to identity problems isn’t just detection, it’s approval combined with enforcement and evidence collection, something that lands itself in the workflow territory. Armis, on the other hand, is an exposure management platform, and exposure management produces arguably the most “workflowable” output in security: prioritized risk that needs action (assignments, fixes, compensating controls, exceptions, etc.). Both platforms create cross-org coordination work: in the case of identity, it’s between employees, IT, and security, and in the case of OT/IoT/medical devices, it’s between facilities, biomed, IT, security, and so on. Put simply, Veza helps ServiceNow own “who/what can access,” and Armis helps it own “what’s out there and how risky it is.” Both of these are upstream decision points that feed everything else. It’s pretty obvious that these acquisitions aren’t about adding another security SKU to the broader portfolio; they’re about assembling a platform where security decisions get made and implemented. You can read it as a three-layer stack ServiceNow is trying to own: see (gain visibility into different aspects of security), decide (understand impact, prioritize, govern, etc.), and act (ServiceNow’s bread and butter of ticketing and workflows).

Data may be the new oil, but it’s workflows that get redefined with AI agents

People like to say that in the age of AI, data is the new oil. I am not going to dispute that, but I do want to point out an important nuance. Having quality data has been critical for over a decade, ever since tools like data science and machine learning became ubiquitous in the tech world. The impact of AI agents is not really changing the importance of data. What it’s doing is raising the importance of workflows.

The current generation of AI, and specifically AI agents, makes it possible to automate a lot of work that has previously needed to be done by humans. The most impactful innovation of the present is about workflows, and guess what, no single system on the planet houses more enterprise workflows than ServiceNow. This is why, in my view, ServiceNow is the platform that has very high chances of benefiting from AI agents for everything, including automating security workflows.

Closing thoughts

I think that the ServiceNow strategy isn’t just a very smart move for the company, but it can also be great news for the industry. We like to talk about security by design and embedding security into the products from the very moment we design a new solution. This surely is something that we should be aspiring toward, but even if that were to happen (which I am not overly optimistic about), I don’t think it’d have as much impact as people believe it would. The majority of risks aren’t an outcome of poorly designed products; they are an outcome of organizational complexity. Since I’ve used identity as an example throughout this article, I’ll use it here as well. It’s not that all applications get shipped with broken authentication and authorization functionality, it’s that at enterprise scale, it’s insanely hard to get these right.

We’ve all read reports that over 99% of all breaches will be the result of misconfigurations, and I am a firm believer that that’s exactly what’s going to happen (if it hasn’t already). If we want to solve the problems of enterprise security, we need to find a way to embed security into the enterprise workflows. I don’t think there’s anyone who would be in a better position to do this than ServiceNow. If it plays its cards well and if it uses the advantages it gets with AI, it can very well reshape the way cybersecurity is done.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

This issue is brought to you by… Tines.

The security leader’s playbook to GRC

Manual compliance work is costing your team time - and fueling burnout. But the path forward from planning to action can feel ambiguous. Which workflows deliver the fastest value? How should APIs be configured?

In this new security leader’s playbook to GRC by Drata and Tines guide, you’ll learn:

• Concrete steps to replace reactive compliance with continuous, automated GRC

• Key use cases for GRC orchestration including streamlining evidence collection, and audit preparation and response

• Metrics of success and a sample ROI model for a more resilient, proactive GRC program

Get the Playbook

The one thing that makes selling security different than selling most other products

We can talk all we want about how security is different from other industries. I do this pretty often because not everyone understands that security is a horizontal, not a vertical; that in security, there is a unique driver of innovation that can’t really be found in any other market except for defense - the adversary, and that for a long list of reasons, everything in our industry relies on trust.

All this is true, but we’ll never be able to understand the complete picture until we discuss why selling security is different than selling most other products. The reason why that is the case is that most of the time, sales motions in cyber are defensive. What this means is that security leaders aren’t casually exploring “what new tools are available on the market” and instead, they are responding to the risk, compliance, or board-level concerns. Don’t take me wrong, CISOs and other security leaders are most definitely curious about what’s out there - what new startups, ideas, and approaches are companies trying. Yet when it comes to actually writing checks, most security leaders have fundamental challenges they need to address first, well before they do a test drive of some new cool idea. These fundamental problems tend to also be pretty boring, but that’s a topic for another article.

Think about how the buying motion works in other fields. As a product leader, I bought and advocated for my fair share of product management tools. I did that because I had certain goals to drive, but also because I wanted to experiment with different solutions to see if they could move the needle for us. Marketers are especially notorious for this, which is why they try - buy - churn their tooling nonstop. Most other functions have some breathing room to experiment, but security teams are always so behind and so overwhelmed with their existing problems that they barely ever have time to shop for “what’s new and interesting”.

Most security purchases have historically been rooted in helping companies not get screwed, and not in achieving efficiencies or helping CISOs be more innovative. This is why fear, uncertainty, and doubt (aka FUD) have worked as the only drivers for a while. While in other markets, new ideas have usually been focused on helping companies gain new competitive advantages, achieve efficiencies, or save costs, security buyers would want to see proof that they’re making a safe choice and that they will be protected when something bad happens.

Changing reality of cybersecurity sales

Over the past several years, the way cybersecurity products are being bought and sold is changing, and old playbooks are starting to fall apart. There are too many ways in which this is happening, so here’s just a taste.

We’ve largely moved from proof of concept (POC) to proof of value (POV)

This may sound like a play on words for some, but it’s not. One of the trends I am seeing is that we’ve largely moved from doing proof of concept (POC) to doing proof of value (POV). The difference is pretty simple. When a security product relied on some real deep tech and unique novel ideas, CISOs would do the so-called proof of concept (POCs) to understand how the solution works, what it does, and how it works with everything else already configured in their environment.

Fast forward to today, and we see that most concepts are pretty well understood. When someone says words like “runtime”, “posture”, “proxy”, “firewall”, “sensor”, etc., we have a good idea how things are going to work. In 2025, CISOs don’t really need to validate concepts; they need to see value, and that is a completely different game. Just because the sensor is looking at some telemetry, doing analysis at runtime, and generating findings, it doesn’t mean there’s going to be much value. The same applies to just about anything in security. The founders today aren’t going to get asked “How does it work?”, they’re going to get asked “So what?”.

CISOs are starting to ignore FUD and look for ROI

As I am starting on this paragraph, I am realizing that this whole section could have very well been called “going from one three-letter word to another”. Kind of expanding on the previous point, I am seeing that more and more security leaders are tired of FUD. Every startup keeps telling them, “If you don’t buy what we’re selling, you’re going to get breached”, and because everyone is repeating the same pitch while selling different solutions, I think this argument has become completely overused.

CISOs are starting to ignore tools trying to scare them, and instead look for enablers of business resilience and efficiency. Security leaders are starting to ask how the tool is going to help them make their company more successful - eliminate manual work, answer requests from other teams quicker, and so on. A part of me feels like this whole situation is pretty ironic. For the longest time, security vendors have been investing a ton of marketing dollars in helping spread the message that CISOs should be “business savvy and business enablers”. Now when we are at the point when CISOs are doing exactly that, we are learning that most of these vendors aren’t actually “enabling” anything for the business. They’ve helped create a buying criteria that they can’t satisfy, so to speak.

The fact that CISOs are looking for ROI doesn’t make it easier to communicate it

This is where what we want faces the harsh reality of cyber: just because we want to show ROI, it doesn’t make it any easier to do it. Money is no longer free, so most companies today are becoming smarter about their budget allocation. This is bad news for security because every time a CISO is pitching a security initiative to get the budget, it gets evaluated against other, revenue-generating projects. If a company is trying to double its revenue year-over-year, is it more likely to invest in a new security initiative, or something that marketing, product, or sales say is going to increase revenue and improve gross margin? The answer is obvious.

I don’t think most people truly recognize how hard it is for CISOs in many companies to secure new budgets. We often hear the nonsense that “many CISOs aren’t business leaders”, but I haven’t seen anyone recognize that any CISO who can get their executive team bought-in to fund new security initiatives when everything is about cost-cutting and top-line growth, is a master communicator, negotiator, and evangelist.

The challenge of communicating the value of security starts even before communication. How do we measure risk reduction? How do we explain the ROI and quantify the savings of the attacks that didn’t happen because we had security controls in place? These are rhetorical questions, but when a CISO is working to secure the budget for critical initiatives, they are forced to think about this. To be completely fair: many other execs have trouble tying their spend to outcomes, not just CISOs. Take marketers who struggle to attribute any sales activity to the specific initiatives they are driving. What’s different about CISOs, though, is that they also get less attention, and the only outcome boards are happy with (zero breaches) is not at all realistic.

Cyber sales in 2025 are stuck in a limbo

My conclusion is that cyber sales are getting stuck in a limbo. On one hand, FUD no longer works, unless the company has so much mindshare that buyers simply see it as the safest option (startups rarely fall under this category). On the other hand, we are continuing to struggle trying to communicate the business value of security controls, and with that, to come up with an alternative to FUD (which, by the way, hasn’t served the industry well, but which has most definitely enriched plenty of companies).

The biggest industry gap, in my view, has nothing to do with the ability of security leaders to communicate the value of security controls, even though that’s what is often being brought up at conferences and on social media. Instead, it is the fact that way too many entrepreneurs have no idea what problem they are solving. I remember having a chat with my friend Jonathan Haas, who put it really well: the reason most early-stage startups aren’t growing is that they haven’t figured out what it is they should be growing. To say it differently, they have no idea in what direction they’re moving, or even simply what problem they are trying to solve. Behind all that “next-gen” and “AI-powered” fluff is the fact that they can’t pinpoint which workflow they are addressing, what tool they are replacing, and who they are trying to sell to. It’s fine to not have these answers at the seed stage (after all, that’s what the seed stage is for - to get these answers), but shockingly, you’ll meet some companies that have been around for 5+ years and that are still struggling to figure out who they are and why they exist.

Going into 2026: challenges and opportunities for security leaders

I don’t think the lives of CISOs are going to get much easier going into the new year, but I do hope that they will continue to get more support from their leadership. In 2025, we’ve seen several cases when company founders and CEOs stood by their CISOs instead of throwing them under the bus when things went wrong, the most prominent being the story of Coinbase. Also recently, we saw the SEC dismissing the case against Timothy G. Brown, the CISO of SolarWinds, who, by the way, remained the CISO of the company while going through the nightmare of continuous litigation.

The signs are pretty positive for CISOs, but for obvious reasons, I don’t think their jobs will get any easier. The budgetary pressure will continue to force them to do more with less, and the noise from all the vendors in the space will only make it harder to tell the difference between what’s real and what’s BS. The silver lining is that all this noise should serve as an opportunity for security leaders to refocus on fundamentals, because they are what truly matters. Companies continue to get breached because they are not doing the basics well, and not because they haven’t bought some next-gen whatever.

Going into 2026: challenges and opportunities for founders

Going into 2026, the market will only become more competitive. Over the past several years, tens (or maybe hundreds?) of new startups were founded, most of which are still in stealth, but all of which are trying to solve various problems and offer new solutions. Most of them aren’t trying to address new problems - they’re going after the exisign markets, which means they’ll have to convince buyers to replace their existing solutions. That’s going to be pretty hard. Nearly a year ago, Eyal Worthalter published this post on LinkedIn that I strongly agree with:

“The “better mousetrap” pitch is dead in cybersecurity. Here’s why. Most enterprises have already laid their security foundation. EDR, SASE, SIEM, CSPM - the core stack is in place. Not perfect, but good enough to handle almost everything.

Last year taught me this: After demonstrating 40% better detection rates in a flawless POC, the CISO still walked away. Why? Because “better” isn’t enough anymore. Think about what we’re really asking when we pitch a “better” solution:

• Rip out existing integrations

• Retrain the entire security team

• Rebuild automated playbooks

• Revise procedures and documentation

All for what? Incremental improvement. The hard truth? Unless you’re 10X better (not 50% - 10X), you’re fighting a losing battle against organizational inertia. “Good enough” is your real competitor, not other vendors. I think in 2025 we are only going to see deals close when:

1. Compliance requirements force change (i.e. your product solves a niche industry requirement)

2. We solve a net-new problem their stack can’t touch

Both A and B depend on the product. So not much sellers can do about it. Instead, if we demonstrate order-of-magnitude improvement that justifies the organizational pain and drives better business outcomes, we can land better deals. Everything else is just contributing to option fatigue in already overwhelmed security teams. Most honest feedback I got last year was: “Your solution is better. But ‘better’ isn’t worth the change management overhead.” - Source: Eyal on LinkedIn.

Eyal’s words were true a year ago, and they’re going to be even more true a year from now. Obviously, as founders, we have to be betting on the fact that there will continue to be enough interest from CISOs to buy from the new generation of companies. I am sure there will be, but the bar for startups will continue to go up. While it’s not going to get easier, I think when the pressure is on, and survival instincts kick in, people will figure out what they stand for faster and more efficiently.

To close the year off, I must say that the industry continues to mature, and I continue to be incredibly optimistic about where things are headed (if you are not, please read the Cyber optimist manifesto: why we have reasons to be optimistic about the future of cybersecurity). May the new year be the year when more companies develop clarity about their purpose, and may they have enough runway to be able to do it. Building startups is hard, and I wish everyone who is working tirelessly to defend our present and the future lots of success in the New Year! CISOs, founders, marketers, investors, security professionals, - regardless of who you are, we are all on the same side. Happy New Year!

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share

Subscribe now

This issue is brought to you by… ZeroPath

Why Your SAST Tool Misses the Scariest Bugs

ZeroPath has discovered critical vulnerabilities in curl, sudo, and Next.js that every traditional SAST, SCA, and secrets scanning tool missed. These are some of the most scrutinized open source projects in the world, but legacy security tools left them exposed. Conventional appsec tools rely on pattern matching and static rules that don’t understand how your code actually works. They miss the business logic flaws, authentication bypasses, and chained vulnerabilities that matter most. Instead, ZeroPath learns your codebase like a security researcher would, understanding how repositories, services, and dependencies interact.

Learn More & Book a Demo

First, a quick recap

To those of you who didn’t read the original piece, I highly recommend checking it out because it provides a broad overview of the idea foundational to this article. For those that did but need a quick refresher, here’s how I explained it: “…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.” - Source: Competing with layer zero in cybersecurity

The easiest way to understand what it looks like in the real world is to look at who the layer zero providers are:

• In the cloud, it is cloud service providers like AWS, Azure, and GCP.

• In the network, it is networking providers like Cisco and Juniper.

• In the endpoint, it is the OS providers like Microsoft (Windows) and Apple (macOS and iOS).

• In identity, it’s identity providers (IdPs) like Microsoft Entra and Okta.

• In the browser space, it’s the browser platforms like Mozilla (Firefox), Chrome (Google), and Edge (Microsoft).

• In code security, it’s the platforms where the code is created and managed, like GitHub, and most recently Cursor.

In the previous article, I explained the market dynamics and what happens when layer zero providers start offering security (people usually prefer third-party solutions), and when security companies mess with the core business of the layer zero providers (bad idea), among other things. Now I would like to share a few other thoughts on this topic that may make it easier for people to solidify the mental model around this concept.

Every new layer zero creates an explosion of security companies

Layer zero is a pretty dynamic concept because things evolve all the time, and when they do, they create both shifts in infrastructure and the expansion of the attack surface. We talk about cloud, identity, and operating systems as if they’ve always been layer zero, but they weren’t inevitable per se. Instead, they became default control planes because some deeper infrastructure shifts created gravity around them. The explosion of personal computers created the endpoint layer, IP networking created the network layer, virtualized compute created the cloud layer, and the rise of SaaS turned the browser into a delivery mechanism for applications.

Every time a new foundational layer emerges, we see the same pattern when a large number of cybersecurity companies get created to take advantage of that shift. The speed with which it happens varies a lot and is largely dependent on the speed of the underlying infrastructure change. With the cloud, it happened almost overnight; identity took at least a decade to consolidate, and the browser is only now starting to get the recognition it deserved over 5 years ago. With AI, we see many companies making the bet on the fact that AI will become the new layer zero, which is why so much capital is being poured into security for the AI space. Regardless of the specific market segment, the dynamic is the same - when a new control plane forms, security companies chase the surface area around it.

This is why I think of layer zero as a creator of new security markets. When the foundation changes, thousands of new problems appear: posture, visibility, misconfigurations, gaps between old and new workflows, fragmented APIs, and inconsistent policy models. If you zoom out far enough, the 5,000+ cybersecurity vendors today aren’t a sign of market inefficiency; they’re a solid proof that we’ve had dozens of layer-zero shifts over 40 years, and each created its own cottage industry of “missing controls.”

Why layer zero never delivers “enough” security

There’s this idea that if layer zero platforms (endpoint OS, browsers, cloud platforms, etc.) were just built with stronger security controls, we wouldn’t need all the add-ons and point solutions. That’s partially true, but realistically, it’s impossible. Layer zero optimizes for reliability, scale, economics, and user experience, not for the edge cases enterprises run into. Historically, layer zeros weren’t even designed with access controls, logging, or basic security guardrails, and all these were added only after attackers forced the hand of the creators.

Layer zero players build new features with the same structural challenge: they need to serve the entire world with one architecture. Even if they can build some posture, policy, and detection capabilities, these will be weak, shallow, or overly generic. Even after customers get breached by adopting the basic layer, these platforms can’t go deep enough on security. This is partly because it’s not their bread and butter, but also because doing that is often counterintuitive to their business models. Doubling down on security often reduces compatibility, increases support burden, and complicates core workflows, something that makes these players sell less of their core products.

Having seen this story repeat itself several times, I don’t think that if the layer zero platforms shipped their products with much stronger security, it’d solve the problem here either. The bigger the enterprise, the more flexibility it needs in configuring things, and more flexibility always means more misconfigurations. I’d go as far as to say that the majority of security problems are really misconfiguration problems (which is probably why CSPMs and identity automation products have been exploding in growth). That’s why the first security category around every layer zero is always some form of “posture management”, the industry’s ongoing attempt to deal with complexity nobody could have imagined.

The predictable evolution of security around any layer zero

Once a new foundational layer develops, the security around it follows a repeatable evolution pattern:

Step 1: Visibility and posture

Security teams typically don’t have control over whatever is happening in IT or engineering, but they need to know whether the new thing is deployed safely. The earliest successful network tools were scanners, the earliest successful cloud tools were posture managers, etc. This sequence is very important because history has shown that starting with runtime instead of posture for a new layer zero is a mistake. When a new layer zero develops, the attackers need time to understand how to actually exploit it, and there’s rarely enough activity to justify going too deep. People start with configurations, and CSPM is actually a very good example of that in real life when Wiz was able to win the market despite not having all the deep-level controls that some of their competitors did on day one.

Step 2: Threat detection

Once posture is “good enough,” attackers figure out how to bypass it. This is when logging, behavior analytics, anomaly detection, and runtime monitoring come into play. In the cloud, we went from CSPM to runtime detection, and in other areas of security like data and appsec, we’re very much moving in the same direction. It always takes time for people to outgrow posture, and the reality is that that maturity curve is pretty steep, but it happens eventually.

The tricky part here is that the competitive dynamics of the market often forces security products to become more and more sophisticated, but some areas just don’t see attackers move as fast. When this happens, cyber vendors get too far ahead of the actual attacks and end up building detections that are only triggered by false positives. It doesn’t take long for people to get rid of these tools. The bottom line is that step one (posture) is always going to be applicable to every new layer zero, but whether or not the market ever gets to step 2 or 3 depends on many factors.

Step 3: Operations and incident response

Once (and if) detection tools get widely adopted, the alert volume becomes overwhelming to security teams, which drives all kinds of operational improvements like SOC platforms, SIEMs, response automation, etc. These tools are usually built to help humans deal with what I’d define as “human-made” problems, aka all the alerts produced by the tools in phases one and two. This, on its own, doesn’t really lead to the creation of new categories. What creates new categories is when the number of attacks focused on the new layer zero is increasing. At that point, companies typically realize that there’s a pretty big difference between just learning that something bad is happening and actually containing it. As always, we learn that apparently there are not enough people who can respond to this new attack, and that creates room for specialized incident response expertise.

This cycle explains why our industry is repeating the same pattern all over again, and for every new layer zero, we get posture, then detection, and then (sometimes) response tooling. This also explains why the companies that break out attach themselves to a fast-growing, widely deployed layer zero can inherit decades of relevance.

More about layer zero

At the beginning of the article, I mentioned a quick exchange with Bill Phelps. He shared some other points that I think are spot on:

• Maybe this is obvious, but layer zero is where the business process/data lives, and it is what adversaries are attacking. So it is also the ultimate target for pentesting/red teaming. Pentesting and malicious attacks start with a “naked” layer zero, then all the layers on top of layer zero are built to protect it from attack.

• If a company can evolve into a layer zero platform, it can become a public company. I’d expand on this thought and say that another way to go public is to deeply embed into an existing layer zero, but it’s that depth that creates a competitive advantage. CrowdStrike is a good example, and the fact that it needed to go super deep to observe the endpoint is one of the factors that differentiate it from, say, the CSPMs I’ve mentioned that didn’t get to build that deep of an IP.

• It is really hard to achieve scale in cyber if you are not some type of add-on to a dominant layer zero.

All these are great insights, and frankly, it’s the feedback and ideas from the readers that help me refine and expand my own thinking. Thank you, Bill, and thank you to all the readers for supporting my blog years later!

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

This issue is brought to you by… Tines.

Manual evidence collection, scattered tools, and repetitive audits can take a real toll on security and GRC teams. This new GRC playbook, created by Drata and Tines, offers a practical look at how teams are shifting to continuous, automated compliance.

Inside, you’ll find:

• Detailed workflows for evidence collection, monitoring, audit prep, and vendor risk

• Implementation guidance from credential setup to scaling

• Best practices for building resilient, proactive GRC programs

Read the guide now

Top 12 deep dives to understand the cybersecurity market

Why there are so many cybersecurity vendors, what it leads to and where do we go from here

It is common to hear that there are “too many vendors” in cybersecurity, and that “we don’t need 200+ products in the same category doing the same thing”. What is rare is seeing analysis as to why there are so many similar vendors - what is driving the establishment of the new companies, and fueling the cybersecurity gold rush.

In this article, I am looking at some of the factors that lead to the emergence of hundreds of “me too” startups, why relatively few businesses in the industry fail and equally, few win big, and why there are only 18 pure-play cybersecurity companies listed on the US stock exchange.

It’s been nearly 3 years since I published this article but it is as relevant today as it was back then.

20 years of cybersecurity consolidation: how 200 companies became 11

Everyone in cyber likes to talk about consolidation but very few people understand how it looks in the wild. This isn’t a usual article, it’s a lookback at the past 20 years of consolidation history in our industry. Here’s a preview:

12 ways to fail a cybersecurity startup

“Why do startups fail?” is one of the most commonly asked questions among anyone interested in building a startup. At first glance, a lot has been written about this problem. However, wherever I go, I continue to see three things:

• Most of the analysis is based on the consumer startups

• Most of the analysis lacks the context of the cybersecurity industry

• Cybersecurity founders repeat the same mistakes over and over again

For a variety of reasons, both success and failure in cybersecurity look different compared to other industries. In this piece, I offer a guide to failing a cybersecurity startup, highlighting some of the reasons I have seen startups fail, and offering insights and advice to avoid the failure.

Splunk, Okta, Cylance, Palo Alto, CrowdStrike, and Zscaler mafias in cybersecurity

Some companies play an outsized role in shaping the industry: not just because of what they accomplish, but also because of the kind of startups their alumni create. In this piece, I dive into Splunk, Okta, Cylance, Palo Alto, CrowdStrike, and Zscaler mafias in cybersecurity.

This article is a continuation of the series about the cybersecurity mafia networks. I’ve also written about Check Point mafia, the impact of Foundstone, Juniper Networks & Cisco, as well as @stake, NetScreen, IBM, Israel Defense Forces and the US Armed Forces mafia networks in cybersecurity.

Let’s have an honest conversation about the state of cybersecurity

In this piece, I am offering a very direct and real perspective about what I think are the main drivers for companies to spend on security. Spoiler alert - yes, the majority of the companies buy security products for compliance, but there’s much more to this.

Cybersecurity is not a market for lemons. It is a market for silver bullets

In this piece, co-written with my friend Mayank Dhiman, we are looking into the reasons why security is not at all a market for lemons; instead, it is a market for silver bullets. Neither Mayank nor I didn’t come up with this idea on our own. Our article is centered around the analysis of an excellent essay written by Ian Grigg back in 2008 titled “The Market for Silver Bullets”. Since we connect our own ideas to those expressed in Ian’s article, please assume that anything not listed in quotations is our perspective and not that of Ian.

Ian’s essay is a must-read for anyone trying to understand the dynamics of cybersecurity on a deeper level, and we hope this article will inspire many people in the industry to give “The Market for Silver Bullets” a read.

Source: “The Market for Silver Bullets”

The only six cybersecurity markets large VC funds actually care about and why security startups don’t have a moat

At first glance, there are hundreds of important problems that need to be solved in cybersecurity. This, in turn, presents opportunities for thousands of security startups, making the whole security technology landscape look like a bingo card.

The reality, however, is very different. Most security problems are niche, and hence why they simply have no potential to lead to outsized, venture-scale returns. The problems that aren’t niche, tend to follow specific patterns. In this piece, I am taking a closer look at what these patterns are, and what areas of security actually constitute large markets. The short of it is simple: while things change, tech changes, and attackers also change, decades later, the top markets remain the same:

• Network remains foundational despite the fact that many proclaimed that “network is dead”. As companies started to move away from traditional networks, the problems of connectivity and security came up once again. The solution which became known as Secure Access Service Edge (SASE) combined networking and security into one product.

• Endpoint security remains critical for security and ransomware prevention since people still do their work on the workstations the way they did it a decade ago. For better or for worse, ChromeOS is not yet a OS standard heavily used in enterprises, and it’s unlikely to become one anytime soon.

• Identity has truly become the new perimeter, and since access is now based on user and machine identity, the market has exploded.

• Email security remains big because, despite the introduction of Slack, Teams, and other collaboration tools, that is still how businesses communicate with the outside world.

• Security information and events management (SIEM) remains the foundational technology that allows security teams to aggregate, correlate, and analyze data, or in other words, to do their jobs.

One new kid on the block that VCs care about is cloud security:

• As companies started to move to the cloud, cloud security emerged as a new player. Two decades later, we now have players such as Wiz that are centralizing that space.

To solve security problems, you don’t have to build a security company

If you were to ask security founders what they think are the best ways to make companies more secure, they would probably tell you different ideas about getting CISOs to buy new security tools. That’s not wrong per se - CISOs control security budgets, set strategy, and are responsible for the organization’s security posture. This thinking, however, is very limited for a simple reason: some of the biggest improvements in security have come from products that were never sold as “security” at all.

In this issue, I discuss the concepts of security as the product vs. security as a byproduct, and what they mean for founders.

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.

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.

Owning the control point in cybersecurity

In every business function, there are control points - systems that teams rely on the most and that concentrate the most power and influence over operations. In cybersecurity, identifying these control points is critical for understanding where decisions are made, where workflows converge, and where to prioritize investment. Dave Yuan offers a useful heuristic: “If you had to turn off all the systems in your stack, which ones would you turn off last?” The answer to this question is a good heuristic to figure out which platforms are core to the function and which are secondary.

For most cybersecurity teams, the primary control point is their SOC platform, usually a SIEM or XDR. It’s where telemetry is aggregated, alerts are prioritized, and investigations happen. It’s the default interface for day-to-day security work, and often the first system looked at during a breach or audit. While the tools used may vary, nearly every mature team has something in place that acts as the operational center of gravity for detection and response.

Other domains within security have their own control points. Whoever owns the control point, gets an opportunity to build a billion-dollar company.

Explaining the complex world of channel partners in cybersecurity and looking at their past, present, and future

Channel partners are critical for cybersecurity because no company can reach millions of businesses around the world on its own. Establishing and maintaining relationships spanning countries, languages, time zones, and industries is not feasible without reliance on partner networks.

Over the past decade, the world of channel partners has been evolving. In this piece, I am diving deep into this evolution, what it means for the industry, and the future of security.

Enmeshment in cybersecurity: blurring boundaries between products and services

A decade ago, anyone looking to segment and classify cybersecurity companies would first split them into two buckets: products and services. Today, that difference has been disappearing as more and more service providers have been building products, while product companies are now offering services. In the deade to come, I think the line between the two is going to fully disappear.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

The topic I want to touch on instead is how AI has been reshaping the expectations around company growth (spoiler alert: it changed them completely). In this piece, I’ll discuss how AI is changing the trajectory of startup growth, and then I’ll talk about our industry and why I think that, for better or for worse, the vast majority of the cybersecurity startups won’t grow as fast as the new AI companies. I’ve initially wanted to say that “the rate of growth of cyber startups will never match the rate of growth of the new AI companies,” but then someone will always find an example that makes the point seem wrong, even if it applies to 99.99% of the market, so I would rather maintain some credibility and frame that differently.

This issue is brought to you by… Intruder.

30M Domains Later, Here’s What We Found Hiding In Shadow IT

How much Shadow IT can you uncover with only public data? We ran the experiment and the answer was: too much. From backups holding live credentials to admin panels with no authentication, these exposures stay invisible to you but wide open to attackers. Read the research to see what we found and how Intruder helps you find it first.

See what we found

The new $100M ARR growth curve for AI startups

Several months ago, Bessemer published The State of AI 2025 report (if you haven’t seen it, I highly recommend giving it a read). In this report, they discuss the trends in the AI world and put forward some predictions about the coming years. It’s a good read overall, but what stood out to me is the idea that before AI, top companies would on average need ~7 years to reach $100M ARR. In the post-AI world, the amount of time has been shortened dramatically. Today, according to Bessemer, great AI startups (they call them “AI Shooting Stars”) get to $100M in 4 years, and exceptional AI companies, which Bessemer calls “AI Supernovas,” get to $100M ARR in some 1.5 years.

Image Source: Bessemer’s State of AI 2025 report

Image Source: Bessemer’s State of AI 2025 report

These are fantastic numbers. Let’s have a look at a few pieces from the report: “Supernovas are the AI startups growing as fast as any in software history. These businesses sprint from seed to $100M of ARR in no time, often in their first year of commercialization. These are at once the most exciting and the most terrifying startups we see. Almost by definition, these numbers arise from circumstances where revenue may appear vulnerable. They involve fast adoption that either belies low switching costs or signals massive novelty that may not align with long-term value. These applications are often so close to the functionality of core foundation models that “thin wrapper” labels could be thrown. And in red-hot competitive spaces, margins are often stretched close to zero or even negative as startups use every tool to fight for winner-take-all prizes.” - Source: Bessemer’s State of AI 2025 report

“Shooting Stars, by contrast, look more like stellar SaaS companies: they find product-market fit quickly, retain and expand customer relationships, and maintain strong gross margins—slightly lower than SaaS peers due to faster growth and modest model-related costs. They grow faster on average than their SaaS predecessors, but at rates that still feel anchored to traditional bottlenecks of scaling an organization. These businesses might not yet dominate headlines, but they’re beloved by their customers and are on the trajectory to making software history.

On average, these Shooting Stars reach the ~$3M ARR range within their first year of revenue while quadrupling in YoY growth with ~60% gross margins, and ~$164K ARR / FTE in their first year.

If T2D3 (triple, triple, double, double, double) defined the SaaS era, then Q2T3* (quadruple, quadruple, triple, triple, triple) better reflects the five-year trajectory we’re seeing from today’s AI Shooting Stars. These startups grow meaningfully faster than traditional SaaS, but still operate closer to SaaS benchmarks than the explosive AI Supernovas.” - Source: Bessemer’s State of AI 2025 report.

Overall, I think this report does a great job outlining how building software companies is different today compared to some 2-3 years ago. At the same time, for me, it raised a lot of questions, the biggest of which is “So… what does this mean for cyber?”.

Cyber startups in the age of AI

AI changes the speed of shipping products, but not so much the speed of GTM

Paraphrasing Dave DeWalt a bit, in cyber, product is the game of inches, but GTM is the game of miles. This has been the case five years ago, and whether you like it or not, it’s even more the case today. The most technologically superior products rarely win against better distribution (for once, that’s why startups often struggle where large vendors just bundle new capabilities into their platforms).

AI has, without any doubt, made it faster for companies to ship new products, faster to iterate, and faster to learn what works and what doesn’t. However, in cyber, shipping features quickly hasn’t been a problem (for once, Israeli startups have figured that out). Growth in our industry is all about distribution, and distribution, in turn, is all about trust.

Security moves with the speed of trust, not the speed of shipping new features. Interestingly enough, as AI is accelerating the speed of shipping new features, it’s actually slowing down the speed of trust, so POCs can become longer. Enterprises are questioning how exactly AI is being used, what it will do with their data, and so on, and getting the answers only extends the amount of time it takes for startups to close deals.

Some security startups may become “AI Shooting Stars,” but the majority will remain in that “Cloud Centaur” spot

Let me first say that ARR is a funny metric these days, as some companies in our industry have been rumored to be pretty creative about how they define it, allowing them to boast numbers far higher than the amount of money that was flowing into their bank accounts. The peculiarities of the non-GAAP term “ARR” aside, the fact of the matter is that security revenue isn’t often a flywheel. Enterprise sales (and most cyber companies sell to enterprises) are a slog, with sales cycles often spanning more than 6-12 months. It’s pretty hard to become an “AI Supernova” when the POC is going to take 9 months, and the first purchase may come from the “innovation budget”.

I have no doubt that some security startups will indeed be able to move through procurement faster. And yet, (and I am sorry for having to say this), it most likely isn’t going to be because of AI. At the end of the day, AI-powered vulnerability management is probably going to go through the same procurement cycle (plus even more checks and steps) as vulnerability management, and AI-powered SIEM will most likely go through the same process as a regular SIEM. From what I’ve seen and from what I know, AI-native companies do often offer superior experience, and some problems that can now be solved with the help of AI were previously completely unsolvable. And yet, procurement teams are still taking them through the same series of steps as before (and then some).

Then there’s the fact that many security products don’t need AI. Ironically, for non-AI companies, it may take less time to get through the POC compared to their AI-native counterparts. The bottom line is that while some security startups may become “AI Shooting Stars”, the majority will remain in that “Cloud Centaur” spot. They will still be growing, they will still be durable businesses, and they’ll often still have fantastic exits, but they’ll look different than these “AI Supernovas,” which brings me to one of the most interesting points of this article: venture capital.

It’s not that security startups are bad investments; they’re just different

It’s not that security startups are bad investments; they’re just different, and these differences are structural. Security is slow because, by its very nature, it is about reducing risk, and everything new is risky. Trust always decides the pace in cyber. For those interested in this topic, I previously wrote several deep dives about trust in security, including Why there are so many cybersecurity vendors, what it leads to and where do we go from here and Time to trust: what it is, why cybersecurity startups must shorten it to accelerate growth, and how to do it.

Growth in security is slow, and it requires a lot of patience. Take, for example, Zscaler, which recently celebrated crossing $3B ARR - an astronomical number for most cyber companies. What most people don’t realize is that it took Zscaler 10 years to get to $100M in ARR, and then just 5 more to $1B in ARR. A decade to $100M ARR is surely not an “AI Supernova,” but nobody is going to argue that Zscaler is not a huge success. CrowdStrike, founded in 2011, did $250M ARR in 2019, during the year it went public (it took them 8 years to get to that number). Today, 6 years later, the company’s ARR reached $4.66B. These numbers show that growth in security is about consistency, hard work, and the compound effect of trust. It is not about growth hacks or marketing gimmicks; it’s about continuous value delivery and discipline. Companies that went for something else (rapid scaling, etc.) have historically struggled to build lasting business.

Subscribe now

I think we’ll see more generalist VCs leaving security

Over the past decade, cybersecurity has become one of the hottest categories in tech from a VC standpoint. In just the past year alone, we’ve seen massive outcomes, from Wiz’s acquisition to the recent CyberArk deal, along with a steady stream of smaller but solid exits. Naturally, every VC watching these big M&A moments wishes they had been an early investor in Wiz. And for a while, they all acted like they were chasing the next one. Until now.

You see, Wiz is still just one company. It’s an outlier. Although VCs like to say that they are into betting on outliers, the majority want to see a path of how their investment is going to become that one in a thousand. In cyber, that can be pretty hard. Security does have great stories (Palo Alto, Zscaler, Cloudflare, CrowdStrike, and you name it), but it’s not an easy market to make sense of, especially in a world where there seems to be an easier path.

For cyber VCs, making investment decisions is simpler because their freedom of choice is pretty limited (after all, they’ve committed to their LPs that they’ll be investing capital precisely in security). Sure, they can get creative and count some drone startups as “security”, or some anti-fraud solution, or maybe even AI voice startups if they try really, really hard. Outside of that, they have to allocate capital in the industry they’ve committed to. Most importantly, they know well that for those who understand what they’re doing, slower growth in cyber doesn’t mean less potential for fantastic returns.

Generalist VCs operate under a different set of incentives. They aren’t bound to a specific vertical, and even their “specialties” tend to be broad, like SaaS, fintech, enterprise software, AI. So let’s bring back that Bessemer stat about hitting $100M ARR in 1.5 years. Now imagine a generalist VC evaluating a fintech startup with $5M ARR after 10 months versus a cybersecurity startup that’s been selling for a year and a half and is on track for $1.7M ARR. In the cybersecurity world, $1.7M at that stage is considered very good, sometimes exceptional. But when compared side-by-side with a fintech startup sprinting at 3x the revenue in less time, a generalist VC isn’t likely to be impressed. It’s not ignorance; it’s just rational portfolio decision-making. Faster growth in a bigger category is hard to argue against.

If the current trend continues, I think it’s going to drive a lot of the tourist VCs out of cyber because they just won’t be able to justify investing in “slower-growing” security companies over all these “AI Supernovas” with $10M-40M ARR after one year. Looking at this chart from Bessemer, cyber is most likely gonna stay as “Cloud Centaur” by default and by design, with few companies getting into the “AI Shooting Star” category as exceptions rather than the new norm. The cyber specialists VCs who understand the space and who underwrite deals with a good idea of how different markets evolve, I think, will not only stay but will continue to generate great returns. At the same time, I fully expect the interest from generalist VCs to dry up as they’ll continue to struggle with how to compare what’s by the new standard, “an average-looking company,” to the AI superstars.

Looking into the future

Predicting the future is never easy, but sometimes the writing is on the wall. Unless security budgets keep expanding indefinitely, and unless security buyers suddenly become less risk-averse (neither of which seems likely), security startups will struggle to compete for VC attention against the new wave of AI companies. The contrast is becoming increasingly stark as more AI-native startups report record-breaking ARR numbers. Yes, some of those figures are inflated, and many of these companies will collapse as fast as they raise, but the impact of AI across industries appears real, and so is the competition it introduces.

For now, there’s still plenty of capital flowing into security startups, but it’s likely to get harder soon. As strange as it sounds, that might actually be healthy for the industry. Once the “tourists” lose their enthusiasm for cyber, the VCs who truly understand security, and who spend real time with security buyers, should find their jobs easier. It becomes a kind of natural selection: companies solving real, urgent problems will endure, while those built on hype or weak signals will inevitably struggle.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

Share Venture in Security

In this piece, I am doing a deep dive into the aspects of that great article that are most relevant to security. First and foremost, there’s the fact that nobody ever gets credit for fixing security problems that never happened. This has serious consequences for security teams and startup founders alike, as it effectively defines what initiatives (or products) are likely to be doomed from the start. It also answers many other questions, like why we blame people and not processes, why people are conditioned to work harder instead of working smarter, and why we love shortcuts even if the long-term impact of taking them can be pretty bad.

This issue is brought to you by… Intruder.

30M Domains Later, Here’s What We Found Hiding In Shadow IT

How much Shadow IT can you uncover with only public data? We ran the experiment and the answer was: too much. From backups holding live credentials to admin panels with no authentication, these exposures stay invisible to you but wide open to attackers. Read the research to see what we found and how Intruder helps you find it first.

See what we found

Working harder vs. working smarter

Nelson and John, authors of the IEEE article, explain in very simple terms why security teams, similar to other functions, get stuck in the endless cycle of firefighting.

The idea here is simple. Security teams spend all their time dealing with incidents, tickets, and alerts - all the stuff that causes the well-known fatigue. Everything is on fire, the amount of work is overwhelming, and it’s impossible to ever reach a point where the team has time to pursue more strategic initiatives. Because the teams are bogged down doing all this manual, repetitive, low-value work, they never get the time to prioritize investing in foundational hygiene, architecture changes, or resilience. This creates a vicious cycle: the more they firefight, the more fragile the system becomes, and the more fragile the system, the more they need to firefight to keep it from falling apart.

Nelson and John explain that the core reason for this is that working harder leads to immediate performance improvements. The more time and effort people dedicate to work, the better the results. Moreover, the improvement is immediate, and it’s easy to measure. The problem is that the benefits of working harder are pretty short-lived. As less time is spent improving processes, the capabilities slowly worsen, and eventually hit the point when simply working more won’t achieve much. This is why the authors describe working harder as “better before worse”: at first, working harder leads to immediate improvements, but over time, things get worse.

The so-called working smarter approach is the opposite. When the company decides to prioritize some larger-scale improvement initiatives, in the short term, things slow down because people are distracted by all the improvements and can’t work as hard on their day-to-day operational tasks. Eventually, however, the capabilities & the level of maturity increase more than enough to compensate for the initial productivity losses, and security teams become much more effective long-term. The article authors describe this as a “worse-before-better” dynamic.

We see how these things play out in the real world all the time. Foundational work like inventorying all assets, refactoring IAM, redesigning network segments, documenting architectures, and implementing zero trust initially slows everything down, and it can be hard to see how it can immediately reduce incidents. Over time, however, it is these operational improvements that give security teams superpowers and make them more effective, efficient, and productive in the long run. Since most people aren’t comfortable with the initial productivity dip that comes with working smarter, they prefer to focus on initiatives that lead to an immediate visible bump in productivity, even if, long-term, they’re actually less effective.

Image Source: California Management Review

Good security is destroyed by shortcuts

It can be said that good security is destroyed by shortcuts, not just those of people across the organization, but also shortcuts that security teams themselves are taking.

When security teams are pressured to do more with less time, they have to cut corners, and what naturally suffers are things that feel less urgent, like improvement initiatives, documentation, maintenance, and root-cause analysis. On one hand, this is understandable because in the short-term, taking this path can enable security teams to accomplish more in other areas and go heads-down on some operational day-to-day tasks. In the long term, they end up paying for these luxuries. Skipping threat modeling, not patching fully, ignoring IaC misconfigurations, not cleaning up IAM exceptions, and postponing other foundational work creates invisible long-term risk that adds up and eventually blows up in somebody’s face.

Here’s how authors of the article explain this phenomenon: “Shortcuts are tempting because there is often a substantial delay between cutting corners and the consequent decline in capability. For example, supervisors who defer preventive maintenance often experience a “grace period” in which they reap the benefits of increased output (by avoiding scheduled downtime) and save on maintenance costs. Only later, as equipment ages and wears do they begin to experience lower yields and lower uptimes.[...] Similarly, a software engineer who forgoes documentation in favor of completing a project on time incurs few immediate costs; only later, when she returns to fix bugs discovered in testing does she feel the full impact of a decision made weeks or months earlier.”

Power of the attribution error

Our industry is a prime example of what psychologists call the “fundamental attribution error”. Here is how the authors of the article explain this phenomenon.

“Suppose you are a manager faced with inadequate performance. Your operation is not meeting its objectives and you have to do something about it. [...] You have two basic choices: get people to work harder or get them to work smarter. To decide, you have to make a judgment about the cause of the low performance. If you believe the system is underperforming due to low capability, then you should focus on working smarter. If, on the other hand, you think that your workers or engineers are a little lazy, undisciplined, or just shirking, you need to get them to work harder.

How do you decide? Research suggests that people generally assume that cause and effect are closely related in time and space: To explain a puzzling event, we look for another recent, nearby event that might have triggered it. People also tend to assume each event has a single cause, underestimate time delays, and fail to account for feedback processes. How do these causal attributions play out in a work setting? Consider a manager observing a machine operator who is producing an unusually high number of defects. The manager is likely to assume that the worker is at fault: The worker is close in space and time to the production of defects, and other operators have lower defect rates. The true cause, however, may be distant in space and time from the defects it creates. Perhaps the defect is actually the result of an inadequate maintenance procedure or the poor quality of the training program. In this case, the delay between the true cause and the defective output is long, variable, and often unobservable. As a result, managers are likely to conclude that the cause of low throughput is inadequate worker effort or insufficient discipline, rather than features of the process.”

We see this in security all the time. Security teams say that breaches happen due to user errors because users “are dumb, not security-conscious, ignore policies, and can’t stop clicking on links,” instead of the system (overload, bad processes, etc.). On their part, company executives blame breaches on “bad security teams” instead of on systemic issues like chronic underinvestment, technical debt, complexity, and lack of automation.

The cycle of firefighting creates a hero culture

The fact that security teams are stuck in firefighting mode, and only relatively few are able to buy themselves time and space to prioritize strategic initiatives focused on working smarter, not harder, leads to serious consequences. Here’s what Nelson Repenning and John Sterman saw in their experience:

“As organizations grow more dependent on firefighting and working harder to solve problems caused by low process capability, they reward and promote those who, through heroic efforts, manage to save troubled projects or keep the line running. Consequently, most organizations reward last-minute problem solving over the learning, training, and improvement activities that prevent such crises in the first place. As an engineer at an auto company told us, “Nobody ever gets credit for fixing problems that never happened.” Over time, senior management will increasingly consist of these war heroes, who are likely to groom and favor other can-do people like themselves. As described by a project leader we interviewed, “Our [company] culture rewards the heroes. Frankly, that’s how I got where I’ve gotten. I’ve delivered programs under duress and difficult situations and the reward that comes with that is that you are recognized as someone that can deliver. Those are the opportunities for advancement.”

Reading this makes it clear that while security is certainly not the only place where people struggle to buy themselves time and space to work smarter, not just harder, it is surely a good example of this phenomenon.

Generally speaking, it is pretty rare to see security teams that are given enough power in their organization to implement preventative controls and prevent problems from happening. Prevention means friction, so it’s not only that “Nobody ever gets credit for fixing problems that never happened”, but it’s also that nobody can afford to introduce more friction.

Stuck in circumstances when they don’t have enough control, enough resources, and enough support, it’s no wonder that security professionals often fall victim to the so-called hero culture. It’s honestly hard to blame them: after all, most security people are trying to do their very best with the little support and resources they’ve got. If you are interested in learning more about hero culture and how it manifests itself in security, I recommend reading a piece Kymberlee Price and I published nearly 2 years ago, titled Hero culture in cybersecurity: origins, impact, and why we need to break the toxic cycle. (Spoiler alert - it’s as relevant today as it was two years ago).

Putting all this together

One of Venture in Security’s readers, Michael A. Davis, once left a comment under one of my other articles where he explained the consequences of the topics I am discussing here better than I ever could. He said: “What if this isn’t unique to cyber but is how ALL organizations handle prevent vs. react? I think the same dynamics appear in manufacturing (specifically quality control), healthcare (preventive medicine), and construction/infrastructure (the maintenance vs. repair cycle).

The pattern seems to be:

1. Organizations get trapped in firefighting mode because that’s what’s visible and rewarded.

2. First movers try to sell the organization that they should “work on tomorrow’s problems” to teams drowning in today’s crises and issues.

3. Only external forces like breaches or regulatory mandates create enough pain to break the cycle.

4. Second movers arrive just as the market tips from “theoretical risk” to “urgent need”.

This is a pretty good summary of what’s happening. The only thing that I would add is that while historically, preventative security products have had a harder time than those that are more detection and response (aka firefighting)-focused, in recent years, prevention is starting to get a good amount of traction. Not only are we seeing a new generation of companies emerge, including startups like BforeAI, Aryon, and R6 Security, but even Gartner seems to be putting forward the idea of “preemptive cybersecurity”. Time will tell if we’ll be able to overcome the organizational inertia traditionally associated with preventative and preemptive security measures, but I think when many smart and stubborn people take a shot at something, it’s generally a good sign.

Source: Gartner

This isn’t all about getting a new Gartner category for preemptive security. I think it’s much more about giving security teams permission to prioritize working smarter, getting ahead of the issues, planning for the future, and finding time to pursue the large-scale initiatives every security team I know would like to find time and resources for. It’s about hygiene and a mindset of preventing issues from happening, much more than specific products or product categories.

Looking into the future

It’s been over 20 years since Nelson Repenning and John Sterman published their article, where they explained that nobody ever gets credit for fixing problems that never happened. They were talking about how businesses in general approach decision-making. While none of this was about security, our industry only amplifies the problems seen in other areas of business.

In the coming years, I hope that more security leaders will get the trust credit and political capital to advocate for prioritizing working smarter in their organizations. I see so many CISOs trying to do the right thing but running into internal obstacles that I have no choice but to be optimistic that things will get better. I am also hopeful that we will be seeing more startups coming up with ideas that reinvent old problems and find modern solutions, not merely automating and codifying the old, ineffective ways we have always been doing things. This is the same problem that Tomer Weingarten described as thinking incrementally in our recent episode of Inside the Network. We can all do better as an industry, and I do not doubt that we will.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Subscribe now

Share

Share Venture in Security

This issue is brought to you by… Intruder.

As AI Enables Bad Actors, How Are 3,000+ Teams Responding?

Shadow IT, supply chains, and cloud sprawl are expanding attack surfaces - and AI is helping attackers exploit weaknesses faster. Built on insights from 3,000+ organizations, Intruder’s 2025 Exposure Management Index reveals how defenders are adapting.

• High-severity vulns are up nearly 20% since 2024.

• Small teams fix faster than larger ones - but the gap’s closing.

• Software companies lead, fixing criticals in just 13 days.

Get the full analysis and see where defenders stand in 2025.

Download the Report

Incentives define how different departments prioritize security

If you read Verizon DBIR, CrowdStrike report, or any of the other credible, regularly produced reports about the root causes of breaches, or even if you simply follow the news, you’ll notice a consistent pattern:

1. Most breaches aren’t caused by some novel technology like AI or blockchain, nor are they the result of mysterious, never seen before zero-days.

2. The vast majority of security problems are not really security problems; they are problems that originate in other types of organizations and introduce security risks.

To put it differently, the vast majority of all the breaches happen because of some basic and boring problems. Someone forgot to change the password. Someone wasn’t able to track all the assets in a centralized system. Someone decided to grant a contractor more permissions than they needed, but forgot to revoke access when the contractor left. This list can go on and on, but the fact that matters here is that most of the time, what gets companies breached is something the security team can’t fix on their own. It is what my friend Yaron Levi calls “lack of operational discipline”.

None of this is rocket science, and anyone who has worked in security for over a year gets this. And yet, it still amazes me how often security professionals insist that things should be different, i.e., that engineers should care more about secure coding, that IT should prioritize access hygiene, that teams should think about security by default. The question that usually gets lost is Why should they? Why should any of this be true if nobody in the organization is appropriately incentivized to think about security? There’s the adage saying that “What gets measured, gets done”. To put it more bluntly, people will do what they’re incentivized to do.

A simple way to understand incentives is by looking at 2 things: what gets people promoted, and what gets them fired. At the highest level, the answer to both these questions is tied to organizational goals and key performance indicators (KPIs). Software engineers and product teams are incentivized to ship fast. Anything that hurts their ability to achieve this objective (extra design reviews, extended testing, and yes, lengthy security reviews) - all of that becomes an obstacle to be avoided. IT teams live in ticketing systems and are incentivized to close as many tickets as possible as quickly as possible without making people annoyed. Every IT support request (grant access to X, enable Y, open a connection to Z) means that there is a person in an organization who is looking for something, and they want it to happen yesterday. Everything is urgent, everything is on fire, everything has been requested by the manager, and everything needs to happen without any delays. Unsurprisingly, IT is incentivized to close the ticket as soon as possible and to immediately move to another (also urgent) request.

Every department has its own KPIs, and guess what, there’s only one team that gets measured on risk reduction, so it’s no wonder that, within most organizations, the only executive truly incentivized to care about security is the CISO. Until secure behavior becomes a part of everyone’s performance reviews, alongside execution, teamwork, and communication skills, this is not going to change.

Incentives define how different companies and industries prioritize security

The problem of incentives is even more apparent once we look outside of individual security teams and at the industry at large.

Every now and then, the whole industry gets excited about some new grand idea. Several years ago, it was about SBOMs, and as recently as a few months ago, it was about signing the Secure by Design Pledge by CISA (there are now 328 companies that have signed it). Obviously, I think Secure by Design Pledge is a good initiative; after all, it raises awareness that it’s important to think about security ahead of time, or as they say, designing security instead of bolting on security later. At the same time, thinking that an initiative like this is going to lead to any real consequences means not understanding how incentives work. To be clear, this has nothing to do with CISA or any of its programming; the problem is, once again, incentives.

I’ve talked about this before. When a company is just starting, it’s generally a few people in a garage, so all focus is on figuring out what to build and what direction to pursue. Obviously, thinking about security at this stage would be ridiculous: when the chances are 90-99% or higher that the whole venture will fail within a few months, the biggest risk isn’t a security breach, it’s not finding the right entry point. Let’s say the founders got this right and they were able to survive. From this point onward, the pressure only increases. The next challenge is getting to product-market fit (most startups never get there, so prioritizing it is paramount to company success). When the company has a product and zero customers, the number one priority isn’t to make the product secure; it is to get that first customer. Then the second, then the third, and on and on until the few lucky startups that get to survive and get to the growth stage are fully focused on growth. At no point in the company journey is security the number one priority.

Secure by design sounds great because, in theory, every company should indeed be making sure that its products are secure by design. In practice, security often slows business down, and in a world that prioritizes speed and execution over anything else, putting security first is never going to be easy. This is how, once again, incentives kill security, not just on the company level but also on the industry level.

Not getting incentives right can kill a security startup

For security leaders and practitioners, understanding how incentives work in our industry can help increase the success of security initiatives. After all, when security initiatives fail, it’s rarely because the tech isn’t there or because CISOs haven’t tried hard enough. Most security initiatives that fail fail because of misaligned incentives. A good example is the “shift left” movement, which failed because developers were never incentivized to own security. No security champions program can make developers prioritize security over velocity when they get promoted for the latter, not the former.

For cybersecurity startup founders, misunderstanding incentives can be the difference between building a successful company and a company that fails to get adoption. Many startups fail because they assume that different departments inside the company will care more about security than they actually do. This is especially the case for large enterprises that most security startups go after to begin with. The larger the company, the less likely it is that IT, infrastructure, or engineering will ever pay for, or be excited to implement a product, the primary value proposition of which is security. I have previously explained that to solve security problems, you don’t have to build a security company, and that the only way IT and engineering teams will buy a security product is if that product offers security as a byproduct of a different value prop they do actually care about.

Image source: Venture in Security

It’s not enough to understand organizational incentives and how different teams fit into the picture. I’ve also met founders trying to pursue large, ecosystem-level initiatives that also run into challenges with incentives. Every once in a while, someone with a great vision puts forward an idea of sharing threat intel or collaborating on detection data, only to learn that there are misaligned legal incentives (companies don’t want to expose breaches, spend time sharing data, or are afraid of accidentally sharing something that can be traced back to them). Many visionary ideas were killed by the realities of how legal liability, insurance, and other concerns make companies behave. What sounds like an obvious idea at a BSides talk oftentimes is simply not possible because of how the incentives work.

Looking into the future

Those who know me on a personal level can tell you that I am an optimist (and it’s not just because I wrote a manifesto of a security optimist). And yet, even I am struggling to see how, without radically shifting incentives, we can change the way security works. A lot needs to be done there, both on the organizational and industry levels. Some things generally evolve on their own, but incentives rarely do until something major happens.

I don’t think I have a good perspective on what can be done to change the way companies and society as a whole treat security. All I can hope is that the work we do as startups will make a small dent and help companies that care to improve their security.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share Venture in Security

Share

Subscribe now

What most in the industry don’t realize is that behind every successful security company is a software engineer you’ve never heard of. Palo Alto, Zscaler, CrowdStrike, Cloudflare - all these and most other security companies have people who envisioned, architected, and built their platforms without becoming widely known, and even without holding the CTO title. In this piece, I am sharing some of their stories.

This issue is brought to you by… Intruder.

As AI Enables Bad Actors, How Are 3,000+ Teams Responding?

Shadow IT, supply chains, and cloud sprawl are expanding attack surfaces - and AI is helping attackers exploit weaknesses faster. Built on insights from 3,000+ organizations, Intruder’s 2025 Exposure Management Index reveals how defenders are adapting.

• High-severity vulns are up nearly 20% since 2024.

• Small teams fix faster than larger ones - but the gap’s closing.

• Software companies lead, fixing criticals in just 13 days.

Get the full analysis and see where defenders stand in 2025.

Download the Report

Software engineers turn a vision for security into a reality

I am well aware that when security professionals hear that software engineers are going to be defining the future of security, they quickly tune out, thinking, “Well, this idea hasn’t worked well for us in the past”. The whole “shift left” movement has failed everywhere except for the world’s most mature and tech-forward companies (and even there, the reality is rarely as awesome as BSides talks suggest). The idea that software engineers are going to get excited about doing security work has proven to be, at best, overly optimistic and, at worst, a somewhat delusional fantasy.

I am not here to argue that this is about to change. Instead, I want to talk about something else: the role software engineers play in defining the very direction of the security industry itself. In all these conversations about “developers using AI to generate vulnerable code”, what often gets missed is that the very same software engineers are also the ones building the solutions that define how security gets done.

If you agree that companies like CrowdStrike, Palo Alto, Wiz, and Zscaler have done a decent job solving real enterprise problems, then you have to also acknowledge that the vast majority of these companies weren’t built by a bunch of security engineers. Now, I know there will always be people eager to comment that security vendors aren’t truly making any difference, but that’s not the point I’m making here, and I think we can agree that uninstalling antivirus software and replacing password managers with a single password won’t make us more secure. While founders and CEOs often get the credit for the vision and execution, not nearly enough is said about the engineers who turn that vision into reality. That is to me what matters, and that’s what I want to focus on.

Technical visionaries behind top security companies often remain unknown

What I find really interesting is that the majority of the brilliant minds behind the world’s largest security companies remain unknown. How many people know Yuming Mao, Chief Architect and one of the co-founders of Palo Alto Networks? He served as Chief Architect and a Distinguished Engineer at Juniper Networks, which he joined through the acquisition of NetScreen, but I was barely able to find one picture of him on the internet. How many people know Fengmin Gong, who worked with Nir and Yuming and led the conception, architecture design, and implementation of the appID/threat engines in the next-gen app-aware firewall? It’s fascinating how big a role brilliant Chinese engineers played in the early days of Palo Alto, yet history has largely lost their names.

Similarly, most of the people in security have never heard of Alex Ionescu, a brilliant technical powerhouse who served as CrowdStrike’s founding Chief Architect and Vice President of Endpoint Engineering. Early employees of CrowdStrike will tell you that there would be no Falcon as we know it without Alex Ionescu, but he doesn’t often talk about his story. Having left CrowdStrike in 2021, Alex came back in early 2025, which is most likely not a coincidence given what the company had been through a few months before he rejoined.

Another software engineering powerhouse behind one of the most valuable security companies in the world is Zscaler co-founder Kailash Kailash. In the case of Kailash, there’s actually quite a bit of information about him online, as Jay, Zscaler co-founder & CEO, always credits him with all the technological brilliance. Here is how Kailash himself talks about the origins of Zscaler, which was formerly known as SafeChannel: “It was during dinner at Jay’s house when he first proposed the idea of a cloud security platform. After we spoke, I was so convinced that this is the future, but the problem wasn’t easy to solve from a technology standpoint, and it hadn’t been done. After four months of development, discussion, and lots of trial and error, it seemed that we had a viable solution.”

The truly tragic story that few people in the industry know is what happened to the brilliant technologist behind Cloudflare. While today most know Matthew Prince (CEO) and Michelle Zatlyn (President), three people started Cloudflare. Lee Holloway, Cloudflare’s third co-founder and the technical genius who architected the platform and recruited and led the company’s early technical team, stepped down from Cloudflare in 2015, suffering a truly tragic form of dementia when he was only 36 years old. Wired discussed this story (there’s also this 2-minute video), but given how tragic it truly is, it is not surprising that there is no good place to talk about it.

All these stories are just examples that illustrate the core point of this piece: that every great security company was built by incredible engineers. In some cases, the main founder and CEO is that engineer, but in the majority of cases, they are not. Even if we don’t always know the names of technical geniuses behind each platform, there is always someone, and it’s usually a team, not a single person.

Israel wins in part because of its pool of software engineers who know security

There are many reasons why the Israeli security ecosystem has exploded in the past number of years - the continuous pipeline of great security talent, the culture of risk-taking, and the presence of value-add capital. All that is true. However, I think a large part of Israel’s success is its large pool of software engineers who understand security.

The United States arguably has much more security talent than Israel, which makes sense given the population. However, there are relatively few software engineers who combine 3 attributes:

• Having a background in software engineering and experience building customer-facing products

• Having experience, understanding, or passion for security

• Having experience working at a startup or otherwise shipping products 0 to 1

Each of these attributes matters.

In the US, there are plenty of security engineers, and while many are great at writing automation scripts, connecting different tools, or even building some internal tools, the majority of them don’t have experience building products. But building products is a different discipline altogether because it requires thinking in terms of systems, scale, and user experience, not just functionality. Product engineering means understanding how to design for reliability, performance, onboarding, and long-term maintenance. It’s about solving a problem, not just once for your team, but for thousands of organizations with different architectures, constraints, and use cases. Product building demands a blend of creativity and rigor that extends beyond security expertise. It’s one thing to secure an environment; it’s another to build the platform others will depend on to secure theirs. This is why every successful security company has needed great product engineers alongside security domain experts (domain experts make sure that the product solves the right problem, and software engineers translate that domain knowledge into tools that scale).

At a startup, people need to be able to cut corners and to know which corners to cut. It’s a compromise between designing for scale, but also shipping something quickly, because without quick iteration, that scale will most likely never come. This is why startup experience also matters a lot. Many great software engineers who understand security in the US work at large enterprises like Microsoft, Google, AWS, Cisco, or even agencies like the NSA, but what makes an engineer successful working at Cisco is very different from what makes an engineer great at building products at a startup. Let me be clear: a person who has worked at any of the big companies can be a great fit for a startup, but someone who has only worked at big companies for a decade or longer is less likely to successfully adapt.

Lastly, either expertise or passion for security matters a lot as well. Sure, security is just another domain, and the vast majority of engineers are domain-agnostic. That is true, but security does require people to go a bit deeper, and if an engineer has absolutely zero interest in immersing themselves in that depth, they’re less likely to be successful.

Israel has created a fantastic pipeline of software engineers with experience working at startups and a strong passion for security. That’s one of their secrets, and to replicate their success, we have to replicate that.

Closing thoughts

I am sure I am biased. As an early-stage founder, hiring great engineers has been my main focus lately, so I’ve spent a lot of time thinking about what “great engineering” even means in the age of AI. While I read about companies trying to replace engineers with AI agents, my co-founder and I have been doubling down on the opposite bet: that the real breakthroughs will come not from AI itself, but from the best engineers who know how to use AI to get even better. It’s really bizarre to me that this is a contrarian idea in 2025, but there we are.

For people in the security industry (CISOs, security engineers, etc.), my message is simple: recognize that software developers aren’t just introducing vulnerabilities, they’re very much building the future of our industry, just as they’ve done in the past. Every breakthrough in cyber, be it endpoint or cloud security, has been built through the hands of software engineers who took ambitious visions and translated them into working products.

For founders, the lesson is also pretty clear: think of AI as a tool for engineers, not as a replacement. Hire great engineers and give them what they need to do their best work - autonomy, support, recognition, and an environment surrounded by other brilliant minds. Sure, give them the latest AI tools, but equally (or I’d argue even more) important, create room for real ownership, and make sure their impact is visible and rewarded.

Lastly, if you’re an engineer passionate or curious about security, or someone who wants to work on hard, foundational problems that matter, I’d love to connect. Not only because I’m hiring, but also because I know many other founders looking for great builders.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share Venture in Security

Share

Subscribe now

For this conversation to make sense, I think we need to separate two lines of thought: what AI enables for customers, and what AI solves for startups. These are two very different conversations, and while I want to focus the article on the latter, it won’t fully make sense if I don’t briefly address the former.

This issue is brought to you by… Harmonic Security.

Early Access Open: MCP Gateway with Intelligent Data Controls

Agentic AI is moving fast and most teams have no visibility into what’s actually happening.

Harmonic’s MCP Gateway changes that.

It’s a lightweight, developer-friendly gateway that gives security teams visibility into MCP usage and the ability to set real controls, blocking risky clients or data flows before something slips through.

We’re opening early access to a limited number of forward-leaning security teams. Request early access for your team here:

Request Early Access

For customers, AI is transforming how security is done

Over the past year, it has become clear to me that AI is already transforming how security is done. Now, this is not because LLMs are perfect at detection, or that AI has no gaps (they aren’t, and it does). A much more important reason why I am bullish on the opportunities this wave of AI unlocks is simple. Well over 90% (and some people would even say 95-97%) of security teams’ day-to-day is not some advanced incident response or dealing with nation-states. Most of the security teams’ work has nothing to do with chasing advanced adversaries. Much more than that, it’s boring, mundane stuff like:

• Updating reports and dashboards for leadership

• Collecting screenshots and evidence for audits

• Responding to repetitive access and compliance requests

• Reconciling data across tools and systems

• Investigating low-priority alerts that never amount to much

• Documenting findings and closing out endless tickets

I previously wrote a dedicated deep dive about this if you are interested in reading more: Most of the security teams’ work has nothing to do with chasing advanced adversaries.

The main point here is that all this manual stuff is exactly the kind of work that lends itself to automation opportunities, and where AI agents can make a lot of difference. As an industry, I think we should be excited to use AI to streamline or eliminate the time-consuming but necessary work, and buy ourselves time to focus on the high-value work that we simply can’t get to. This is what scaling security teams means and I am very optimistic about the opportunities this creates, for both enterprises and startups.

The impact of AI for security startups is trickier to evaluate

When it comes to what AI enables for security startups, my opinion diverges from a lot of the stuff I read online. I’ve seen some people suggest that AI makes it possible to quickly validate demand, to radically shorten time to market, and even to avoid having to hire senior engineering talent. Some even think that enterprises will replace all of their expensive SaaS subscriptions with homegrown agentic solutions. I don’t quite agree with either of these statements.

AI doesn’t really make it significantly easier to validate demand in security

I am a huge fan of AI prototyping tools (V0 is one of my favorites, but if you have suggestions for even better ones, I’d love to hear them). Prototyping makes it possible to iterate on designs in minutes and to generate good enough working prototypes for testing with prospects. They are fantastic. So why do I then say that AI doesn’t really make it significantly easier to validate demand in security? The answer is pretty basic: because getting feedback about prototypes is pretty far from real demand validation.

I recently wrote an article titled The real dilemmas of cybersecurity startup ideation, discovery, and validation where I expanded on some thoughts shared online by Stephen Ward and referenced an amazing illustration of the ideation journey he shared on LinkedIn.

Image source: Stephen Ward

What I am talking about here is different. It is more about the fact that real validation in B2B only really comes when someone is writing a check. Ideally you want this someone to not have any incentives to be doing this, aside from wanting to solve a painful problem at their company.

People will always be willing to share their perspectives, and having a visual illustration of an idea is very, very important. AI prototyping tools can help gather feedback, learn about the problem, and even plan what capabilities should be prioritized first based on user feedback. The one thing prototypes do a poor job at is validating that someone is going to pay real money (based on my observations, anyway).

AI doesn’t significantly expedite go-to-market in security

I have heard many people in the industry say things like “Now that I can ship new features much faster, I can scale with 3x-10x speed”. In other markets - looks like it, in consumer space - for sure, but in security, not so much.

It is true that founders can now ship new features faster, but the biggest obstacle to fast growth in security has never been the speed of shipping new features. The number one obstacle security founders have to grapple with is years-long sales cycles, and that isn’t changing anytime soon.

Andrew Peterson of Aviso Ventures, and formerly founder & CEO of Signal Sciences, put it really, really well in his post on LinkedIn: “AI is changing how fast you can build products and features but it isn’t changing how slow sales cycles are in security. This will continue to hamper the speed of growth in infosec despite the increased speed to build features.

You might think the costs of the products could go down a ton and drive speed of adoption but the price of security products have almost always been driven by sales and marketing costs, not dev costs or gross margins (that tend to be legendarily good in security).

Until we see sales cycles improve for security, we’re gonna be stuck with slow adoption curves for the time being. How I’d expect to see this change is a longer convo but short version is I don’t. Mainly because security relies on eng for install of meaningful controls and they’re rarely a priority (despite being easier and easier to actually implement).

All this said the growth of security start ups have always been strong and I predict will continue to be cause of constant new opportunities and innovation. I just don’t predict the growth to accelerate cause of AI despite expecting this in other sectors.”

I don’t think I can add much to this rather perfect summary of what I’ve also been seeing. If a feature that could take 9 months to ship now takes 6 months, that’s a dramatic improvement (30% shorter). But if the same feature takes a year to sell, then suddenly the math is different. What would usually take 1 year 9 months from concept to first paying customer can now take 1 year 6 months. In reality, it can be even longer because security teams afraid of risks introduced by AI-generated code are likely to extend their evaluation periods and ask to see more architectural diagrams and so on. We may cut time on writing software, but if the sales cycles remain the same or even become longer, we aren’t going to see radical differences in GTM speed.

AI doesn’t make it possible to avoid hiring senior engineering talent

Then there’s the question about talent. I’ve heard from several people that with tools like Claude Code, companies can hire fewer senior engineers and instead startups can attract young and hungry talent eager to use new tools. As someone smart once said, in theory, there is no difference between theory and practice, but in practice, there is. This very much applies when it comes to developers and AI-generated code.

My thought process is simple: from first principles, not much has changed, and most likely, not much will:

1. People who are hungry to learn and grow and do new things, but who don’t have solid experience, will, over time, outperform those who have experience but are much less motivated to learn and grow. This was the case before AI, and there will be no changes with AI. AI will only amplify the difference between motivated and non-motivated engineers. It’s 2025 and any software engineer that “didn’t have the time” to get started with AI coding assistants yet is probably on their way out of the industry.

2. People humble enough to admit they don’t have all the answers and smart enough to always look for shortcuts will, over time, outperform those who have more answers but feel like looking for shortcuts hurts their ego or makes them lesser. This was true before AI, when some devs were just “too good” to go to Stack Overflow or to just ask their colleagues for help and would waste hours trying to do things themselves. AI just makes the difference between two kinds of engineers more stark.

3. People who embrace new tech and new ways of working will always outperform those who don’t. There were plenty of developers who were against cloud, against agile, against shipping in smaller increments, against shipping continuously, etc. History has proven them all wrong big time. I don’t think it will be any different with AI: developers who don’t embrace it will go the same way as those who didn’t want to embrace the cloud.

4. Experience will continue to matter when it comes to building for scale and building for deterministic precision. It’s one thing to build a service, and it’s another thing to build a service that will perform at enterprise scale.

5. Domain expertise will continue to matter even more in a world where people think they can just AI their way into areas they don’t know anything about.

Companies that hire a bunch of engineers and ask them to use Claude to generate code without establishing real guardrails to make sure the quality of that code is solid will drown in technical debt before they close their first paying customer. In my opinion, senior engineers without AI tools are simply too slow and too expensive; junior engineers with no experience but drive and AI coding tools are likely to break too many things and create mountains of tech debt. The best answer is to hire great engineers and to give them all the latest and greatest tools. This does, however, mean that attracting amazing talent is as critical today as it was before (or arguably even more!).

Another interesting thing people miss is that AI is making building software harder, not easier. Mrinal Wadhwa articulated that thought several weeks ago: “Most software, until now, was focused on forms. Most software engineers spent their careers building 3-tier web apps. Products with agents, in contrast, are stochastic; each request has a long lifecycle; communication happens over bi-directional streams of messages; state is distributed across agents; etc. This is harder engineering. Sure, generating code has gotten easier, but to build reliable products that scale and are secure we now need much more complex architectures.” I recommend listening to this short 7-minute snippet because it offers a good perspective as to why strong engineering talent is even more critical today compared to several years ago.

AI isn’t going to kill security products anytime soon

Over the past several months, I have heard some people say, “I can now vibe code most of the security products over the weekend”, predicting that the wave of vibe coding will lead enterprises to stop buying SaaS. In my opinion, this could not be further away from the truth.

People who believe enterprises buy software only because they can’t build it in-house fundamentally misunderstand how large organizations operate. Open source has been around for decades, so why do enterprises still spend millions on freely available software? Because at their scale, the real cost isn’t in per-seat licenses; it’s in maintenance, reliability, and support.

Once a company reaches 5,000 employees (and definitely beyond 25,000), it needs scalable systems of ownership, maintenance, and accountability. If everyone just vibe coded their own tools and moved on, the whole structure would collapse. Every large enterprise already has a few internal tools whose creators have left (or even passed away), leaving behind fragile systems no one is brave enough to touch. That’s exactly why they choose to buy, not build, and that’s why they are so careful about throwing AI at problems.

Another aspect of security is that it is all about depth. Sure, anyone can vibe code some high-level basic system that will ingest cloud configs and output some findings. That is indeed very easy. However, to make it work for enterprise scale, enterprise complexity, and enterprise environments, for that, no vibe coding will be enough. More critically, to identify risks in complex systems, security products have to be five inches wide and 10 feet deep, and that depth is something that comes from human expertise, research, and clear focus, not from telling Claude to write some “cloud detection logic”.

Closing thoughts: for startups, AI is a great amplifier, but it’s not a compensator

There are many discussions about how AI makes it drastically easier to build startups. It may be the case in other industries and market segments, but I don’t think it’s true for security. Let me be clear and reiterate that AI does enable startups to solve problems that were fundamentally unsolvable before. In addition, it amplifies a lot of the security problems our industry has been trying to solve (data security, SaaS security, third-party risk management, etc.). All this creates new possibilities, new problems, and therefore new markets and new opportunities.

However, what AI doesn’t do in my view is change how security companies are built. It does make some things like prototyping easier, but it doesn’t make a bad idea a good one, and it doesn’t make “this looks good” a real validation. AI makes great developers even more productive than before, but it doesn’t turn a junior developer into a senior, or an unmotivated developer into a 10x high-performing engineer. In other words, AI is a great amplifier, but it’s not a compensator.

Most importantly, AI doesn’t really change the fundamentals:

• That security is about trust, and unpredictability of AI only increases the bar for developing trust.

• That enterprise sales are about navigating people and complexity, and AI does little to reduce that complexity.

• That building great products requires depth and expertise, and you cannot win by relying on what is literally the average of human knowledge.

Fundamentals for building a successful company don’t really change: a large market, a strong team, and ten million decisions that have to be made right, with the hope that the wrong decisions will be insignificant enough to matter.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share Venture in Security

Share

Subscribe now

I am saying all this as a preface to the fact that this article is going to be different. Today, I am diving headfirst into the topic of the day, namely the AWS outage. Yet, even here, I’ll be doing it mostly my way.

This issue is brought to you by… Dropzone AI.

Most AI SOC Tools Are Still Unproven. This Study Actually Measured Them.

Your board wants proof that AI delivers on security operations, not vendor promises. The Cloud Security Alliance independently tested 148 real SOC analysts investigating actual alerts with and without AI assistance. No sales pitch, no cherry-picked results.

The findings? AI-assisted teams completed investigations 45-61% faster with 22-29% higher accuracy. Even skeptical analysts became advocates after hands-on use. More importantly, CSA maintained complete control over methodology and results, making this the independent validation your stakeholders actually trust.

If you’re evaluating AI for your SOC or need data that survives board scrutiny, get the full CSA benchmark study here.

Get the CSA Study

The news about the AWS outage is not really about the AWS outage

Now I need to clarify something here: I am not actually going to be talking about the AWS outage. There are so many people talking about the ins and outs and reasons and outcomes and whatnot that having one more voice would not add any value. Instead of talking about AWS, I think it’s worth talking about the problem at hand in the broadest possible way.

It doesn’t take long to draw parallels between the AWS outage and the CrowdStrike outage some year and a half ago, and that is a fair comparison. I am sure there will be zealots saying “they are different events because…” (and many will be right), but as far as the outcomes go, these two events look pretty similar to me. In both cases, an important platform went down, which has led to the platforms that depend on it going down.

This brings me to the main point of today’s piece. In our discussions about supply chain risk, we have forgotten that there is something else at play here, which is that our digital world is powered by many components that are critical and virtually irreplaceable. I believe this is exactly the definition of critical infrastructure.

Redefining “critical infrastructure” for the modern age

The outdated definition of critical infrastructure

In most countries, the term “critical infrastructure” is defined by the government policy frameworks that go back many years and often even decades. CISA, a part of the U.S. Department of Homeland Security, explains that “There are 16 critical infrastructure sectors whose assets, systems, and networks, whether physical or virtual, are considered so vital to the United States that their incapacitation or destruction would have a debilitating effect on security, national economic security, national public health or safety, or any combination thereof.” If you look at the list of these sectors, it will make a lot of sense: energy, water, transportation, communications, healthcare, financial services, manufacturing, and other areas are indeed all critical.

The US isn’t the only country that has compiled this kind of list. There’s the EU’s NIS2 Directive, Canada’s National Strategy for Critical Infrastructure, and I am sure if you ask ChatGPT, you’ll get examples of something similar for most countries (hopefully, all real).

All these frameworks originated at a time when national stability was closely connected to the physical world: electricity generation, oil pipelines, airports, and emergency response systems. The idea was that we need to protect infrastructure and systems that, if disrupted, can harm a lot of people or interrupt critical public services. This approach gave governments a consistent way to prioritize what matters most and allocate resources where they can make the most difference. Agencies can assign responsibilities to sector-specific regulators, figure out resilience requirements, and set up things like public-private partnerships to protect critical functions. These frameworks have proven very valuable to protect traditional infrastructure and coordinate emergency response during events like earthquakes. But, over time they also proved to be insufficient.

As time went by, people realized that the digital world matters, and we now see IT systems that support many critical functions also on the list. On paper, everything seems to suggest that we’ve learned that the digital world does matter. Certainly, the fact that AWS, Microsoft, Accenture, Oracle, and many other organizations are now a part of CISA’s Information Technology Sector Coordination Council is great news. What worries me is something else.

What modern critical infrastructure actually is

Transparently, I don’t know what this Information Technology Sector Coordination Council does (maybe I would if I had enough patience to read through its charter). To me, that’s not even the most important part. It all starts with who is on that council.

If you look closer, you’ll see that a large percentage of the organizations on that list are tech giants like Oracle, HP, IBM, Dell, AWS, and Microsoft, and cyber companies. This makes sense because these companies support the computing, storage, and network environments that government agencies, healthcare providers, and enterprises rely on every day. They provide the foundational technologies that power data centers and enterprise software, the modern equivalents of the roads and power lines that keep the digital economy functioning.

What’s less obvious is that the new generation of companies that I’d argue should be considered “critical” is not on the list. Take Twilio, for instance: it provides messaging and communications infrastructure embedded in everything from hospital appointment systems to two-factor authentication flows used by banks and government portals. If Twilio goes down, the entire authentication and notification systems can fail across thousands of organizations simultaneously. Similarly, Stripe processes payments for millions of businesses around the world, making it a critical layer of the global financial system. When Stripe’s services go down, the impact cascades across every single business that processes transactions online, like e-commerce, subscription platforms, and a large number of enterprises.

Then there are companies like Snowflake and Databricks, which have become central to how modern organizations store, process, and analyze data. These platforms host sensitive data for enterprises across healthcare, finance, manufacturing, and the public sector. Their availability directly influences an organization’s ability to operate, make decisions, and respond to incidents. Add to this list platforms such as Atlassian (which powers engineering collaboration), Okta (identity and access), Cloudflare (web and network security), and GitHub (software development infrastructure). An even better example is GoDaddy, a platform that manages a huge chunk of the world’s domain addresses. Each of these tools supports core business operations at scale, across companies of all sizes, and if any were to experience a prolonged disruption, the number of companies and whole sectors that would be impacted would be incredibly high.

All this is to say that the present-day definition of “critical infrastructure” is completely outdated. Nearly everything in the digital world is interdependent, and a failure of one part of the system can lead to a cascading effect in ways we cannot even predict. If you want proof, think back to the CrowdStrike outage. In theory, an outage of the endpoint security platform should not have caused airports to crumble, but guess what, it did. I surely hope that we won’t see a growing number of outages, but we all know that our digital world is starting to look more and more like this famous meme from ages ago.

Looking into the future: this isn’t about words

When we think about the problem of protecting critical infrastructure, it’s definitely important to prioritize things that can impact the safety and well-being of people. Water, electricity, financial systems, and other areas are certainly the right things to think about first. And yet it’s important not to forget that the digital world relies on its own digital infrastructure that is all interconnected and, as we’re learning every year, incredibly fragile.

I don’t know what the future of this problem will look like, but I do know that this isn’t about playing with words. Recognizing what truly constitutes critical infrastructure has real, tangible consequences. How we define “critical” determines what gets regulated, what resilience standards are enforced, and what kinds of incident response and redundancy planning will be put in place. If we continue to treat cloud platforms, SaaS ecosystems, and digital intermediaries as ordinary vendors rather than as essential systems, we risk underestimating the scale of disruption a single outage can cause. A modern economy that runs on APIs, cloud workloads, and distributed services depends on a different kind of backbone, one that is global, digital, and deeply interconnected. We live in a world where an outage of Microsoft Entra ID can disrupt planes, an outage of Duo can disrupt hospitals, and an outage of Webex and Microsoft Teams can disrupt emergency response. We have to be able to at least acknowledge this reality and admit that many of the startups are now as critical to our functioning as a society as large tech giants. That, in my opinion, is the first step toward building resilience for the world we actually live in, not the one we used to.

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.

Lastly, check out the Inside the Network podcast where we bring you the best founders, operators, and investors building the future of cybersecurity.

Share Venture in Security

Share

Subscribe now