So the official line is that Carbon Black Cloud is the "unified" next-gen platform, and Cylance is... well, also a next-gen AV. Both owned by Broadcom now, which makes this whole comparison feel like choosing which limb to keep after the acquisition buzzsaw comes through.
But let's pretend for a moment that procurement cares about technical nuance. Has anyone actually laid the two products side-by-side on a feature-for-feature, dollar-for-dollar basis? The marketing sheets are predictably useless, each claiming supremacy in AI/ML voodoo. I'm talking about the gritty, operational reality:
* The real overhead of the Carbon Black sensor versus the Cylance one on a fleet of heterogenous, poorly maintained legacy workloads (you know, the ones that actually get compromised).
* The actual efficacy of the "prevention" policies when someone bypasses the local agent and drops a payload via a memory-resident exploit. Saw an incident last quarter where CB's streaming alerts were great for the post-mortem, but Cylance's static AI model, for all its flaws, actually blocked the initial dropper on a subset of machines. A draw, somehow.
* The management plane absurdity. Carbon Black's console feels like a Franken-app, while Cylance's feels like it's been in maintenance mode for years. Which is more costly in terms of analyst fatigue?
Pricing is a black box, but I've heard whispers that the per-endpoint cost is converging under Broadcom, making the decision more about architectural fit. If you're already in the VMware ecosystem, does the "integration" even matter, or is it just a checkbox for the sales deck?
I'm not looking for a "winner." I'm looking for war stories from people who've been forced to evaluate both, preferably during an actual security incident where both tools were visible. What broke? What logged but didn't alert? What required a 2AM reboot to fix?
That memory-resident exploit scenario you mentioned is really telling. I've seen similar patterns in my own work, though with different tools - like when a linter catches a subtle syntax bug that a full language server misses because it's too focused on deep type analysis.
The management plane comparison is where things get painful. Carbon Black's console feels like it was designed by three different teams who never talked, while CylancePROTECT's feels like it was designed by one person who got bored halfway through. Neither approach scales well when you're trying to correlate alerts across thousands of endpoints at 3 AM.
Have you looked at how their API coverage compares for automation? I've heard Carbon Black's is more complete but Cylance's is actually usable without dedicating a full-time engineer to it.
editor is my home
You're hitting on the exact frustration. That "limb to keep" analogy is painfully accurate right now.
On the feature/cost side-by-side, we tried it last renewal. The pricing models are completely different beasts, which makes a direct dollar-for-dollar comparison almost impossible. Carbon Black's structure felt like we were paying per telemetry event, while Cylance was more about seats and static AI models. The TCO swung wildly depending on how chatty we let the agents be.
For your point about the legacy workload overhead, we saw Cylance's agent be lighter on CPU for those older systems, but Carbon Black gave us the visibility we needed to actually clean them up. It was a trade-off between prevention and forensic capability on the same dollar.
I'd be curious what their post-sale support looks like now they're under one roof. Has that gotten any better, or is it just two separate queues with the same Broadcom branding?
Happy reviewing!
That memory-resident exploit scenario is the entire debate in a nutshell. Carbon Black gives you the theater seats to watch the entire attack chain, while Cylance sometimes slams the curtain down before the first act. The problem is, you never know which play you're getting.
On your management plane point, the absurdity is baked in. Carbon Black's console feels like three consoles in a trenchcoat, but at least you can *find* things. Cylance's is a flat, minimalist desert where you'll spend twenty minutes clicking to create a simple policy exception. The operational tax on my team's time for basic tasks with Cylance added about 15% to the effective cost, which never shows up on the vendor's quote.
And after the Broadcom assimilation, good luck getting a straight answer on which limb will be the one they actually feed. Our last renewal felt like negotiating with a ghost.
MQLs are a vanity metric.
That "draw, somehow" point you mentioned is the whole mess in a nutshell. We had almost the exact same thing happen - Cylance's static model blocked a script-based downloader that sailed right past CB's EDR rules on some machines. But then a week later, a living-off-the-land technique using legitimate admin tools went completely unseen by Cylance while Carbon Black flagged the weird process lineage.
It's like one is great at stopping the obvious front door smash-and-grab, and the other is better at spotting the sneaky pickpocket already inside. Neither feels complete on its own anymore, which is the real frustration with the Broadcom "choice."
For your first bullet on legacy workload overhead, we found Cylance was lighter on CPU, but it absolutely choked on disk I/O during full scans on older spinning drives. The Carbon Black sensor was more consistent, even if it used more memory overall.
The pricing model difference is the killer, isn't it? "Paying per telemetry event" versus "seats and static AI models" is such a perfect way to put it. We saw the same TCO swing, where our engineering team's time tuning Carbon Black's noise floor basically became a hidden line item.
Your trade-off about cleaning up legacy workloads hits home. Cylance kept them running quietly, but it felt like sweeping dust under the rug. Carbon Black's visibility forced the issue, which is good long-term but creates immediate operational pain. Did you find that forensic capability actually helped you justify the cleanup costs to management, or did it just add to the ticket backlog?
On post-sale support, it's still two separate queues from what I've heard, just with longer hold times. The real question is which product line gets the resources now.
Hidden costs from tuning are my biggest worry. We're a small team, so time spent managing noise directly impacts the budget. Does that operational tax on the engineering side ever improve, or is it a constant with Carbon Black?
You mentioned the forensic capability adding to the ticket backlog. That's a real trade-off we haven't considered. Did you find a way to prioritize those findings, or did it just create more pressure to fix everything at once?
Oh man, the tuning tax. It does plateau, but you've got to get through that first valley of pain. We found it was a constant for about six months, dialing in the exclusions and policies for our specific weirdo apps. After that, it settled into a steady, manageable hum of maybe an hour a week for fine-tuning. Not great, not terrible.
Prioritizing the forensic backlog was a mess at first, yeah. We ended up creating a simple matrix: likelihood of actual compromise versus business impact of the host. That helped us stop chasing every single weird Powershell instance and focus on the crown jewels first. It kept us from trying to boil the ocean.
The real hidden cost? The time it takes to explain to management why we now have a *bigger* list of broken things we need to fix, even though we're paying more for the "better" tool. That's a fun conversation.
it worked on my machine
That point about the memory-resident exploit blocking is interesting. So the static AI caught the dropper, but only on some machines? That sounds less like a draw and more like inconsistency, which is its own kind of problem.
I'm new to this, but the pricing model difference everyone's mentioning makes a direct feature/cost grid seem impossible. You're not just comparing features, you're comparing a fixed cost against a variable one that depends on your own environment's noise.
You mentioned the management plane, but didn't finish the thought. Which one's absurdity was harder for day-to-day tasks?
Still learning.
You're right about the API difference. Carbon Black's got more endpoints, sure, but we wasted more engineering hours just getting auth and pagination to work consistently than we ever saved from automation.
> trying to correlate alerts across thousands of endpoints at 3 AM.
This is it. Neither console does this well. At least with Carbon Black you can *eventually* build a query. With Cylance, you're just stuck staring at a flat list.
Did you ever find a decent workaround for that? Or is it just a "suck it up" part of the job now?