Lenny Zeltser

How Modern Design Principles Strengthen Security

Tue, 14 Apr 2026 00:00:00 GMT

Unnecessary complexity makes products hard to maintain and hard to secure. Modern apps such as Cloudflare's EmDash and Tailscale show that designing for simplicity produces stronger security as a side effect.

Every design choice in a product shapes what customers must configure, monitor, and maintain. When the software requires an operating system, someone must patch it. When authentication relies on passwords, someone must store, hash, rotate, and reset them. When extensions run with unrestricted system access, every extension author becomes a security dependency. Modern applications are showing how simpler designs can produce stronger security as a side effect.

Every Component Is a Liability

WordPress illustrates the pattern. 90-96% of its security issues originate in plugins, according to Patchstack and Wordfence. WordPress architecture gives every plugin unrestricted access to the entire system, so the extensibility that drove its adoption also made it difficult to secure. A malicious or exploited extension can affect the entire environment.

Software components not only add features, but also add things the customer can misconfigure, forget to update, or leave exposed. Self-hosted databases need replication setup, backup configuration, and version upgrades. Container platforms need network policies, image scanning, and cluster maintenance. The longer that component list grows, the harder it becomes to keep up.

Design for Simplicity, Get Security

Cloudflare's EmDash shows how modern product design can strengthen security as a side effect. They rebuilt WordPress from scratch as a serverless CMS. The app's architecture made it simpler to operate and harder to attack:

Eliminate customer-managed infrastructure. EmDash has no PHP runtime, no customer-managed operating system, no long-running web server, and no customer-managed database. The application runs in lightweight sandboxes that spin up on demand and shut down when idle.
Isolate extensions and require explicit permissions. Plugins run in isolated sandboxes and must declare the capabilities they need, such as "read:content" or "email:send." A plugin that declares only content-reading capabilities can't access the network or the filesystem.
Let the underlying platform handle patching. The platform provider handles patching on its own schedule, with no customer-managed OS to maintain.

EmDash is new and unproven (as of this writing), and platform offloading creates its own vendor dependency. But its architecture shows what a simpler design can achieve.

Consider another example: Traditional VPN deployments require opening a port on a firewall, standing up a server, distributing credentials, and maintaining certificates. Multi-component VPN software, such as OpenVPN, added a significant attack surface on top of that operational burden.

WireGuard took a different approach. Rather than building a full VPN stack, it designed a tunneling protocol around radical simplicity. Its entire implementation fits in roughly 4,000 lines of kernel code, small enough for a single person to audit. It uses one fixed cryptographic suite with no cipher negotiation. Products such as Tailscale build on WireGuard to create identity-based mesh networks. The customer maintains no server, no open ports, and no certificates to rotate.

Defaults That Win

Reducing complexity removes entire categories of risk. But the components that remain still need safe defaults, because users rarely change what ships out of the box.

The most successful secure defaults don't feel like security at all. When Microsoft made passkeys the default for new accounts, passkey sign-ins grew by 120%. The FIDO Alliance reports a 93% success rate for passkey logins compared to 63% for traditional methods. Passkeys are faster and easier to use than passwords for many people, and they happen to be phishing-resistant.

Misconfigured cloud storage buckets were among the most common sources of data breaches before AWS made Block Public Access the default for all new S3 buckets in 2023. The feature had existed since 2018, but it required customers to enable it. Changing the default eliminated an entire category of exposure.

EmDash applies the same deny-by-default approach to extensions, and even administrators who make no changes still get a secure configuration.

Where These Principles Lead

EmDash, WireGuard, and Tailscale all followed modern design principles: They minimized components, offloaded infrastructure to platforms, and defaulted to least privilege. The security improvements emerged from those architectural decisions, not from adding controls on top.

For builders designing new products or rearchitecting existing ones, the following principles can guide the work. For existing apps, each component simplified, offloaded, or removed is one fewer thing to patch, configure, and directly defend.

Review your component list. For each component, whether the runtime, database, authentication system, or extensibility model, ask whether the product truly needs it. Could a platform service replace it, and does that shift reduce your overall risk? Could a different architecture eliminate it entirely?

Default to the safest configuration. If a user installs your product and makes no changes, it should be in a secure state. Every permission, integration, and capability should require an explicit opt-in rather than an opt-out.

Measure what you eliminated, not just what you added. A well-designed product makes security problems structurally impossible. If your customers configure fewer components, rotate fewer credentials, and patch fewer systems, you've strengthened security before adding any controls.

The design decisions that reduce what customers must manage also reduce what attackers can target. Builders who design for simplicity will find they've already designed for security.

When Executives Reject Your Security Recommendation

Thu, 09 Apr 2026 00:00:00 GMT

A rejected security recommendation feels personal, but it often reflects competing demands the security team doesn't fully see. Knowing how to act on that reality helps the CISO become someone the business trusts with its priorities.

As cybersecurity leaders, we've inevitably felt frustrated when executives didn't act on our recommendation. The instinct is to conclude that leadership doesn't take security seriously, but that take is usually counterproductive.

Executive managers are weighing cyber risks against revenue targets, hiring plans, product launches, and dozens of competing priorities. Sometimes they're right to choose differently, and the rejection itself can sharpen our thinking by forcing a more targeted approach. To move past merely advising, we need to understand why they disagree and find ways to frame our perspective on their terms.

Disagreements Shouldn't Surprise Us

That colleagues disagree with us shouldn't be a surprise, but it often is. We invest time and energy in identifying, prioritizing, and explaining risks, and that effort fosters a sense of ownership. Behavioral economists call it the endowment effect, which is the tendency to overvalue what we possess. An executive who hasn't spent hours analyzing the same security issue doesn't share that sense of ownership. As a result, the same risk might weigh less in their mind than in ours.

Decision fatigue amplifies the problem. Executives make hundreds of resource allocation decisions in a given week. When our risk perspective reaches them, they may be operating with diminished attention. The status quo wins, not because it's the right call, but because it requires the least effort.

Traditional justifications for security spending often fall short, even when executives are paying full attention. As Phil Venables has explained, arguments based on loss avoidance, reputational risk, and return on security investment don't justify the accumulated costs of the mitigations we propose. Executives have learned this through experience, having watched companies suffer high-profile breaches and recover. Many have drawn their own conclusions about how severe the consequences really are and have grown skeptical of our severity ratings.

None of this means the disagreeing executive made the wrong call, assuming they made an informed decision. They're evaluating a broader set of tradeoffs than we see from the security team's perspective. If the problem isn't that they failed to understand us, repeating the same arguments louder won't help. We need to change how we respond to disagreement.

How We Make Rejection Worse

When executives reject a recommendation, we tend to make predictable mistakes that weaken our ability to influence:

We take it personally. We interpret the rejection as the organization not valuing security. In most cases, the decision reflects resource allocation priorities, similar to deprioritizing a feature or deferring a hire. Other functions in the company face such constraints, too.

We double down with more data. We respond to "no" by piling on more proof that the risk is real. If we did our best with the original explanation, additional details are unlikely to change the executive's decision. They probably already agreed that the risk exists and decided that the mitigation wasn't worth pursuing right now.

We don't ask why. We walk away frustrated instead of asking what would need to change to get a different answer. The right question, asked genuinely, can reveal the constraints we didn't see and open persuasion paths we didn't consider, possibly for a later conversation.

These reactions assume the problem sits with the executive. None starts by examining our own framing. If they understood the risk and chose differently, we should either accept the decision or return to it with a different approach.

A Slide Deck Isn't a Handoff

Security governance is a shared organizational responsibility, not something the CISO carries alone. But our job doesn't stop at presenting risks. As Allan Alford has argued, "I presented the numbers and leadership decided" is where our work starts, not where it ends. If the message didn't land, we adjust the framing and try again.

Allan also pointed out that we decide which risks reach the executives' desks and which ones we handle quietly. When we "walk into a budget meeting requesting funding for three initiatives and stay silent on four others," we implicitly make a risk acceptance decision. We should be deliberate about what we defer and transparent about why.

A genuine handoff requires explicit terms, not a checkbox on a slide deck. It sounds like "We'll accept this for six months, revisit in Q3, and add monitoring in the meantime." That specificity creates a shared commitment that both sides can track.

Even after that handoff, our work continues as part of regular governance. Circumstances change, so we monitor whether the original risk decision still holds through periodic risk reviews. The executive takes input from many sources, so we continue shaping the conversation through allies and timing. And we build resilience that makes it easier for the business to accept risks. Defenses, guardrails, and buffers absorb tolerable insecurity so the organization can move forward.

Make It About What They Already Want

Understanding why executives said no reveals what might make them say yes. The most effective way to earn that yes is to connect our recommendation to something the business already wants:

Offer options, not ultimatums. An executive who says no to a $1M project might say yes to a $100K first step. That first step addresses the highest-priority exposure, prioritized by business context. Presenting tiered alternatives gives them a way to say yes to something rather than no to everything.

Build allies before you need them. A recommendation that arrives with the CFO's or CTO's support lands differently than one from security alone. Invest in cross-functional collaboration before the critical ask. Phil Venables has observed that formal committees confirm decisions, not make them. Allies shape those decisions before the meeting starts. He calls this building a "base of support" by being useful beyond the immediate boundaries of the security role.

Connect to outcomes they already measure. When security solves a problem another team already has, the ask sells itself. Automating manual access provisioning saves the dev team 10 hours per sprint, for example. Achieving SOC 2 unblocks enterprise deals stuck in procurement. Frame the expense as unblocking revenue or velocity, not reducing risk.

Make the cost of inaction specific to their world. A concrete scenario tied to the business is more persuasive than generalized breach statistics. What separates specificity from FUD is a named customer, a dated deadline, or a measurable outcome. "If customer X asks about this in their next security review and we can't answer, that's a renewal risk." Understand what motivates individuals, not just the organization.

From Opinion to Influence

When we prioritize risks and articulate them in the executive's terms, a "no" becomes the beginning of a conversation, not the end of one. Each conversation handled this way compounds our credibility. We stop selling security to the business and start helping the business succeed through security.

Designing Security Products for Humans and AI Agents

Mon, 06 Apr 2026 00:00:00 GMT

AI agents are quickly joining humans as personas that use enterprise security products. Vendors who understand how to support all their users, from analysts to agents, will build products that fit how teams actually work.

Poor usability in a security product often signals that the vendor doesn't understand how their customers actually work. The products that win adoption aren't necessarily the ones with the longest feature lists, but the ones that fit the team's workflow so well that users don't want to give them up.

AI not only makes this gap harder to spot but also requires special attention. Coding assistants produce polished front-ends that make all enterprise products look increasingly alike, so responsive layouts and clean navigation no longer differentiate them. Instead, product managers need to understand how every persona uses the product, including AI agents.

The Next User Isn't Human

AI agents are becoming a critical interface for enterprise products. Most products started as closed, self-contained tools, but market pressure forced vendors to add APIs for customer integrations. Now agents are the next layer, handling configuration, oversight, action, and output consumption.

Products that built their entire interaction model around a visual GUI now struggle to support AI agents. Before AI, vendors created drag-and-drop canvases so enterprise users could design automations without writing code. The approach caught on quickly, but users found the canvases complex and time-consuming. When AI agents offered a simpler path, many users preferred describing their intent to an agent rather than dragging components across a screen. Because these products treated the canvas as the primary interface, their APIs often don't expose the full capability set.

Having a REST API doesn't make a product agent-friendly. REST's small, composable endpoints aren't great for AI agents. Each endpoint's schema consumes tokens in the agent's context window before the agent does any work, and responses return every field, whether the agent needs them or not. Simple tasks require multiple sequential calls, and the agent must pass context between each one.

Products that serve agents well provide dedicated agent interfaces, not just repurposed APIs. Cloudflare's EmDash CMS, for example, ships with MCP, CLI, and LLM-ready documentation, enabling AI agents to manage content alongside human editors.

The Right Interface for Each Persona

Products that present the right interface to each persona win adoption that spreads across the organization. A security exec needs a different view than a SOC analyst, who needs a different workflow than a GRC manager. AI agents are another persona in this mix, with their own requirements for structured data and efficient access. When each role finds value in its own view, displacing the product means a competitor has to win over every persona at once.

Getting personas right demands industry expertise, customer conversations, and product telemetry. Building usable security products starts with deep knowledge of who will use them and how. But talking to customers isn't enough on its own. Usage telemetry reveals which features users adopt, where they encounter friction, and which capabilities they ignore. That data feeds back into the product. More usage generates better telemetry, which drives better features, which drives more usage. Each cycle sharpens the product's fit with how each persona actually works.

Anticipate What Users Need Next

The best products anticipate what each user needs and present it as the default action. For human users, the interface should present the recommended next step with enough context that the user feels confident clicking "OK." The user can adjust, but the default should be right most of the time.

AI agents need the same anticipatory design, delivered through APIs and MCP servers. For example, the REMnux MCP server guides AI agents through malware analysis. It recommends which tools to run, how to interpret output, and when to reconsider conclusions. When the MCP server detects a packed executable, it steers the agent away from tools that won't help. It recommends unpacking first.

Visibility Has to Match the Persona

Anton Chuvakin and Oliver Rochford found that even a few visible false positives can erode trust in correct detections. When products surface every detail behind every automated decision, users stop paying attention, just as they do with excessive alerts.

Transparency matters, but different audiences need different forms of it. For example, when a security tool blocks a suspicious email:

A human analyst might need to know which rule fired, what the ML model flagged, or whether similar messages were also blocked.
An AI agent triaging the same alert needs structured metadata to decide its next autonomous action, not a prose explanation that burns tokens.
A legal team needs documented evidence showing why the product blocked it and whether anyone could have overridden the decision.

Each audience defines "useful detail" differently, and a product that serves only one leaves a usability gap that the others will notice.

The Feature List Doesn't Matter If Nobody Uses It

Product managers who want to treat usability as a competitive advantage should ask these questions about their product:

Does it present the right interface for each persona?
Does it anticipate what users need next?
Does it explain automated decisions in a way that each audience can act on?
Can AI agents interact with it efficiently and effectively?

A product that humans adopt and agents operate has a competitive advantage that a feature list alone can't match.

Awareness Training Won't Protect Employees from Their Own AI Tools

Wed, 01 Apr 2026 00:00:00 GMT

When an AI tool influences an employee's decision, audit logs record the human's action and miss the AI's role. Addressing that blind spot requires escalation procedures and engineering controls that go beyond what awareness programs can deliver.

AI tools that employees use every day shape their decisions, but that influence is hard to recognize. Addressing this through AI awareness training risks repeating the mistakes we made with security awareness. We told colleagues to "be suspicious" of links and attachments they needed for work. We extolled the virtues of vigilance, setting unrealistic expectations rather than explaining a specific process, such as reporting a security anomaly.

Now, as enterprises embed AI into daily workflows, employees build trust in systems that speak insightfully and project confidence. Many organizations offer responsible AI training that covers data privacy, acceptable use, and intellectual property. Employees are told they're responsible for verifying AI output. But accountability rules don't help people recognize when a trusted tool is shaping their judgment.

A large-scale survey found that 66% of respondents rely on AI output without checking its accuracy. Employees using AI tools their organization chose and deployed have even less reason to question the results. The natural response will be to add "be careful with AI" to the awareness curriculum. But "be careful" hasn't worked for us before.

Trusted AI tools are harder to question than trusted colleagues.

An AI tool that helps a person do better work every day earns their trust. That trust amplifies the negative effects of a compromised agent, a poisoned model, or a misaligned recommendation. Even more than phishing emails that appear legitimate, guidance from a trusted tool arrives with credibility already established. For example:

Automation bias research shows that people defer to automated systems even when those systems are wrong.
Researchers found that when professionals challenged AI outputs, the model didn't reconsider. It escalated its rhetoric, a pattern the researchers call "persuasion bombing."
In a clinical study, physicians whose LLM gave erroneous recommendations saw diagnostic accuracy drop by 14 percentage points. More experienced clinicians showed larger drops, suggesting expertise amplifies rather than counteracts AI influence.

When something goes wrong, audit logs miss the AI's role.

Traditional social engineering leaves forensic traces if we know where to look. A phishing email sits in an inbox, a pretexting call shows up in phone logs, and an unauthorized access attempt appears in authentication records.

In most enterprises, AI-driven influence doesn't appear in audit logs. The AI recommends an action, and the employee carries it out. Audit logs of the downstream application capture the employee's decision as a legitimate human action. The AI interaction is rarely linked to the action it influenced, if it's recorded at all. OWASP's Top 10 for Agentic Applications recognizes this issue, describing the agent as an untraceable influence that manipulates humans into performing the final, audited action.

Awareness frameworks don't address AI-driven influence as of this writing. CIS Control 14, for example, trains employees to recognize "phishing, business email compromise, pretexting, and tailgating," all scenarios where an adversary directly targets the employee. It doesn't cover the case where the employee's own tool is the source of influence.

Teach specific procedures, not general suspicion.

Telling employees "don't trust your AI tools" fails for the same reason "be suspicious of links" isn't practical. People who interact with AI tools throughout the day can't maintain a constant state of skepticism. Even employees who know AI can still be influenced by it.

The response to this risk has four parts, and only one of them involves training.

Teach when to escalate, not what to fear. If an AI tool recommends something outside normal parameters or suggests circumventing a process, employees should contact security. Escalating to a person matters more than debating the tool. This mirrors what works for other awareness topics. Tell people when and how to ask for help, not just to "be cautious."

Require confirmation for high-impact actions. Financial transactions, permission changes, and data exports recommended by AI need human confirmation steps that the agent can't bypass. Organizations already require dual approval for wire transfers, and AI-recommended actions with comparable consequences deserve the same control.

Close the audit trail gap. Investigative teams need to see what the agent suggested, not just what the employee did. Without that visibility, they'll attribute AI-driven decisions to employees. This requires working with internal engineering teams and external vendors to implement the necessary logging.

Test AI interactions in exercises. Add AI-driven scenarios to red team and tabletop exercises. Measure whether employees reported anomalous AI behavior, not whether they "fell for it." Phishing exercises should reward reporting over punishing clicks, and AI exercises should do the same.

Awareness training works when it tells people what to do, not what to fear. For AI tools, that means teaching escalation and building the engineering controls that training alone can't replace.

Security Governance at the Speed of Vibe Coding

Mon, 30 Mar 2026 00:00:00 GMT

Employees who've never written code now build production apps using AI, without security review, dependency scanning, or enterprise oversight. The SaaS and DevOps transitions give security teams a starting governance approach for this.

Employees outside engineering now build their own apps using AI coding tools. Developers who use AI for vibe coding present their own governance challenges, but the gap is widest when the builders have no software engineering background at all.

Security leaders have navigated comparable shifts before, though none moved this fast. When SaaS removed IT's role as gatekeeper for software procurement, it took us years to figure out a reasonable governance approach. We ran into similar challenges when DevOps became the way to deploy software. Those lessons give us a starting point for governing vibe coding by non-engineers, even if the timeline to act is shorter.

The SaaS transition offers a governance playbook.

Let's say a marketing analyst uses AI to build an interactive dashboard that consolidates campaign data and surfaces insights. Or a finance team member creates a reconciliation tool that saves hours of manual work. These are the business outcomes we want, and security governance should make them safer, not slower.

During the SaaS adoption wave, we realized that saying "yes, with these guardrails" gave us influence over how adoption happened. We created discovery workflows, vendor review tiers, and procurement processes that offered visibility without unnecessary friction. Security teams that didn't adapt became disconnected from what was running in production.

Most organizations haven't built equivalent mechanisms for vibe coding. No wonder that Retool's 2026 report found that 60% of respondents built software outside IT oversight in the past year. Without discovery workflows or other forms of oversight over AI-built tools, we face the same blind spot we had with early SaaS, but with apps that pop up much faster.

Vibe-coded apps create challenges SaaS governance didn't address.

SaaS governance required solving SSO integration, user provisioning, vendor security reviews, and decommissioning. While these controls still apply to vibe-coded software, they're not enough. We need to address:

Orphaned code at scale: When the person who built a vibe-coded app changes roles or leaves, the app loses its owner. Unlike SaaS, where the vendor maintains the product, these apps usually lack the support structure or personnel. They sit in production, accumulating tech debt, with no one responsible for patching, updating, or retiring them. The risk extends beyond security, since a business process that depends on an unmaintained tool is an operational liability.

A confidence-competence gap: Stanford researchers found that developers using AI assistants wrote less secure code while rating their own output as more secure. The people who trusted AI the most produced the worst security outcomes. Non-developers building apps with AI have even less ability to design and implement with security, reliability, and maintainability in mind.

No security input in the creation process: SaaS vendors typically involve security experts and undergo third-party testing. Apps vibe-coded by employees skip every traditional security practice, including threat modeling, code review, and dependency scanning.

Unmanaged hosting environments: Traditional software, including SaaS, runs on managed, secured, and monitored infrastructure. Vibe-coded apps often end up on platforms like Replit that the organization hasn't vetted and doesn't monitor.

Classic governance approaches assume someone vetted the vendor, reviewed the code, maintains the software, manages the infrastructure. Vibe-coded apps invalidate all four assumptions at once.

Security adapted to DevOps velocity. We can adapt again.

The challenges above look overwhelming, but security teams have adapted to comparable shifts before.

When continuous deployment became mainstream, we wondered how we'd keep up. Zane Lackey and Rebecca Huehls made the case that security teams had to abandon the gatekeeper mentality. As Etsy's first CISO, Zane saw developers deploying code dozens of times a day, which was uncommon at the time. His team learned that the same velocity that overwhelmed traditional reviews let them patch vulnerabilities in minutes instead of waiting for quarterly releases. Catching and fixing problems fast was better than trying to prevent every issue before deployment.

Vibe coding demands a similar shift. Pre-approval gates don't work when non-developers build apps outside traditional workflows. We need guardrails embedded into the way people already operate and visibility to spot what slips through.

Govern through guardrails, not gates.

Governing vibe-coded apps requires a single owner with authority across IT, security, legal, and privacy. Without that, apps that fall between team jurisdictions get no oversight at all. With ownership in place, security teams can adapt governance principles from SaaS oversight and DevOps, starting with visibility and building toward automated controls:

Discover and catalog vibe-coded tools: We can't expect employees to register their apps on their own. Automate discovery through network monitoring, endpoint agents, and platform-level reporting from approved hosting environments, starting with what current tools can already surface. Aim for the inventory to capture what data each tool accesses, where it runs, what permissions it has, and who owns it.

Prepare for orphaned apps: Design the app inventory to track who built each app and when it was last updated. Build a process to flag apps for review when their builders change roles or leave, so someone can inherit or retire them before they become unpatched liabilities. Without owners to enforce decommissioning, apps that fall between team jurisdictions will get no oversight.

Use tiered governance: Not every vibe-coded tool carries the same risk. A dashboard that visualizes public marketing data needs less oversight than a tool that processes financial records. As new apps enter the inventory, classify them by the data they access and the infrastructure they touch. Low-risk apps get basic cybersecurity support, while sensitive-data activities require pairing with security or IT experts.

Automate security scanning for AI-generated code: Non-developers won't run security tools on their own, so the tools need to run without them. Build dependency scanning, secret detection, and permission constraints into the platforms employees already use to create and deploy their apps.

Control access to company data: When vibe-coded apps connect to internal resources, the organization controls the authentication. Aim to provide scoped OAuth tokens instead of broad API keys so each app can access only the data it needs, regardless of where it runs.

Vibe coding won't give us the years we had when adapting to SaaS and DevOps. Security leaders who act now will calibrate acceptable insecurity on their terms rather than becoming the last to learn what's already running in production.

Scope Security Assessments for Attack Paths, Not Org Charts

Sat, 28 Mar 2026 00:00:00 GMT

When assessment scope follows organizational lines, gaps open where team boundaries meet and real attackers don't stop. Pulling adjacent teams into the scoping conversation and following attack logic closes those gaps.

If scoped correctly, pentests and other security assessments address compliance requirements and improve defenses. However, determining the project's scope can be a challenge. If we define it too narrowly, we'll miss vulnerabilities that a real attacker could've exploited. But if we go too broad, we inflate costs and put relationships at risk. These challenges intensify as organizations begin using AI for assessments, since agents can interpret rules of engagement more literally and operate faster than a human tester.

See Where Scope Breaks Down

We often think of a security assessment in terms of an "application," "infrastructure," or "corporate" pentest because different teams maintain these resources. The funding comes from different budgets, and different people get stressed about the findings. As a result, our scoping decisions are anchored in "who's responsible?" factors rather than "what can an attacker reach?"

Such constraints prevent the assessment from mimicking how real attackers operate. A pentest focused on corporate resources might target the identity management system. But it would stop short of following a weakly controlled admin account into the customer support environment, which is a different application, scoped for a separate pentest.

Shared responsibility models divide ownership across teams, so the assessment's realistic scope spans multiple groups. Let's say a pentest focused on a web application discovers that a service account has overly permissive cloud IAM permissions. This allows access to data stores, internal services, and production infrastructure well beyond the web app itself. Is that an application finding or a cloud infrastructure finding? The app team didn't configure IAM, and the cloud team didn't build the app. Which team might feel blamed for the issue? Which is responsible for getting it addressed?

A human tester who encounters ownership and scope uncertainties might take context into account and, when necessary, check with the client. An AI agent running the same assessment might push through the boundary or halt entirely, depending on how literally it interprets the scope statement. Either outcome creates problems that detailed upfront scoping could've prevented.

Follow the Attack Logic

Political boundaries won't disappear from security assessments scoped along budgetary or organizational lines. But with the right planning, we can still move the assessments closer to how attackers actually operate.

"Test what an attacker could reach starting from the web app" produces more realistic findings than "test the web app." Attack-path language helps the assessment team flag what they discover at the edges, even when the formal scope can't span every team's resources.

Bring stakeholders from adjacent systems into the scoping conversation, not just the commissioning team and the provider. The scope doesn't need to expand, but the conversation does. The people defining the scope should understand the systems the assessment might touch, so they aren't surprised when findings reach their systems. These scoping conversations surface ownership disagreements before testing forces the issue, when they're easier to resolve.

Upfront planning matters even more for AI-driven assessments. Technical boundaries such as systems, network segments, and data classifications translate into rules the agent can follow. Organizational boundaries, especially when they include political considerations, don't. Agree on a plan with the teams involved, then translate it into operating procedures the AI agent can follow.

We can plan individual assessments across a year or multi-year cycle, so they collectively cover the threat model. Design intentional overlap where team boundaries meet. If the cloud infrastructure review examines the same service accounts a web app pentest touched, that overlap is a feature, not redundancy. Findings from one assessment inform the next one's scope, building a feedback loop across engagements.

Assign a person or function to review findings across all assessments and route cross-boundary discoveries to the right teams. Without this, people will assume that someone else will handle them. These findings should trigger a defined workflow rather than an ad-hoc conversation about whose problem it is.

A scope statement is only as useful as the agreement behind it. Before your next security assessment, consider whether the people defining the scope understand what an attacker could reach, not just what the commissioning team owns. Shape that agreement around the attack paths, not the org chart.

Understand the Reality of the SOC 2 Checkbox

Tue, 17 Mar 2026 00:00:00 GMT

SOC 2 standardized security reporting, but it left the vendor in control of the system boundary and auditor selection. Understanding that structural gap helps vendors and buyers get the most value from the framework.

In 2010, I wrote about companies placing too much trust in providers' SAS 70 reports. At the time, Gartner called the widespread misuse "deceptive and harmful." Chris Schellman, who had led over 500 SAS 70 audits, clarified that the industry had been using it for something it was never built for. Turns out the AICPA was already building a replacement; SOC 2 was born.

SOC 2 introduced prescribed trust criteria, required management accountability, and gave buyers a basis for risk-informed decisions. Fifteen years later, familiar patterns have resurfaced.

SAS 70 wasn't meant for security.

The AICPA issued SAS 70 in 1992 as a framework for auditors to report on controls at service organizations that could affect customers' financial statements. Then Sarbanes-Oxley arrived in 2002. Public companies needed their vendors to demonstrate control effectiveness, and SAS 70 became the default.

Organizations began requesting and marketing SAS 70 reports for security assurance, well beyond the standard's original design. SAS 70 had no prescribed control criteria. The provider chose which controls to include, and the auditor evaluated only what the provider put forward.

By the late 2000s, the market had turned "SAS 70 certified" into marketing language for something that was neither a certification nor a security standard. The gap between what SAS 70 was and how the market used it had grown too wide to ignore.

SOC 2 introduced the missing structure.

The AICPA issued SSAE 16 in 2010 (superseded by SSAE 18 in 2017), replacing SAS 70 with three distinct report types. SOC 2 addressed the security gap the market had tried to cover with SAS 70. SOC 1 continued financial controls reporting, and SOC 3 provided a public-facing summary of SOC 2.

Where SAS 70 let providers choose which controls to include, SOC 2 introduced the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. Unlike SAS 70, the new report required a written management assertion, making organizations formally accountable for the report's claims.

SOC 2 became table stakes.

Enterprise buyers needed evidence of vendor security controls, and SOC 2 filled that gap as the cloud market grew. The framework's adoption accelerated when compliance automation tools such as Vanta and Drata made it accessible to startups and smaller companies that previously couldn't afford it.

Lower barriers changed what SOC 2 meant in practice. The report appeared in vendor questionnaires and RFPs as a checkbox, and for many companies the goal shifted from demonstrating a strong program to passing a binary check.

As a result, merely having a SOC 2 report no longer distinguishes a company. It's the baseline expectation for SaaS providers selling to enterprises.

SOC 2 concerns start to surface.

Broader adoption put more weight on SOC 2's structural gaps. Despite the improvements over SAS 70, the audited organization still defines the system boundary and selects the auditor. These choices drive the concerns I hear from fellow CISOs:

The Trust Services Criteria prescribe what to evaluate, but the provider decides which systems and services the report covers and how controls address each criterion. Organizations have an incentive to optimize for controls that produce favorable evidence.
The rigor of examinations varies across auditors. Auditors who work quickly and keep clients satisfied win repeat business at the expense of examination rigor. As a result, promises of "fast and easy" threaten SOC credibility.

The AICPA has responded by cataloging common examination deficiencies and requiring peer reviewers to examine firms' SOC work. However, I'm not aware of any firm that has faced disciplinary action for lax examinations.

Use SOC 2 intentionally.

SOC 2 addressed real weaknesses in how the market used SAS 70, but the old pattern of treating reports as checkboxes persists.

SaaS companies have an incentive to draw scope boundaries that exclude their weakest processes and time observation windows to avoid known-bad periods. Controls might exist during the examination and atrophy once the report ships. These practices are the predictable result of letting the vendor define the scope and select the auditor.

Vendors that want their SOC 2 to carry weight should design controls around their actual product and threat model, not a default compliance template. And they should hold their auditors to high standards and avoid misrepresenting where the program actually stands.

From a buyer's perspective, a SOC 2 report from a trusted audit firm offers visibility into a vendor's security program. But due diligence requires not only reading control statements, but also asking which systems and processes were excluded from scope. If that boundary doesn't match what you actually rely on, the assurance doesn't either.

Most Cybersecurity Products Aren't Platforms and It's OK

Mon, 16 Mar 2026 00:00:00 GMT

The test for a genuine platform is whether each new addition makes everything else more valuable, not just whether products share a brand or console. Let's draw a distinction between a platform and a suite.

Many cybersecurity startups refer to their products as a platform. That aspiration can shape product strategy and motivate a company to think big. But the label carries a specific meaning. Misapplying it means investing in ecosystem infrastructure that the architecture can't support while starving the integration work that actually makes a suite competitive.

A platform creates self-reinforcing value.

Each new addition to a platform delivers more value than it would as a standalone offering by plugging into an established ecosystem.

Network effects, the dynamic that the book Platform Revolution identifies as the primary engine of growth, create a virtuous cycle where increased participation generates compounding value. In tech platforms, this plays out through shared foundations:

Products or participants share data, so one's telemetry enriches another's analysis.
Shared identity eliminates onboarding friction.
Distribution advantages let new features reach an established base instantly.
Shared data trains AI models whose accuracy improves as more products contribute telemetry.

However, the cybersecurity industry uses "platform" differently. Gartner's cybersecurity platform consolidation framework treats platforms as consolidated security capabilities under a single vendor. Palo Alto Networks describes platformization the same way. These definitions all describe a suite.

Suites consolidate. Platforms compound.

In a suite, each module adds a fixed increment of value. On a platform, each addition makes everything else on it more valuable. That holds regardless of who builds the additions. The classic examples are multi-sided platforms in which third parties create value that the platform owner doesn't fully control.

Bill Gates reportedly offered a well-known test for recognizing platforms. A platform, he said, is "when the economic value of everybody that uses it exceeds the value of the company that creates it." That formulation captures platform dynamics with heavy third-party participation. But the self-reinforcing dynamic doesn't require outside participants.

If your next product gains meaningful advantages from what's already at the foundation, you have platform dynamics:

A suite solves the complexity problem. Customers want fewer vendor relationships, tighter integration between security functions, and a single console for operations.
A platform goes further. Shared foundations enable the vendor's own teams and external partners to build capabilities that reinforce one another, delivering more than either could independently.

Platform dynamics emerge from architectural decisions, ecosystem participation, and sustained investment in shared foundations. A vendor can't simply declare itself a platform, and most that try end up with a suite.

Platform dynamics require deliberate architecture.

The companies that have built genuine platform dynamics did so through specific architectural choices. CrowdStrike shows perhaps the clearest example in cybersecurity:

CrowdStrike built a single-agent architecture with a unified data layer, where a single sensor feeds endpoint data to every module on the platform.
When CrowdStrike launched Falcon Cloud Security and Falcon Identity Protection, those modules ran on the same sensor and drew on shared telemetry, reaching the existing customer base. Standalone competitors had to build those capabilities from scratch.
Partners can extend the platform through CrowdStrike's Marketplace and Falcon Foundry, building applications that access the same data and reach the same customer base.

Not every network that looks like a flywheel behaves like one. Okta's Integration Network connects over 7,000 applications, but most are standardized SSO connectors that follow the same pattern regardless of who builds them. Adding app number 7,001 doesn't make existing integrations more valuable. The platform dynamic is real, but it lives in the identity data layer, not the integration count:

Once an organization adopts Okta as its identity provider, each additional Okta capability (access reviews, lifecycle management, governance) draws on that shared identity foundation. A standalone competitor would have to rebuild that context from scratch.
Okta's threat intelligence improves as more organizations contribute identity signals, creating a data advantage that a competitor can't replicate through features alone.

Okta's identity expansion is suite behavior, while its shared identity data layer is platform behavior. The two can coexist. Palo Alto Networks shows this pattern at a larger scale:

The company assembled its security portfolio largely through acquisition, consolidating network security, cloud security, and security operations under one vendor. That's suite behavior, and it's effective, because customers get fewer vendor relationships and tighter integration.
But Cortex XSIAM collects telemetry from endpoint, network, identity, and cloud data sources and correlates them in a shared layer. When firewall data from Strata enriches threat detection in Cortex, both products become more valuable. That's platform behavior.

Unifying the data layer is the hard part. Frank Wang describes this common failure as the "middleware trap," which is putting a shared console over separate acquired backends without unifying the underlying data models. Palo Alto avoided that pattern by enforcing Cortex Data Lake as a shared foundation early in its acquisition integration, turning what could have been suite consolidation into genuine platform investment.

Platforms are rare because declaring one is easy and building one is hard. Even by a generous definition, most platform attempts across industries fail within five years, often because they can't attract participants to both sides of the flywheel simultaneously.

Not every buyer needs a platform. When the security team evaluating your product has three analysts and no developers, ecosystem extensibility is overhead they didn't ask for.

Build for the dynamics you actually have.

If you're building a suite, your competitive advantage comes from how well your components work together, not from ecosystem gravity. Design for integration depth and operational simplicity. Don't overinvest in marketplace features or partner programs that you can't support, because those investments drain resources from the integration work that actually differentiates a good suite.

If you're building toward a platform, you need shared architectural foundations that create compounding value, not just a shared brand or console. That might be a shared data layer where each product's telemetry enriches the others, or an integration network where each new participant increases value for everyone already connected. Build those foundations for your own product expansion first, then consider opening to partners once the internal foundation proves its value.

If you're deciding which to pursue, start with your core product. Does each new addition gain a meaningful advantage from what's already there, or is it essentially standalone work under a shared brand? If additions reinforce each other, you have platform dynamics. If they don't, you have a suite. Either is a legitimate path, and some companies will find both, with suite dynamics in parts of the portfolio and platform dynamics in others.

Build Better Security Product Strategies Using Your AI Tool

Sat, 14 Mar 2026 00:00:00 GMT

Modern AI tools can help evaluate a security product's strategy, but only if they have the right criteria. An MCP server with domain-specific frameworks gives your AI agent the practitioner knowledge to test strategic fit, evaluate competitors, and assess vendor viability.

AI agents, with the right guidance, can catch strategic contradictions, separate verified facts from marketing claims, and stress-test key assumptions. Point yours at my MCP server to give it access to product strategy frameworks that generic AI doesn't have. Whether you're building your own product, evaluating a startup vendor, or sizing up competitors, the frameworks adapt to your context.

It incorporates my guide to creating cybersecurity products and insights I've published over the years as a builder and consumer of cybersecurity products. Your AI agent applies this practitioner knowledge to what it knows about the company, stage, and market.

A Layer on Top of Generic AI

Ask a generic AI to review a product strategy and you'll get textbook advice. "Consider the target market. Review the revenue model." It won't catch that your $7,200/yr deal size contradicts the Fortune 500 sales motion, or that per-seat pricing undervalues security products when small teams protect large asset inventories.

When you guide the AI tool with specific criteria, expectations, and templates, it identifies such contradictions. The AI tests whether the pricing, positioning, go-to-market, and trust readiness actually support each other. That guided approach also adjusts to the company stage, so an early-stage startup gets different questions than a growth-stage company. It incorporates insights from my product management articles.

AI-Driven Product Analysis in Action

The frameworks are useful for evaluating companies you're considering buying from, comparing against, or investing in. To demonstrate, I used this approach to create structured profiles of the RSAC 2026 Innovation Sandbox finalists. Each profile covers eight market-readiness dimensions, from problem clarity and capability depth to funding efficiency and defensibility. The profiles separate verified facts from marketing claims and score each company on a consistent rubric. You can apply the same approach to evaluate whether a startup vendor will still be around in two years, or to compare how competitors position themselves in the market.

The frameworks also help you develop and stress-test your own product strategy through interactive conversations. The AI applies practitioner knowledge to challenge your assumptions about pricing, positioning, and go-to-market readiness. Below is a simulated conversation to demo such capabilities. You can open it in a new tab.

Codified Strategy Expertise

To help you conduct such analysis, my MCP server provides capabilities that help your AI agent reason through the analysis in a structured, methodical way:

Strategy creation from your context: Your AI receives frameworks for building a product strategy that adapts to your company's stage and situation. It covers market positioning, capabilities, pricing, sales motions, delivery, trust, and team planning.
Constructive feedback on strategy drafts: Your AI evaluates an existing plan against specific criteria, including pricing-positioning alignment, go-to-market readiness, trust gaps, and team expertise.
Multi-company competitive analysis: Your AI receives structured comparison frameworks with scoring rubrics for evaluating competitors, market segments, or investment cohorts side by side.
Topic-specific strategic guidance: Your AI receives focused guidance when you need depth on a single area, such as pricing models, compliance readiness, competitive moats, or platform strategy.

The MCP server is designed to preserve confidentiality. Your AI agent doesn't send your documents or proprietary details to my server, and the server doesn't log conversation contents.

How to Connect Your AI Tool

To give your AI tool access to these security product frameworks, point it at my MCP server https://website-mcp.zeltser.com/mcp. For example, run this command for Claude Code:

claude mcp add zeltser-website --transport http https://website-mcp.zeltser.com/mcp --scope user

Of course, the MCP server also works with Claude Desktop and other MCP-compatible tools. (By the way, the same server provides incident response writing guidance and text search across my website's security content.)

If you prefer to build your own tooling that incorporates my security product guidance, you can download my product insights as a YAML file, which your software can parse locally and use in a way that fits your needs. If you want to codify your own domain expertise for AI consumption, the MCP Expertise Toolkit that powers this server provides a template for building your own.

Key Takeaways

The frameworks test whether the company's pricing, positioning, and go-to-market actually support each other, whether you're evaluating your own strategy or someone else's.
You can sort competitive claims by evidence quality, separating verified capabilities from marketing language when assessing vendors, competitors, or investment targets.
Guidance adjusts to the company stage and draws on vertical market analysis when possible.
Your strategy data stays local and isn't sent to my MCP server to preserve confidentiality.

Competing in Endpoint Security: A Guide for Startups

Thu, 12 Mar 2026 00:00:00 GMT

There are areas where endpoint security startups can build viable, useful products, but those openings shift as adjacent categories converge and incumbents absorb new capabilities. Founders, buyers, and investors need to distinguish a viable product strategy from a feature waiting to be bundled.

Endpoint security startups face a dilemma. Build broadly, and you compete against platforms with more data, broader distribution, and deeper pockets. Build narrowly, and you risk becoming a feature that those platforms develop before you gain traction.

If you are creating an endpoint security product, this guide will help you navigate these market dynamics. If you are evaluating or investing in one, the same questions will help you assess whether the startup has found a defensible position.

Prevention is baseline, platforms are entrenched.
The gaps exist, but they shift.
Adjacent categories are converging with endpoint security.
AI and data advantages grow with scale.
Incumbents own the budget and the channel.
Defensibility determines the exit terms.
A rubric for the startup's position.

Prevention is baseline, platforms are entrenched.

Dominant endpoint security platforms have absorbed what were once separate product categories and set a high bar for newcomers. Microsoft bundles Defender for Endpoint with its E5 licensing and holds the #1 market share according to IDC. Gartner began evaluating EDR alongside endpoint protection, and Forrester retired its standalone endpoint security evaluation entirely. Prevention and detection are now table stakes.

Customers are unlikely to switch from their endpoint platform, even after catastrophic failure. The CrowdStrike 2024 outage affected ~8.5 million Windows systems, yet CrowdStrike maintained 97%+ gross customer retention. If you have a new endpoint security product, be certain it offers significant differentiation over these entrenched incumbents.

Questions on platform differentiation:

How does it differ from modern endpoint protection platforms such as Microsoft Defender, CrowdStrike Falcon, and SentinelOne Singularity?
Does it aim to replace existing endpoint security solutions, or will it complement them? If the two will coexist, how well do they integrate?
Does the product protect beyond traditional endpoints, such as cloud workloads, containers, browsers, AI agents, or firmware?
Does it overlap with adjacent categories such as browser isolation, application allowlisting, or data loss prevention?
How many additional agents, consoles, and integrations will the SOC need to manage? Does the product reduce operational load or add to it?

The gaps exist, but they shift.

Platform vendors spent billions in recent years acquiring startups to fill gaps in their endpoint coverage, validating that the window of opportunity is substantial. But these windows close. Application control was once a standalone category before platforms absorbed it. EDR was a niche that became the standard. Browser security and supply chain security are today's gaps, but they may be tomorrow's bundled features.

Platforms cannot build niche capabilities as fast as they can acquire them. They optimize for breadth and allocate engineering capacity to current customers. When customers demand a capability, building from scratch can take years, while acquiring takes months. The startup, in turn, eventually needs distribution and resources it cannot obtain on its own.

Recent acquisitions and funding rounds suggest where some of the gaps are:

Agentic AI security: Palo Alto Networks acquired Koi for a reported ~$400M.
Browser security: CrowdStrike acquired Seraphic for ~$420M.
Runtime memory protection: Prelude Security raised $45M to address in-memory attacks that evade file-based detection.
Continuous identity: CrowdStrike is acquiring SGNL for ~$740M to pair endpoint risk signals with access control across human, non-human, and AI identities.
Firmware and below-OS security: Eclypsium raised $45M in an effort to secure infrastructure firmware.
AI agent security: SentinelOne acquired Prompt Security and Zenity raised $38M in a Series B to secure autonomous AI agents.

Questions on gap durability:

Which existing vendors are the startup's closest competitors, even if they use a different approach?
How long before a platform vendor builds or acquires a competing capability in the startup's niche?
If a platform vendor shipped a "good enough" version of the product's capability tomorrow, what would the startup retain that they cannot replicate?
Is the gap the startup is targeting driven by a structural limitation of platforms, or by a priority they have not yet addressed?

Adjacent categories are converging with endpoint security.

A startup building near the boundary of endpoint security faces competition from two directions. Adjacent categories are expanding into threat detection. Also, endpoint platforms extending into device management, DNS, and browser control.

MDM/UEM vendors already have agents on endpoints and are adding security capabilities. Jamf grew its security ARR to $216M, up 44% year-over-year, reaching 30% of total revenue by Q3 2025. Francisco Partners subsequently acquired Jamf for $2.2 billion, validating the category's strategic value. Other device management vendors are making similar moves:

Kandji, which had raised $100M at an $850M valuation, expanded from Apple MDM into EDR, vulnerability management, and compliance automation in October 2025.
NinjaOne raised $500M at a $5B valuation for what it calls "autonomous endpoint management," expanding from RMM and patch management into a platform that increasingly overlaps with endpoint security workflows.
Microsoft's Intune integrates directly with Defender for Endpoint to enforce compliance policies based on real-time device risk, extending the bundling dynamic into the device management layer.

Automated patching, configuration enforcement, and vulnerability management fill the space between what MDM manages and what EPP detects. Automox raised over $150M to consolidate these functions into a cloud-native product, while Action1 raised $20M for cloud-native patch management. Larger players such as Tanium (valued at $9B) also operate here.

Beyond device management, DNS filtering is an enforcement layer that major endpoint security platforms do not cover natively, creating space for startups that can integrate DNS-layer protection into broader endpoint strategies:

Cisco Umbrella's legacy client reached end-of-support in April 2025, forcing customers to migrate to Cisco Secure Client and giving competitors an opening during the transition.
DNSFilter, which raised $50.5M total, targets MSPs with multi-tenant management and machine-learning domain categorization, a distribution model that parallels the MSP-first approach discussed in the SMB security product guide.
Infoblox, which manages core DNS and network services for enterprises, has extended into protective DNS by adding threat intelligence and machine-learning analytics capabilities.

Enterprise browsers represent a third convergence vector, one that could reduce dependency on OS-level endpoint agents:

Island reached a ~$4.8B valuation with $810M in total funding, positioning its enterprise browser to consolidate web filtering, isolation, and zero-trust access into a single solution.
Palo Alto Networks acquired Talon for a reported $625M and integrated it into Prisma SASE as a browser-based enforcement point for unmanaged devices.
Google launched Chrome Enterprise Premium, adding threat protection, data loss prevention, and zero-trust access controls directly into the browser.

For endpoint security startups, browsers are both a risk (if enforcement shifts to the browser, the OS-level agent becomes less critical) and an opportunity (browser telemetry as a data source that endpoint platforms do not yet capture well).

Questions on adjacent category dynamics:

Is the startup building in an adjacent category or competing against vendors expanding from one? Does the customer already use an adjacent platform that bundles security features?
Does the product depend on a platform (MDM, DNS infrastructure, browser) that is adding its own security capabilities? If so, what happens to the startup's position when that platform ships a competing feature?
Are adjacent vendors adding security faster than security platforms are adding adjacent capabilities, or the reverse? How does this affect the startup's timeline?

AI and data advantages grow with scale.

Dominant endpoint platforms benefit from network effects that grow with every deployment. CrowdStrike's Threat Graph processes trillions of events daily across its entire customer base, and each new customer adds telemetry that sharpens detection for all others. Microsoft processes over 100 trillion security signals per day.

Competing against this scale of data requires different data, not volume:

Halcyon reached a $1B valuation with an architecture trained exclusively on ransomware attack patterns, a specialization depth that general-purpose platforms optimize away.
In contrast, Deep Instinct raised $322M to compete on general endpoint detection with deep learning and has since pivoted to data security, illustrating the difficulty of matching the platforms' breadth with funding alone.
Cybereason's trajectory, discussed below, reinforces this pattern.

Other opportunities to compete with platforms are in the areas they're not designed to cover, such as the proliferation of AI agents in enterprise environments. This category is early enough that the incumbents do not yet have a data moat, which creates a window similar to what CrowdStrike found when EDR was nascent.

Questions on AI and data strategy:

What proprietary data can the startup accumulate that incumbents with larger customer bases will find difficult to replicate?
Does the product's AI advantage target a specific threat category, or does it compete broadly against platforms with vastly more training data?
If the product depends on third-party AI models, what percentage of its value proposition survives if a platform vendor adds similar capabilities?
If the startup is targeting an emerging category such as AI agent security, can it build a data advantage before the incumbents enter?

Incumbents own the budget and the channel.

A startup's competition is often not another vendor but an existing budget commitment. Enterprise buyers typically operate under multi-year contracts, and displacing an incumbent means justifying the switching costs, staff retraining, and software redeployment. Even at renewal, cyber insurance discourages change. Many insurers now list EDR among baseline underwriting requirements, and a buyer already satisfying that requirement with an existing tool has little incentive to risk a transition.

Prospective customers may already have endpoint security through their Microsoft E5 agreement, making Defender a competitor they perceive as "free." Microsoft has extended this bundling to AI capabilities by including Security Copilot in E5 at no additional cost, further raising the floor that startups must clear. However, E5's Security Copilot allocation is capped at modest levels, creating room for startups offering deeper AI capabilities.

Distribution is the other constraint. At scale, VARs, MSSPs, and MDR providers control which products enterprise buyers see and how fast they get deployed. An MDR vendor can bypass a startup's product entirely by bundling technology with staffing into a managed service, so the buyer never evaluates standalone alternatives. For example, Sophos acquired Secureworks for $859M and defends over 18,000 MSP-managed customer environments. A startup selling to those SMBs must convince the MSP, not the end customer.

Questions on budget and distribution:

Is the prospective customer under a multi-year endpoint security contract? If so, when does it expire, and what would justify an early switch?
Does the customer's cyber insurance already require EDR? If so, what argument would persuade them to switch from a tool that already satisfies that requirement?
Is the customer already using Microsoft Defender through an existing E5 agreement? If so, what is the startup's displacement argument?
Would the customer spend on an MDR service rather than a standalone product? If so, how does the startup's offering compare to that alternative on a total cost of ownership basis?
What is the startup's go-to-market strategy? Direct enterprise sales, channel partnerships through MSSPs and MDR providers, or product-led growth?
If the startup targets SMBs rather than enterprises, how does its strategy account for the different distribution and pricing dynamics?
Does the product address a regulatory requirement (NIS2, DORA, SEC disclosure rules) that existing platforms do not satisfy?

Defensibility determines the exit terms.

Building a new endpoint platform is exceptionally difficult today. For most startups in this space, the realistic best outcome is acquisition on favorable terms. The difference between a strong exit and a distressed sale comes down to defensibility, timing, and leverage.

Today's incumbents are harder to displace than the previous generation. Symantec and McAfee held 72% combined AV market share in 2005 but were architecturally locked into on-prem, signature-based detection.

Today's dominant platforms are cloud- and AI-native and don't carry the architectural debt that created their own opening a decade ago. Displacing them requires either a comparable paradigm shift or a niche they have not prioritized.

The track record is instructive. Cylance pioneered AI-based prevention but was acquired by BlackBerry for $1.4 billion in 2018 and resold to Arctic Wolf for $160 million in 2025, an ~89% decline. Cybereason competed broadly on general EDR, raised over $900 million in total funding, reached a ~$3 billion valuation, and was eventually acquired at a fraction of that peak.

Carbon Black went public, was acquired by VMware for $2.1 billion in 2019, then absorbed into Broadcom's portfolio where it reportedly could not find a buyer willing to meet its asking price. SentinelOne, the sole independent public company from this cohort, has seen its market capitalization fall substantially from its 2021 peak.

Becoming a platform is not impossible, but the conditions that enabled CrowdStrike and SentinelOne to emerge no longer exist in the same form. For most founders, the more honest strategy is to position for strategic acquisition with enough differentiation to have leverage. Security teams evaluating a startup with this trajectory should ask what happens to their deployment after the acquisition closes, and whether the product's roadmap is shaped by customer needs or by exit timing.

Questions on defensibility and exit:

Is the startup positioning for strategic acquisition, or does it have a credible and funded path to becoming a platform? How does that choice shape its product roadmap?
Does the company have sufficient funding to deliver on its promises, or a reasonable path to obtaining it?
Which platform vendors would benefit from acquiring the product's capability, and are there at least two?
What would a customer lose by switching to a competitor or a platform's bundled alternative?
If the startup is acquired, what happens to the customers? Will they face forced migration, feature stagnation, or integration into a platform they don't use?

A rubric for the startup's position.

The following table can help assess whether the startup is pursuing a defensible gap in the endpoint security market. Score the startup against each factor. Those that cluster in the "Needs Rethinking" column are likely building a feature, not a company. My guide for creating cybersecurity products covers the broader product strategy framework that applies beyond endpoint security.

Factor	Defensible Niche	Vulnerable Position	Needs Rethinking
Differentiation	Addresses gap platforms have not covered	Incremental improvement over existing	Feature platforms will bundle
Technical depth	Hard to replicate (novel research, unique data)	Moderate complexity	Commodity technology
Platform relationship	Complementary; platforms want to acquire	Ambiguous; could coexist or conflict	Directly competitive with bundled feature
Independent evidence	Validated by MITRE, AV-Comparatives, or incidents	Supported by analyst coverage	Supported only by marketing
AI/data advantage	Proprietary data flywheel that compounds with customers	Dependent on third-party models or public data	No data advantage over platforms
Acquirer interest	Multiple platforms bidding for the capability	Niche interest	No clear acquirer
Founding team	Shipped endpoint security products before	Adjacent security experience	No relevant domain experience