Build vs. Buy is No Longer a Binary Choice

Russell Miller

No items found.

For years, the build vs. buy decision in cybersecurity followed a predictable logic: buy established tools, accept their limitations, and move on. Building custom security tooling was expensive, slow, and usually reserved for the largest organizations with dedicated engineering resources. Everyone else bought what was available and worked around the gaps. With the rise of AI and vibe coding, that logic is breaking down.

Organizations are building more than ever. A 2026 report by Retool found that 35% of enterprises have already replaced at least one SaaS tool with custom-built software, and 78% expect to build more internal tools this year. The driving force is simple: AI-assisted development has compressed timelines from months to days, and made custom tooling accessible to teams that couldn't have attempted it before.

But the real shift isn't just that building has gotten easier. It's that the traditional build vs. buy framing has become the wrong question entirely.

Enzo, Token Security's AI-native application builder, is designed for exactly this moment. It lets security teams build custom identity security applications on top of a live NHI and agent identity data foundation, using natural language, in minutes, without managing integrations themselves. It's not a binary choice. There is a third option: build on an existing foundation. This post argues that the option is becoming the dominant pattern in enterprise security. Part 2 shows what it looks like in practice.

Why "just buy it" is no longer enough

The case against defaulting to purchased security tools isn't primarily about cost or capability. It's about fit. Every organization's identity environment is structurally unique. Different cloud footprint, different SaaS applications, different engineering practices, different AI agents operating across systems, different compliance requirements. Off-the-shelf identity security platforms were built around the assumption that a fixed set of dashboards and workflows could address this variability. Increasingly, they can't.

The scale of non-human identities and AI agents makes this worse. NHIs now outnumber human identities 82 to 1. Service accounts, API keys, secrets, credentials, and a growing population of AI agents are accumulating at a pace faster than any static tool can track, and no two organizations accumulate them in the same way. A vendor roadmap designed for the average customer isn't suited to your environment.

The result is a gap that most identity security teams know well. It's not a visibility gap. Modern platforms are actually quite good at showing where risk exists: excessive privileges, dormant accounts, over-permissioned service accounts, AI agents with production access, orphaned credentials. Security teams can see the problems.

The gap is operationalization. When a CISO asks "Show me every dormant admin account across AWS and Azure that hasn't been used in 90 days, grouped by business unit, with remediation recommendations," most teams can't answer that directly inside their tooling. They export data to a spreadsheet. They write a one-off script. They open a feature request and wait for engineering or the vendor roadmap to catch up. Meanwhile, the risk stays live.

Why "just build it" has its own cost

The obvious answer sounds like: build it yourself. And today, with AI-assisted development, the engineering barrier is genuinely lower than ever. Code that would have taken a team weeks can be generated in hours. But there's a cost most people don't account for: the data layer.

Building a useful security application isn't just about writing logic. It's about connecting that logic to live, accurate, normalized identity data. That means integrating with cloud providers, secret managers, SaaS applications, CI/CD pipelines, agent frameworks, and on-premises systems, and keeping those integrations current as environments change. It means normalizing data across different schemas and systems so that a query such as "all service accounts with production access" means the same thing across AWS, Azure, GitHub, and Salesforce.

Without that foundation, custom-built tools are built on stale exports and fragile point-in-time scripts. They answer questions once, not continuously. They break when upstream systems change. And they require ongoing maintenance that pulls engineering resources away from other priorities.

This is what most "just build it" advocates underestimate. The hard part isn't writing the code. The hard part is safely connecting that code to live enterprise identity data at scale.

The right question: which layer should you own?

The build vs. buy framing assumes two options. The reality is a spectrum, and the question that actually matters is: at what layer do you build?

The broader market is converging on a clear pattern: buy the foundation, own the operational layer that differentiates you. For AI development, this looks like buying the intelligence layer (open-weight models, inference infrastructure) and building the proprietary data and routing layers that reflect your specific business. The same logic applies to identity security.

The foundation of identity security is the data layer: continuous discovery, cross-environment normalization, integration with cloud, SaaS, and agent frameworks, and correlation of relationships among identities, permissions, and access paths. That work is hard, expensive to maintain, and requires years of specialized engineering to get right.

The differentiation lives in what you do with that data: the workflows, applications, reports, and automations tuned to your organization's specific risk model, policies, compliance requirements, and operational structure. That's where custom tooling pays off, and that's exactly what most security teams can't build fast enough using traditional approaches.

A practical framework for the build versus buy decision

The "it depends on the layer" answer is correct but not complete on its own. Here is what the decision actually looks like:

Lean toward buying when the problem is structurally the same across organizations. Standard access certification, basic privilege reporting, off-the-shelf compliance workflows: these are commodity problems. The vendor has already solved them, and the ROI of building your own version is low. Buy when speed matters more than fit. If you need coverage in weeks, a purchased tool with its defaults is faster than anything you could build. And buy when you don't yet have the underlying data infrastructure. Building useful security applications requires live, normalized identity data across your full environment. Without that layer, most of your "build" effort goes to data plumbing rather than actual security logic.

Lean toward building when your environment is specific enough that no vendor's default workflows were designed for it: combinations of cloud providers, SaaS applications, on-premises systems, and agent frameworks the platform didn't anticipate. Build when you need continuous, live data rather than periodic snapshots. Risk in motion is not caught by queries against yesterday's export. Build when your security model depends on logic that crosses systems in ways no vendor has prebuilt, correlating AI agent permissions with secrets access, ownership, and the business applications those agents can reach. And build when the vendor roadmap moves too slowly for your risk environment. Waiting six months for a feature while a gap stays open is not a viable security posture.

In practice, the answer is almost always both. No security team builds its own discovery engine, normalization pipeline, or integration library from scratch. No purchased platform perfectly reflects your organization's risk model, compliance requirements, or operational structure. The question is which layers you buy and which you own. Buy the depth of expertise that took years to build. Build the operational layer that reflects your environment. The organizations that get this right move fastest when their environment changes, because they own the part that needs to adapt.

The extensibility imperative

There is a broader product design argument underneath the build vs. buy question, and it matters for how security teams should evaluate what they buy.

For most of the last decade, enterprise security platforms competed on coverage and visibility. The product question was: how much can we see? The implicit assumption was that seeing risk was the hard part, and organizations would figure out what to do with it. That assumption no longer holds. Visibility is table stakes, and the best platforms offer granular remediation controls, ITTT-style playbook automation, and even programs designed to drive specific outcomes.

We’re reaching the stage where we can even go past top-quality remediation workflows. The question for security platforms now is: how much can teams build on top of us? Organizations buying security tools increasingly ask not just "what does this platform do?" but "what can I do with the data this platform has?"

Enterprise security products that want to be relevant in five years need to be platforms, not dashboards and workflows. They need to expose their underlying data and context in ways that security teams can build on, not just consume. The alternative is a tool that shows risk clearly but gives organizations no operational lever to act on it at the speed and specificity their environment requires.

The pattern is familiar from other domains. Salesforce became the dominant CRM not because its default interface was perfect, but because it built a platform that thousands of businesses could extend to fit their specific sales process. AWS turned infrastructure into composable primitives that engineering teams could combine however their architecture demanded. Stripe's payment logic became embeddable rather than prescriptive. In each case, the platform won by stopping attempts to anticipate every customer's need and instead giving customers the foundation to build what they actually needed.

The platforms that have invested in remediation capabilities hit the same wall. Out-of-the-box workflows handle the common cases well. But every enterprise operates at the margins of those cases — specific combinations of systems, ownership models, compliance requirements, and risk tolerances that no vendor anticipated when they built their default workflows. That last mile is where products today consistently fall short, and it's the gap that extensibility is designed to close.

Security is overdue for the same shift. The identity platform that exposes its data layer for teams to build on, with proper governance, tenant isolation, and built-in audit controls, will displace platforms that require teams to accept fixed workflows or file feature requests and wait.

Enzo is Token's design bet on this direction.

‍

Sources:

‍