A perfect cybersecurity startup idea
Discussing a variety of dimensions that would constitute an “ideal” cybersecurity startup idea
Having learned a ton about the state of the industry over the past several years, and having been through the process of ideation, customer discovery, and figuring out what areas are worth focusing on myself, I ended up collecting a bunch of notes about different problem areas. In this piece, I am discussing a variety of dimensions that would constitute an “ideal” cybersecurity startup idea.
This issue of Venture in Security is brought to you by… Tines.
Top security team priorities and challenges in 2025, according to IDC research
For Voice of Security 2025, sponsored by Tines and AWS, IDC surveyed security leaders in the US, Europe, and Australia.
The research uncovered that 72% of respondents saw increased workloads last year, yet, 58% consider their teams "properly staffed.” Where’s the disconnect? And what other challenges are leaders facing this year? Read the full white paper to hear more on:
AI adoption progress and top use cases
How teams are performing against key metrics
Tool stack strengths and weaknesses
The skills analysts need to succeed
General thoughts about startup ideation
There’s no such thing as a perfect idea
Let’s get the obvious out of the way: there’s no such thing as a perfect idea. Even if there was, it would probably not matter because no two founding teams with the same idea would end up building the same product, even if they start in the exact same place. Eventually, their paths would diverge in terms of product, positioning, go-to-market, the customer segment they are focused on, and a variety of other factors.
At the same time, I must admit that I find the notion that “ideas don’t matter, all that matters is the execution” plain wrong. A startup idea is the starting point, the initial wedge, and getting it right matters more than many people would like to think. It is important not to get stuck in analysis paralysis, but it’s equally important to spend time and learn as much as possible early on. It’s much easier (and cheaper!) to pivot when the company is just the pitch deck, as opposed to after it has raised capital and VCs expect founders to move fast and execute. Moving fast toward a cliff may get the company off the cliff very quickly. Sure, pivots and adjustments are inevitable, but most companies that pivot end up pivoting within the boundaries of their market and sometimes even their ICP (unless they’re a YC startup in which case they can totally pivot from appsec to building an app for pet owners, or something like that).
Customer discovery without a perspective is useless
For many in the industry, startup ideation is synonymous with asking CISOs about their problems. Having done enough of that myself, I have learned firsthand that in most cases, these kinds of calls are of pretty low value. There are a few reasons why that is the case.
First, when you ask CISOs what their problems are, in 99 cases out of 100 you are going to hear things that are pretty well known: identity, phishing, ransomware, asset management, vulnerability management, getting developers to do the right thing, etc. This is the state of the industry when the problems we’re trying to solve are generally just the basic problems one can learn about by reading an article online and sparing overworked CISOs from having to relive their nightmares on a Zoom call.
Second, if you ask 10 CISOs about their perspective on the same problem, you are going to get 11 different opinions. If you think about it, this makes perfect sense since every company does security their own way. Imagine you talk to a driver and ask “What are the capabilities that an ideal car should have?”. Someone will say they need a siren, someone else will want it to fit 50+ people, and someone else will say it should be able to hold 3,000 gallons of water. None of this feedback will help you to design a solution to their needs until you realize that each and every person has a different use case for what they refer to as a car.
Image Source: ChatGPT
What leads to even worse results than asking CISOs about their problems is asking them what an ideal solution would look like. It's always hard for practitioners to see what the next iteration of a solution could be until someone puts forward a vision. If you think about this, it also makes a lot of sense: security professionals are focused on the day-to-day, and in order to come up with a unique angle, one needs to have the luxury of being able to step back and observe the problem. Very few are able to do that given the demands of their jobs.
The only kind of discovery I have personally found helpful is putting forward a vision, and then trying to learn why it would or wouldn’t work, without talking about the vision itself. Your mileage may vary but this is what I found yields the best results.
Once again, there’s no such thing as a perfect idea
Before we dive into some of the aspects I think about when I look at the startup idea, let me once again reiterate that the goal isn’t to actually come up with a perfect idea. Instead, it is to think through and consider some of the parameters that are going to impact the probability of success and make informed decisions with these parameters in mind.
With that out of the way, here are some of the factors to think about.
An ideal cybersecurity startup idea: 11 things to consider for aspiring founders
Founder-market fit is the number one deciding factor for security startups
Having spent a good amount of time in the security market, I am now convinced that there are no “good” problem areas to build in, no “great” market segments, and no “perfect” ideas. The only thing that matters is whether your founding team is the perfect team to solve a specific problem. Let me explain.
In emerging and not too competitive markets, founders often have enough time to figure things out. When nobody is breathing down your neck, it’s okay to be wrong, it’s okay to make mistakes, and it’s okay to take time to figure things out. Security, however, is not one of those markets. In security, the moment a single founder lands on an idea, there are immediately 2 to 5 other companies starting with the same vision. If the founder doesn’t have a solid founder-market fit, if they need to learn a new domain, if they don’t have a strong intuition about the problem space they are working in, they are already behind before they write a single line of code.
For me personally, this was not an easy realization. Having worked in several industries in the product role, I have always been able to quickly build an understanding of the space, and some 4-6 months later I was already at the very top of the market. When I worked in the mortgage technology space, I became a licensed broker after two to three months. When I joined an endpoint security company, I learned the new space very quickly. It may be counter-intuitive, but deciding which problem to build the company around is not the same as deciding which company to join. When you join a company, nobody expects you to add much value in the first 30, 60, and sometimes even 90 days. The understanding is that you will take time, learn the space, build relationships with your colleagues, and then press on the gas. When you are launching a startup, you have to make decisions on day zero, and if you aren’t deeply familiar with your playground, if you hesitate, there are at least 2-5 other companies building the same thing that will outcompete you on any given day.
Another reason why founder-market fit is so critical is the fact that security is purchased in categories, and to innovate in a specific category, founders generally need to have accumulated a solid perspective about the previous iterations of the same category. Sure, at times having a fresh take on the space may enable entrepreneurs to tackle the problem differently, but even then they have to have a strong perspective and a conviction that they are right.
The lesson here is simple: if you don’t have expertise in identity, it will be harder to start an identity startup; if you don’t have expertise in endpoint, it’ll be tough to build an endpoint security startup, etc. It’s less definitive for second or third-time founders who can assemble a winning team and execute quickly and confidently in a new space. First-time founders, on the other hand, will make mistakes even when they build in the space they know well, so going after the space they are new to puts them at a major disadvantage.
Advantages come in two forms: product and GTM
Founder-market fit comes in two forms: go-to-market and product/technology. In the ideal universe, founders would have the expertise of selling in the specific market or market segment and building in the same space. Everything else being equal, a team where one co-founder has experience building cloud security solutions and another co-founder has experience selling cloud security solutions should be able to outcompete teams with only one type of expertise.
As we have discussed, life rarely presents us with an ideal setup. To me personally, what matters is that the founding team has at least one of the two types of experience (either selling or building).
Aligning the idea with access to talent
Let’s assume you have enough evidence that there is a problem customers care about and are willing to pay to solve, you are convinced you have the right skills and experience to build and sell a solution, and you have reasons to believe you can do it better than others. The next question is - “Who is going to build it?”.
I think many security founders under-appreciate the importance of this question. Broadly speaking, there are two types of security products: those that can be built with a few full-stack engineers and without deep specialization, and those that require deeply specialized talent. I think posture management tends to fall in the former category, while detection and response often belongs in the latter. You can build a tool that helps companies manage their SaaS licenses with a team of full-stack developers, but there are probably 50 people on the planet with enough experience to build an endpoint agent (this is an example to illustrate the point, I haven’t actually counted them). The same applies to emerging technologies like AI. Some ideas are doable by a good back-end engineer, while others are so deep that they would require a hard to find world-class PhD with deep specialization in a specific niche of AI.
It’s hard not to notice that cybersecurity-focused software engineering expertise is now largely concentrated in Israel. However, while it's been widely acknowledged that Israel is the epicenter for solid talent in the fields of vulnerability research and offensive cyber, I don’t think enough people realize that cyber-focused software engineers in the US are also becoming rare. As more and more security vendors open research and development centers in Israel, through acquisitions or expansions, the pool of US-based software engineers with experience building security products is shrinking.
One way or another, when deciding what ideas to pursue, founders have to be strategic and factor in their ability to access the talent required to build the product they envision.
On the topic of painkillers, not vitamins
A lot can be said on the topic of painkillers vs. vitamins. For those not familiar with the concept, painkillers are must-have solutions that solve unmet customer needs, and vitamins are nice-to-have solutions that make things better but customers can live without. In my opinion, in security, this maps cleanly to products that satisfy compliance requirements (must-haves or painkillers) and products that don’t (nice-to-haves or vitamins).
If the goal is to build a venture-scale security company, founders should be looking to do something that supports the compliance mandate (ideally either directly checks the box or makes it much easier to check the box). Companies selling capabilities that don’t directly tie into compliance requirements usually end up exhausting their market pretty quickly, or they are forced to pivot. That said, if the goal is to build a bootstrapped business, it may very well be a good place to focus on since most VCs will generally stay away from what they consider “niche” problems, leaving opportunities on the table for entrepreneurs not forced to adhere to clear the same large TAM (total addressable market) bar.
No cross-department purchasing
Another factor that impacts the probability that a startup is going to be successful is whether or not it can be marketed to, sold, and deployed by the same team.
Ideally, a security product is purchased by the security team, deployed and managed by the security team, and used by the security team. When the security team needs help from other departments to deploy a new tool, it’s ideal if those teams report to the same executive. For example, if the CISO reports to the CIO or vice versa, they’re more likely to align on priorities. That alignment makes it easier for the security team to get support from IT or network teams when rolling out new solutions. In contrast, a CISO and a CTO often don’t have a direct reporting relationship, which can lead to misaligned priorities and slower collaboration.
As a rule of thumb, the team buying and using the product should also benefit from this product. For example, a cloud security product deployed and managed by the security team will be much easier to sell than, say, a cloud misconfiguration prevention tool designed to be used by or deployed in front of engineers.
Any founder will tell you that having to deal with cross-team purchasing can make GTM harder. Gartner has a great chart illustrating what a buyer's journey in B2B looks like. Although every company and every product will be different, the overarching idea is the same: getting an enterprise to make a decision is a complex journey even when there is a clear buyer, let alone when two or three teams need to come together to decide who needs the solution, who will pay for it, who will manage it, and so on.
Image Source: Gartner
Deployment without friction
Some time ago, I wrote a post on LinkedIn saying “I don't believe that in 2025, a startup can convince any CISO to deploy a new agent in their environment. This is just a fact. Time to value is more important than depth of insights.” This was an oversimplification, but the discussion this post spurred was quite telling. There is certainly an argument that having a deeper visibility is important, that the depth of security coverage matters a lot, and so on.
There’s social media and there is real life. And in real life, feasibility and time to value win most of the time (if not all of the time). Everything else being equal, of course, it would be great to have a deeper level of security insights with a simple onboarding experience. In practice, life doesn’t quite work that way. If the security team is deciding between good enough coverage from a product they can roll out within a week, and better coverage from a product they may be able to roll out after 6 months but only after battles with IT, engineering, or whoever will be pushing against a “yet another agent”, most teams choose a “good enough” option.
The story of Wiz is a great illustration of this point. The "agentless" narrative, combined with slick UX and fast insights, made it easy to demo and sell. CISOs and security teams loved it. Lacework, on the other hand, offered deeper telemetry, using an agent to gain visibility inside workloads. However, agent friction, combined with longer onboarding times and more complex architecture, led to slower sales cycles and often made it less attractive in early evaluations, even if its security insights were more in-depth. There’s surely much more to the story of each of these startups, but frictionless deployment (or the lack thereof) was certainly one of the key factors why the two companies had such different outcomes.
One thing I’ve come to realize is that CISOs often overestimate what their security teams can realistically accomplish and what hurdles they would be willing to go through to get it done. It’s not because they’re misguided - they understand what needs to be done and genuinely want to do the right thing. The challenge is that when rubber hits the road, they tend to encounter far more friction when trying to implement security controls than they expected. When that happens, they’re forced to prioritize. They’ll power through complex deployments for tools that are absolutely critical to their security posture, like EDR for ransomware prevention but are far less likely to invest the same effort in solutions that are nice-to-haves or lower on the priority list. This is why frictionless deployments are so important: if someone on the engineering leadership team pushes back against what they see as “unreasonable” security controls, chances are CISOs won’t insist unless they view these controls as critical.
Solving problems in security starts with visibility
Solving problems in security starts with visibility. While it's become somewhat fashionable for practitioners and influencers on social media to proclaim that “the industry is fed up with visibility,” this sentiment overlooks a fundamental truth: visibility is always the first step in identifying, understanding, and ultimately solving security problems. Without clear, actionable insight into what’s happening across the environment, be it network traffic, workload behavior, access patterns, or misconfigurations, security teams are left reacting blindly. Visibility lays the foundation for threat detection, policy enforcement, and risk prioritization. It’s not a solution in itself, but it’s an essential prerequisite for all other actions that follow.
For CISOs and security leaders, visibility enables better decision-making. To justify investments, whether in new tools, process changes, or team expansion, they must first understand where the gaps lie and how those gaps impact the business. If a security control is missing, misconfigured, or bypassed, it can’t be addressed unless it's seen. If a workload is leaking sensitive data or connecting to unsanctioned endpoints, it can't be stopped without first being observed. Effective security programs are built on the ability to measure, monitor, and map the environment. Visibility is not the end goal, but it’s always the starting point and without it, there is no secure path forward.
For founders, this means that unless there is already a visibility product that surfaces issues in their area, for them to sell remediation, they need to start by exposing gaps which means building a visibility layer. It’s ideal if the product can generate findings quickly, and then immediately help fix them - this way it can both justify the need for its existence (visibility aspect) and actually solve the problem (remediation aspect).
On the other hand, visibility-only products are becoming harder and harder to sell because all they do is create more work for the already overwhelmed security teams struggling to keep up with the stream of “urgent” tasks and shifting priorities. Solutions like various forms of asset management platforms suffer from the “So what?” problem: in theory, people need to bring all their problems into the same place but in practice, it’s hard to justify buying another problem repository over a more actionable solution.
Avoiding products that require deep behavioral shifts
I think that as a startup, you have to be smart about picking the battles worth fighting. Trying to convince the whole industry that it is doing things wrong is one of those battles that isn’t worth it. As one very successful entrepreneur said in one of our discussions, as a company you want to be smarter than some of your prospects but you don’t want to be smarter than all of your prospects or else you’ll have no customers.
Broadly speaking, if adopting the new solution requires customers to completely rethink their entire security program and second-guess decisions they and their teams have made over the years, the likelihood of that startup finding success is extremely low. Most organizations aren’t willing (or able) to overhaul deeply entrenched strategies just to accommodate a new tool, no matter how innovative it may be. There may be smarter ways to get started by leaning into the way companies do things today, and slowly, step by step helping them to evolve. Either way, relying on deep behavioral shifts is highly unlikely to work.
Aligning the product with everyone’s incentives
For the purchasing process to be smoother, as many people involved in the purchasing process as possible should be able to get a win. Many of the largest opportunities happem when someone on the buyer's side is trying to get a huge career win. They may be betting on digital transformation, and if they could pull it off by bringing in the right vendor, they would get that promotion to director, VP, etc. If a product can solve more than simply a security problem, it often stands a better chance at getting adoption. A great example of this is Chainguard: it helps developers by making security seamless and non-intrusive, while also giving security teams stronger controls and visibility. This cross-functional benefit increases the product’s relevance and makes it more likely to succeed in complex enterprise environments.
Another aspect of understanding incentives is understanding what has the potential to impact people’s careers, lead to conflicts, or even get them fired. Security leaders have to pick their battles and avoid introducing friction where it’s not absolutely necessary. This includes avoiding attempts to fix what’s not broken. No customer is going to replace a product they spent many millions and many years to adopt. I.e., a CIO or a CISO will get fired if they come to the CEO saying “We need $5 million to replace Zscaler or SailPoint we just spent 3 years and $10 million to implement”.
Selling the product to enterprises from day one
Here’s something that isn’t obvious to most people (and it wasn’t to me either until recently): if you want to build a security product for enterprises, you have to start by selling to enterprises.
The conventional product advice says to begin with SMBs, then move to mid-market, and eventually go upmarket to large enterprises, gradually climbing the ladder from companies with 500 employees to 1,000-2,000, and finally to 10,000+. That playbook might work in some industries, where you can bolt on features like SSO, MFA, RBAC, and 24/7 support to make a product "enterprise-ready." In security, that approach falls apart. The needs of large enterprises, and the complexity of their environments, are fundamentally different from those of mid-market companies and SMBs. You can’t retrofit your way into the enterprise. If you want to serve the big players, you have to design for them from day one. Just look at the most successful security companies: Okta, CrowdStrike, Zscaler, Palo Alto, SailPoint - they all started by building for large enterprises first. The main point here is not that everyone should be building for large enterprises - there are plenty of opportunities in all market segments. What matters is that if your goal is to indeed target the top of the market, you have to find a way to start as close to it as possible, ideally building for them from day one.
Selling to both engineering-centric and non-engineering-centric companies
No matter which idea you pursue, you’ll inevitably start with a niche. The real question is: which one? A common pitfall I see is founders building for engineering-heavy security teams at Bay Area tech companies, without realizing that if your product requires a security engineer to operate, your market is going to be limited. Most companies don’t have that kind of team.
Ideally, you want to define your ICP so that both engineering-centric and non-engineering-centric security teams can use your product. You might still start with the engineering-heavy crowd since they’re often early adopters, but your product shouldn’t be constrained to them.
Where to look for good cybersecurity startup ideas
Nearly everything in security has been tried, and most problems (with the obvious exceptions of AI and emerging technologies) are well documented and understood. The opportunity for innovation today isn’t about what, it’s about how. In other words, it’s not about coming up with new problem areas but it is about solving the existing problems in new ways.
There are five areas I believe is worth looking at:
Opportunities created by new technologies to solve existing problems better. AI is certainly one of them, but looking beyond AI can also be useful, especially if you consider generations of companies created by the emergence of WireGuard, eBPF, Osquery, and other technological advancements.
Looking at areas everyone is tired from. Identity as a whole is primarily owned by private equity, for instance, and companies have been looking for new approaches for a while.
Looking at startups that rushed into a market and did it haphazardly. They probably made it work in the end and got acquired, but that doesn’t mean there is no opportunity for others to try and deliver on their original promises.
Looking at secular trends in the technology space and the opportunities they create. This includes decentralized purchasing of software in the enterprise, the growing complexity of the cloud, the rise of hybrid work, and others.
Looking for shifts in adversary behavior. Attackers are generally very pragmatic, in that they will continue doing what works for as long as they see the return on investment they are happy with.
I am sure there are other areas to innovate in, but these are the ones that immediately come to mind when I think about startup ideation.
“Why now?” remains the number one factor to think about when deciding on an idea
In my recent piece titled “Why now?”: a single question that decides what security startups succeed, and which fail" I discussed that companies don’t change their tech stack unless they are forced to. In security, there are three types of “Why now?” that enable the creation of new companies:
A new technology makes it possible to solve problems in a meaningfully new way which makes new solutions better by definition. For instance, AI today enables effective automation of manual processes which, in turn, can change the entire business models of how technology is built. As an example, it may be possible today to build highly scalable, product-first managed detection and response (MDR) or pentesting companies in ways that weren’t possible before.
Change in infrastructure makes old approaches insufficient or completely irrelevant in the new world. Infrastructural shifts are the strongest type of “Why now?” and as such they tend to create opportunities for the emergence of billion-dollar companies. Okta, Zscaler, and Palo Alto are perfect examples of this phenomenon.
Change in adversary behavior pushes companies to look for new ways to defend their environments. If the new adversary behavior requires a completely different approach to detection and response, or a completely different architecture of the solution, this can create a tremendous opportunity for new startups. Not only can this enable unparalleled value creation, but those who can seize the opportunity will often be able to create billion-dollar companies. CrowdStrike, Palo Alto, Abnormal, and Material are some examples of companies that illustrate this point.
For those interested in diving deeper, I highly recommend checking out this article: “Why now?”: a single question that decides what security startups succeed, and which fail".
Most importantly, remember there are no perfect startup ideas, in security or elsewhere.
Great post, Ross. Many points are also relevant for B2B software outside of cybersecurity
If you do it I am on