Just saw the news that Akamai acquired a zero-trust/secure access firm (again). It got me thinking about their DDoS product line.
Prolexic is a beast for layer 3/4 volumetric attacks, no question. But the threat landscape keeps shifting up the stack. More complex, application-layer attacks that look like legitimate traffic are a bigger part of the mix now.
My immediate question: Will any of this zero-trust tech actually get integrated into the Prolexic service? Or will it just live in a different dashboard as a separate SKU?
From a workflow perspective, having a unified defense would be huge. Imagine:
* Prolexic scrubbing the raw flood at the edge.
* Then, a tightly integrated zero-trust or WAAP policy handling the "cleaner" but potentially malicious application traffic.
* A single pane of glass for logs and mitigation actions.
Right now, you often have to stitch these things together yourself. If Akamai can truly blend network DDoS with zero-trust principles for app access, that's a compelling story. But if it's just another acquisition that doesn't talk to the rest of the portfolio... what's the point?
Has anyone seen any concrete roadmap hints? Or are we just speculating based on press releases?
Spreadsheets > marketing slides.
Your point about stitching things together yourself really hits home. We went through that last year integrating a separate ZTNA solution after a Prolexic scrub. The latency and log correlation between systems was a constant headache.
If history is any guide, Akamai tends to keep acquired tech as separate products for at least 18-24 months before any deep integration. The real test will be if they build a common policy engine. Without that, it's just another tab in the portal, not the unified defense you're describing.
I haven't seen a concrete roadmap, but the pressure from cloud providers offering bundled security might force their hand faster this time.
Data is sacred.
You're spot on about the separate product phase. Looking at their acquisition of Janrain and subsequent timeline before it became part of their identity cloud, that 18-month window is a solid historical precedent.
Your mention of latency and log correlation is the core operational cost. We measured an added 80-120ms on average for the handoff between scrubbed traffic and our third-party access gateway, purely from the extra hops and policy evaluation points. That's a direct tax on every single request that makes it through the DDoS filter.
The bundled pressure from cloud providers is real, but I'm skeptical it changes the integration clock. Their sales motion has always been modular. The real signal will be if they announce a merged engineering team within the next quarter. If the zero-trust team stays siloed, the "common policy engine" is just slideware.
Latency is a liability
Yeah, the "single pane of glass" dream is exactly why I'm watching this. The stitching part is the real killer right now.
I was testing a scenario last month with a mock app-layer attack that slipped past our edge rules. Having to context-switch between Prolexic logs and a separate zero-trust console to trace a single malicious session was a huge time sink. The telemetry formats didn't match up at all.
If the integration is just a bundled SKU, that pain doesn't go away. We need that common policy engine someone mentioned, where a decision at the scrubbing center can inform the zero-trust gateway downstream, and vice versa. Without that, it's just two products on the same bill.
Haven't seen a roadmap either, but I'm checking their next developer blog update like a hawk.
Your vision of a unified defense pipeline is theoretically sound, but the technical hurdle lies in the fundamental difference in traffic inspection points. Prolexic operates at the network edge, making decisions on volumetric flow before it reaches your infrastructure. A true zero-trust model requires application-layer context, which often only exists *after* traffic reaches an origin or a dedicated gateway.
The integration you're hoping for isn't just a common dashboard; it's a shared data model and real-time signal exchange. For Prolexic to inform a zero-trust policy, it would need to pass metadata about scrubbed sessions - like source IP clusters exhibiting suspicious TLS handshake patterns - downstream via a sidechannel. Conversely, the zero-trust service would need to feed confirmed threat intelligence back upstream to potentially adjust scrubber parameters.
Without that bidirectional data pipeline, any "integration" will be superficial. The acquisition gives them the components, but building the connective middleware is the real multi-year project. I haven't seen any technical hints of such a data fabric in their recent research publications.
—BJ
You've hit on the key question about integration vs. separate SKUs. Based on their pattern, I expect a bundled SKU will come first, well before any deep technical integration. That might still have value if it simplifies procurement and support, but it won't solve the telemetry gap.
The workflow you described is the goal, but the real test is the data layer. Can Prolexic's DDoS heuristics - like identifying a source IP range conducting a low-and-slow attack - generate a real-time signal that automatically tightens zero-trust policy thresholds for traffic from that range? Without that, it's just two walls standing next to each other, not a continuous filter.
I haven't seen any roadmap either, but I'm looking for announcements about a shared engineering lead or a common API framework. That would be a stronger signal than any new product name.
That's a good point about the shared data model being the real test. A bundled SKU first feels inevitable, but it risks just giving us two separate problems in one box.
You mentioned looking for announcements about a shared engineering lead. Beyond that, I'm curious about what their first-step integration would even look like in practice. Is a common API framework enough, or does the telemetry gap require a completely new, joint product built from the ground up?
The low-and-slow attack example is perfect. If Prolexic can't pass that signal in a format the zero-trust gateway can act on immediately, the workflow breaks. How have other vendors you've seen handled that signal exchange without introducing more latency?