Navigating the SecOps Cloud Platform Revolution for Enterprise SOCs

The word "platform" in security now means two opposite things, and the gap between them is wider than the marketing suggests. When the established vendors started calling themselves platforms, they were describing a sales motion: acquire a dozen companies, put them behind one portal, and sell the bundle through a contract thick enough to choke on. Maxime Lamothe-Brassard, LimaCharlie's founder and CEO, spent this session, the keynote of a three-part event hosted by co-founder Christopher Luft, arguing that this is a repurposed message wrapped around the same old product. The platform worth wanting already has a working blueprint, and it is not in security. It is the cloud provider.

Two definitions are fighting over one word

Lamothe-Brassard is candid that LimaCharlie has been "part of that discussion, really kind of leading it for a long time," and that legacy vendors have lately "repurposed their message" to claim the platform label. The tell is what sits underneath the label. The legacy version buys a lot of different companies, puts them under a single web portal, calls it a suite, and sells "very complex contracts over large parts of that suite, like big bundles." Some of it works well. The rest, in his words, was "built by 20 different teams across 10 other companies," so it never integrates cleanly. What the buyer gets out of that is exactly what they had before: heavy lock-in, difficult access, and no real control.

The alternative is not invented. Cloud providers are platforms, he points out, down to the names ("even Google Cloud, their name is Google platform"). Viewed from that angle, platformization lands in the opposite place. Instead of five giant vendors fighting to kill competition and innovation unless it happens inside their walled garden, you get a foundation built to be a net enabler, something other people build great things on top of. One model exists to capture the industry. The other exists to grow it.

What "cloud provider for security" actually means

The SecOps Cloud Platform, by his own account, is "not rocket science." It takes the blueprint of how you build a cloud provider, and rather than exposing primitives like virtual machines, storage, and queues, it exposes security operations capabilities with the same qualities. Those qualities are the whole argument. APIs are open and first-class, "the foundation of the capabilities," not something monetized in one of 500 bundles. Control means the vendor never tells you "here's exactly the one way that you'll be using it." Builder-friendliness, which he calls one of the cornerstones, means you can build on top without selling your soul to a vendor, signing a 150-page agreement, or paying 80 percent of your margins to put their logo on everything. And pay-as-you-go means, as he puts it, "if you have a credit card, you get whatever you want at whatever scale you want whenever you want it."

On that foundation sit the operational products: EDR, telemetry ingestion from any SaaS or on-premises source, automated detection and response, long-term retention and search for compliance, and optimization of data on its way to other destinations. The underlying conviction is the one that separates this from a suite. No single vendor is "magically the best to provide everything for all users at the same time using the same software package." The platform puts the security professional in the driver's seat instead of deciding for them.

For a service provider, those abstract qualities translate into concrete economics. Builder-friendliness means adding a capability does not trigger a contract renegotiation or a margin giveaway. Pay-as-you-go means, in the example Lamothe-Brassard gives, an incident responder who gets a 3 a.m. call can go deploy in an organization without first negotiating what next year's contract looks like, and an enterprise that onboards a new SaaS product does not have to go back and renegotiate its capacity. Cost tracks actual usage rather than tiers bought blind. Against that, he names the friction the industry has accepted as normal: capabilities walled behind sales calls so you cannot even generate a proof of concept without clearing several gates, tools so opinionated that a real security team spends its time fighting the product, and the organizational drag of managing hundreds of vendors and their questionnaires. His sharpest framing is that many security capabilities "should be features, not products, not companies." A platform that treats them that way removes the assembly tax a provider otherwise pays on every new offering.

Automation as fabric, not as another tool

The clearest evidence that this is an architecture and not a slogan is the bidirectional functionality Lamothe-Brassard says LimaCharlie formally released around Google Next. The capability itself, taking automated action, is familiar from SOAR, and he says so. The difference is where it lives. Because it is baked into the platform rather than bolted on, "the one way that you are automating for one platform will be the same with other platforms." If telemetry is flowing into LimaCharlie, you can act on its source: lock a user, stop a virtual machine, act on an endpoint, regardless of the third party it came from.

That placement changes the physics of response. A traditional SOAR forces you to ration high-throughput sources like endpoint telemetry because of how much comes through. Here, automation is "part of the fabric," so you can mix sources freely. And it removes the relay he describes with some impatience: telemetry flowing into four data repositories, through a queue, into two SOAR platforms, tipping a SIEM that finally takes an action. None of that. Action happens in milliseconds rather than waiting 20 minutes for the right tip-off to arrive. For a SOC running response across many environments, one consistent action model at that speed is not a feature comparison. It is operating leverage.

What is notable about where the platform is headed is the direction it refuses. Asked for a roadmap, Lamothe-Brassard is explicit that LimaCharlie is "not building the most cutting-edge AI, the new wild thing." The plan is more primitives and integrations this year, delivered the same unopinionated way, so practitioners can spin up solutions in seconds. That restraint is the through-line of the whole session. The bet is not on owning the flashiest capability. It is on owning the foundation everything else gets built on, which is precisely the position a service provider wants to be standing on rather than renting from someone who can change the terms.