Today, 8Layers is generally available.
That's the headline. The story behind it is longer and worth telling because it's the only way to explain why we built the platform the way we built it.
What Devo taught us
Back in 2011, I was part of the founding team of Devo (then Logtrust), alongside Pablo Carretero, Pedro Castillo, and Pedro Palao. We started from zero, with almost no funding, a tight runway, and the conviction that we could build something better than what existed. The Spanish tech ecosystem at the time wasn't exactly designed for ambitious B2B platforms going global, so we pushed hard.
We made it. We scaled the company to a double-unicorn valuation, opened the US market, and built a product used across security teams in industries from Retail and Banking to Defense, including the USAF.
But what I really took away from those years wasn't the milestones. It was a set of scars. How to build a product from first principles. How to validate technology against real problems, not assumed ones. How to be part of a company through the hardest stages of growth. How to know when something is good enough to ship, and when it isn't. Most of all: how to recognize, in the middle of running a successful platform, the problems your customers couldn't solve, even with the best tools available, including yours.
The problem we kept seeing
Year after year, working with security teams across multiple customers, we saw the same pattern repeat itself. Not in the threats themselves, but in the infrastructure underneath.
The SIEM model works when the question fits its assumptions: a known indicator, an event timestamp, and a rule that fires when the two match. It can scale in compute, at the cost of the bill. That logic produces alerts efficiently, but often false positives. As soon as you move into more complex patterns or behaviors, the efficiency drops sharply, and many of the detections you actually need become impossible to run at scale.
Real attacks are kill chains. They unfold across weeks, across systems, across signals that only make sense when you correlate them with months of prior context and the inventory state of the entities involved. The SIEM model wasn't built for that. So instead of catching kill chains, it generates volume: thousands of IOC matches, most of them false positives, that have to be triaged manually by an analyst who spends their day stitching fragments together.
Quality alerts look different. They arrive already correlated across time and signals, already enriched with the historical state of the entities involved, already framed as a kill chain rather than a fragment. One alert with the full story.
Doing that properly meant rebuilding the layers underneath. An inventory that lives independently of the event stream, continuously enriched, queryable at the speed of an investigation. Detection logic that can reach back months without crippling compute costs. A model that produces fewer alerts of higher confidence, not more alerts of lower confidence.
That was the gap we couldn't stop thinking about. Not the symptom. The architecture.
What we couldn't walk away from
When we left Devo, the three of us (Pedro, Pablo, and I) didn't have a clear plan. What we had was conviction. We were not going to attack this problem at the surface, with another set of rules and dashboards bolted on top of someone else's data layer. We were going to attack it from the core.
We reached out to Iago, who had worked with us at Devo as one of the strongest detection engineers and threat hunters we'd ever met. He brought us closer to the operational reality of the problem: in every environment he'd worked in, and across the network of practitioners he stayed close to, the same gap kept appearing. Detection coverage on cloud identity behavior, human and non-human, was either thin, expensive, or non-existent. Not because teams didn't care, but because the data model underneath couldn't support the detections that actually mattered.
Iago had been making the same argument from a different direction. While we were still at Devo, he had been pushing internally for a conceptual shift: detections shouldn't run on logs, they should run on an inventory model, feature-engineered against the entities under observation. It was the same architectural conviction we were arriving at from the platform side. The diagnoses converged.
Resolving security use cases from a different perspective was the genesis of the project. Our initial use case was rooted in the hypothesis that a new paradigm was needed, analogous to what EDR (Endpoint Detection and Response) represented for system logs and antivirus, NDR (Network Detection and Response) for network logs and IDS (Intrusion Detection Systems), or ESA (Email Security Appliance) for email logs and spam filters: an UDR (User Detection and Response) that leveraged our inventory and addressed one of the least tackled problems at the time.
Shortly before launching the project, Gartner coined a similar concept under the name ITDR (Identity Threat Detection and Response). Frankly, a far better fit. Its emergence confirmed that the need we had identified was also being recognized by others, validating that this was a real problem demanding a solution.
Along with our first design partners, we validated what we already suspected: this wasn't a feature gap. It was a paradigm gap. The identity security category needed something built from the bottom up, from the data layer through every workflow, not another module bolted onto a platform that was never designed for it.
So we jumped.
Doing it from the core
The hardest decisions came from a commitment we made early and never walked back: solve the problem properly, from the core, against the temptation of solutions that look simpler but fail at the layer that matters.
That meant building our own data layer, designed around the inventory model from the start: entities continuously enriched, queryable without log-anchored assumptions, and able to correlate today's events against the historical state of an entity months ago without crippling compute trade-offs. It meant designing the detection language for analysts to audit and customize, not as a black box. It meant building a technological core capable of solving security use cases that demand deep temporal and contextual data, identity today, and other angles tomorrow.
This is the kind of problem that pulled us in. The technical challenge of attacking it from the foundation, not the surface, is the work we wanted to be doing.
Where we are, and where we're going
We're sixteen people today, a mix of engineers we'd worked with before and others we found along the way, brought together by the same kind of conviction this problem deserves.
GA is not the finish line. It's where the real work begins.
In the next twelve months, I want to see 8Layers in the hands of security teams who have been living with the fragmentation problem for years and finally have the coherent answer they've been missing. I want conversations with the people who already know their environment has complexity that generic platforms weren't designed for.
What we're building is something different: not another product fighting for the same ground, but a platform attacking the problem from a layer underneath, where the actual constraints live. That's the work that matters to us, and the work the next decade of security depends on.
If you want to see 8Layers in action or trade notes on where identity security is going, reach out. We'd love to hear from you.
By Daniel García Morán, CEO & Co-Founder, 8Layers