Akamai Prolexic made routed DDoS mitigation a customer-bypass accountability test

Summary

• Akamai's June 17, 2021 update said a Prolexic Routed 3.0 service incident affected a portion of customers using the routed DDoS mitigation service, with alerting beginning at 8:47 a.m. ET and customer traffic rerouted automatically or manually until restoration.
• The accountable issue is delegated mitigation. A customer sends traffic through a scrubbing service to survive DDoS attacks, but that route becomes a business-continuity dependency when validation or routing state inside the mitigation provider fails.
• Akamai said the incident was not caused by a system update or cyberattack and pointed to a routing-table value that was inadvertently exceeded. That narrows the analysis to operational route validation, capacity/state controls, rerouting, and customer recovery.
• ThousandEyes' external measurement record matters because it showed varied customer impact and the value of backup plans. A routed mitigation incident should be judged by whether customers can bypass or return traffic safely when the defense path is impaired.
• Durable repair evidence should cover route-table guardrails, pre-validated bypass, customer notification, automatic rerouting scope, manual support capacity, traffic-return safety, and proof that the mitigation path cannot become a larger outage than the attack it is meant to absorb.

Delegated mitigation changes who controls continuity

Akamai's public update, Akamai provides Prolexic DDoS service impact update, is the core incident record. The company said Prolexic Routed 3.0 experienced a service incident affecting a portion of customers. It said alerts began at 8:47 a.m. ET, affected customer traffic was automatically routed or manually routed by Akamai teams, and services were restored at 12:47 p.m. ET. It also said the incident was not caused by a system update or cyberattack and that the issue was a routing-table value inadvertently exceeded.

That statement makes the accountability question precise. The point is not whether Akamai was under attack. The point is how a protection service controlled the path of customer traffic and how customers could escape that path when it failed. DDoS mitigation is not only an add-on security feature. In a routed model, it can become part of the customer's live network topology.

Akamai's Prolexic materials describe the service as DDoS protection for infrastructure. The Prolexic product page, the Prolexic product brief page, and the Prolexic product brief PDF explain the defensive purpose: absorb, inspect, and mitigate malicious traffic before it reaches customer origins. Later/current product language should not be treated as a 2021 incident finding, but it clarifies the service model that creates dependency.

The dependency is easy to misunderstand. A customer may think of DDoS mitigation as a shield placed in front of the service. A routed design is more than a shield. It changes how traffic reaches the customer. If traffic is announced or redirected through scrubbing centers, route state, GRE tunnels, direct connections, return paths, and provider operations become part of availability. When the protection path fails, the customer may need a bypass path that is already designed, authorized, tested, and understood.

The word "bypass" is central. A bypass is not a panic improvisation after the protection service is impaired. It is a preplanned method for returning traffic to a safe path while balancing the risk that the customer may again face hostile traffic. The customer does not want to remove protection casually during an attack. But during a mitigation-provider outage, the customer may need to choose between continuing through a failed defense path and exposing an origin through a backup route. That decision has to be designed before the incident.

Routed protection turns route validation into customer care

Akamai's service description materials matter because they show how routed mitigation depends on network-control mechanisms. The Akamai services description PDF describes Prolexic Routed in terms of BGP directing traffic to Akamai scrubbing centers. Akamai's blog on Prolexic and Equinix Cloud Exchange discusses bringing DDoS defense closer to customer origin through interconnection. These materials are not outage postmortems, but they explain why routing control is the service.

BGP itself is defined in RFC 4271. GRE, often part of traffic return or tunnel design in mitigation architectures, is defined in RFC 2784. Those standards do not say what Akamai did wrong or right in 2021. They clarify the technical vocabulary: route announcements, traffic paths, tunnels, and return mechanisms are not background detail. They are the product surface.

If a provider's routing-table value is exceeded, customers need to know what that means for their traffic. Did the affected state block new route programming? Did it impair return traffic? Did it affect only certain customers, certain prefixes, certain regions, or certain routing relationships? Akamai's public statement was brief, so a responsible analysis should not invent details. But the brevity itself sets the repair question: what guardrails now prevent a routed mitigation control from exceeding a state value in a way that affects customer availability?

Route validation in this context is customer care. It is not merely an internal network engineering check. The provider's validation protects customer revenue, public portals, APIs, bank access, SaaS applications, and emergency-facing services. A failure in validation shifts work onto customer operations teams, who must determine whether to wait, reroute, bypass, communicate to users, or escalate through support.

RFC 7454, BGP Operations and Security, offers general operational-security expectations around route policy, filtering, and operational hygiene. MANRS network operator actions and CISA's Securing Internet Routing provide public and community framing for route discipline. These are general references, not incident-specific findings. They matter because routed mitigation services put operator route discipline directly into customer continuity.

Typography note

External measurements show varied impact

ThousandEyes' Akamai Prolexic Routed outage analysis is valuable because it looks from outside the provider. It observed reachability differences, peering-related behavior, and customer variation. ThousandEyes later included the event in Seven outages that shook up 2021, emphasizing that some organizations with prepared backup plans were able to reduce impact. That is exactly the accountability lesson: routed mitigation failures are not only provider failures; they are tests of customer bypass readiness and provider-supported rerouting.

The existence of varied impact should not become victim blaming. Customers buy DDoS mitigation because they want a specialist provider to absorb a problem they cannot safely handle alone. If the service path fails, the provider remains responsible for route safety, status notice, automatic rerouting, support capacity, and post-incident repair. At the same time, customers with mission-critical public services need tested bypass and fallback designs because no protection path is immune from failure.

Secondary reporting, including SecurityWeek's Akamai blames outage on DDoS protection service and iTnews' Akamai routing error caused widespread outages, described visible disruptions affecting public-facing services. Such reports can illustrate scope, but they should not be used to claim uniform duration or identical recovery posture for every organization. Routed mitigation affects customers differently depending on prefixes, routing partners, bypass plans, application design, and communication speed.

The measurement evidence also shows why public route visibility is necessary. A customer's website or API may be unavailable even though its origin servers are healthy. The user sees the application as down. The customer may see no obvious origin problem. The provider may be rerouting. External probes can show where traffic fails or returns. Without that visibility, responders waste time debugging the wrong layer.

For providers, the lesson is that public post-incident communication should include enough routing and customer-impact structure to make measurement meaningful. If the public statement says only "service incident," customers cannot tell whether their own runbooks should change. If it says which service, what type of routing state failed, how traffic was rerouted, what automatic controls worked, what manual controls were needed, and what recurrence guardrails changed, customers can improve their own architecture.

Bypass is a shared design, not a last-minute decision

A good bypass plan has several elements. The customer knows which prefixes and services are protected. The customer knows what happens in always-on and on-demand modes. The provider and customer know who can authorize traffic changes. Upstreams know whether alternate announcements are allowed. DNS, TLS, firewalls, origin access controls, and application limits are ready for changed traffic paths. Support teams know which business services are highest priority. Communication templates are ready for end users.

Without that design, bypass can create new risk. Sending traffic around the scrubbing service may expose the origin to the attack the service was meant to absorb. Leaving traffic inside a failed mitigation path may prolong outage. Announcing more-specific prefixes may create route-policy side effects. Changing DNS may be too slow or cache-dependent. Disabling origin restrictions may create security exposure. These tradeoffs cannot be decided calmly when public services are already unavailable.

NIST SP 800-61 Revision 2, Computer Security Incident Handling Guide, is general guidance, but its incident lifecycle is relevant: preparation, detection, containment, eradication, recovery, and lessons learned. In routed mitigation, preparation includes knowing how to move traffic safely. Recovery includes restoring normal protected routing without creating a surge, leak, or security gap.

The customer-bypass question is also economic. Small and medium-sized businesses may not have their own network engineering staff. They may depend entirely on the provider and a managed host. If routed mitigation fails, they may not know what prefixes are announced, which contacts can approve change, or whether a bypass exists. A provider selling protection to such customers should supply practical runbook language, not only enterprise-grade architecture diagrams.

Large enterprises face a different problem. They may have sophisticated networks and multiple providers, but their governance can be slow. If emergency rerouting requires approvals across security, network, legal, business, and executive teams, the bypass may exist on paper and still be unusable. The provider's incident communication should therefore help customers make rapid, evidence-based decisions.

Automatic rerouting needs proof of coverage

Akamai's update said affected customer traffic was automatically routed or manually routed by Akamai teams. That phrase is important because it identifies two recovery modes. Automatic rerouting suggests prebuilt failover logic. Manual rerouting suggests human intervention for cases the automatic path did not cover, did not complete, or required customer-specific handling. The accountable question is how those categories changed after the incident.

Automatic rerouting should be tested against realistic provider-side failure. It is not enough to prove that rerouting works during a planned exercise or a customer-requested transition. It should work when the provider's own routing state is impaired, when alert volume is high, when many customers need help at once, and when status communication is under pressure. A DDoS mitigation provider's recovery system must be designed for multi-customer simultaneous impact because the service itself is shared infrastructure.

Manual support capacity matters because customers cannot all be first in line. A provider may have excellent engineers and still face queueing when many customers call at once. The public repair record should explain whether manual routing steps were reduced, whether more customers obtained automatic rerouting, whether support runbooks changed, and whether notification became more precise. Akamai said it would ensure every customer has automatic rerouting to their closest scrubbing center in case of failure. That promise is a repair marker, but customers need later evidence of completion.

Traffic return is another part of recovery. Once the provider path is fixed, moving customers back through protection can create risk if route convergence, cache behavior, firewall state, tunnel state, or attack traffic is not managed. A service may be restored, but a careless return path can create intermittent failures. The incident record should therefore include not only outage start and stop times, but how traffic was brought back to a stable protected state.

Akamai's 2021 Form 10-K, SEC filing, provides broader business-risk context: Akamai sells services that customers use for performance, security, and availability. The filing does not decide the Prolexic incident. It shows why provider outages in security and delivery infrastructure can become customer governance issues. When a vendor's role is continuity, the vendor's own continuity controls are part of the product.

Status notice should identify dependency and decision points

During a routed mitigation incident, customers need more than a generic availability notice. They need to know whether the affected service is Prolexic Routed or another Akamai function, whether the issue affects all customers or a subset, whether attack mitigation remains active, whether bypass is recommended or risky, whether automatic rerouting is occurring, and what action customers should take if their application is unreachable.

The public can tolerate some uncertainty early in an incident. What it cannot use is vague reassurance that leaves customers guessing whether to change routes. Status notice should evolve: first identify affected service and symptoms; then identify route or scrubbing dependency; then state whether traffic is being automatically or manually rerouted; then provide guidance for customer escalation; then publish a post-incident note explaining what changed. That progression reduces secondary harm.

The Prolexic incident is a case where provider status and customer runbooks intersect. If a customer's protected service is down, it must decide whether to wait for provider rerouting or activate its own fallback. The provider has the best view of the service-side fault. The customer has the best view of business priority and local application impact. Good status notice lets those views meet quickly.

Communication should also avoid overbroad claims. Akamai said the incident was not a system update or cyberattack. That fact mattered because customers could focus on operational routing recovery rather than compromise response. But customers still needed to know whether their own services were affected, whether attack traffic was present, and whether data integrity or confidentiality was implicated. Availability incidents should be scoped precisely so customers do neither too little nor too much.

For critical public services, status notice has a social function. Banks, government portals, healthcare interfaces, and communications services may need to notify their own users. If the upstream mitigation provider's explanation is specific and timely, downstream organizations can communicate accurately. If it is late or vague, downstream notices become vague too. Cost transfer often travels through uncertainty before it travels through money.

Scrubbing services need failure-domain transparency

DDoS scrubbing is intentionally abstracted. Customers do not want to manage every attack signature, global capacity pool, peering relationship, tunnel, or mitigation rule. They buy a provider service because the provider can operate specialized defenses at scale. But abstraction should not hide failure domains that affect continuity. Customers need to understand which part of the provider path can fail and how they can respond.

Product documentation can describe this in controlled terms. It can explain always-on versus on-demand routing, BGP announcement responsibilities, tunnel return paths, direct-connect options, maximum route scale, dependency on customer prefix hygiene, emergency bypass procedures, and support contacts. It can explain what changes if traffic is automatically rerouted to the closest scrubbing center. It can describe which customer actions are dangerous during an active attack. None of that requires revealing sensitive mitigation methods.

Failure-domain transparency is especially important when security and availability trade off. A customer may choose a strict protected path that maximizes DDoS resilience but increases dependency on the provider. Another customer may accept more origin exposure in exchange for faster bypass. Those are business decisions. They should be informed by provider evidence, not discovered during an outage.

The 2021 incident should therefore be used as a procurement lesson. Buyers of routed DDoS mitigation should ask: What happens if the scrubbing service itself has a routing fault? Is automatic rerouting enabled for every protected prefix? How is bypass authorized? How often is it tested? Can the customer see route state? What status details will be provided? How quickly can traffic return to normal protection? What contractual commitments apply when the protection path is the outage path?

Providers should welcome those questions if they have strong controls. They convert a painful incident into clearer customer design. They also reduce response burden during the next event because customers with tested bypass plans call with better information and make safer decisions.

Residual unknowns and the accountable question

The public record does not reveal every detail of the routing-table value Akamai identified. It does not provide a customer-by-customer map of downtime, automatic rerouting, manual intervention, or bypass readiness. It does not independently verify that every customer later had automatic rerouting to the closest scrubbing center. It does not show all contractual allocations between customer, provider, and upstream networks. Those unknowns should stay visible.

What is known is enough to define accountability. Akamai operated the Prolexic Routed 3.0 service. The service used routed traffic paths to protect customers from DDoS attacks. Akamai said a routing-table value was inadvertently exceeded and that affected customers were routed automatically or manually. External measurement showed that customer impact varied and that backup plans mattered. Customers and users bore the consequences of a protection dependency becoming unavailable.

The accountable question is whether routed mitigation became safer after the incident. Did Akamai add validation to prevent route-state limits from becoming customer outages? Did automatic rerouting cover all customers as promised? Did customer bypass documentation become clearer? Did status notices identify decision points faster? Did traffic-return procedures improve? Did customers receive test evidence or architecture guidance? Did the service reduce manual intervention under provider-side fault conditions?

The answer should be judged by evidence. A provider statement that services were restored is the beginning. A post-incident repair record, customer runbooks, tested bypass paths, and later service behavior are the proof. Because DDoS mitigation is sold as continuity under hostile pressure, the provider's own route continuity must be held to a high standard.

The final lesson is not that routed DDoS mitigation is bad. It is that delegated protection creates delegated dependency. Customers need the protection path, but they also need a safe route around the protection path when the defense system is impaired. Akamai's Prolexic incident made that design requirement visible. The accountability standard is whether that visibility became durable customer control rather than a one-day outage memory.

Provider-side capacity controls need customer-visible meaning

Akamai's phrase "routing table value" is necessarily compact. It does not publicly disclose internal architecture, and it should not be stretched beyond the company's statement. But even a compact phrase has governance consequences. Customers need to understand that provider-side route state can become a customer-facing limit. If a value can be exceeded in a way that interrupts service, then validation around that value is part of the customer's resilience model.

The public repair question is not the literal name of the value. It is the control class. Was the value monitored? Was there an alert before customer impact? Was the limit tested under growth and failure conditions? Was there a guardrail to prevent unsafe route programming? Was there a fallback when the value was approached? Could the condition recur in another scrubbing center, region, or customer group? Those questions turn a brief statement into a practical accountability checklist.

Customers can ask for this information without demanding sensitive implementation. A provider can say that route-state thresholds are monitored, that releases or route changes are tested against limits, that automatic rerouting covers defined scenarios, that runbooks cover manual exceptions, and that customer notification will identify decision points. It can also provide enterprise customers with deeper assurance under appropriate confidentiality. The point is not public exposure of the system. The point is customer-relevant assurance.

Capacity controls should also be tested against the shape of DDoS emergencies. Attack traffic can create abrupt route and mitigation changes. Customers may activate on-demand protection under stress. Providers may shift traffic among scrubbing centers. The same control that works during a calm maintenance window may behave differently during simultaneous customer events. A service built for hostile traffic should validate route state under hostile-like conditions, not only ordinary operations.

The Prolexic incident showed that a protection provider's internal limit can be felt by end users who have never heard of the service. A person trying to reach a bank or public portal sees the site as down. The customer sees a supplier incident. The provider sees an internal routing-state problem. Accountability requires translating among those views so the party with control over the limit proves it has reduced the public symptom.

Customers should classify protected services by bypass risk

Not every protected service should bypass in the same way. A public marketing site, a payment API, an online banking login, a healthcare portal, a SaaS control plane, and a government service have different exposure if DDoS protection is removed. A bypass runbook that treats all protected prefixes as equal is too crude. Customers should classify protected services by the risk of staying on a failed mitigation path and the risk of leaving protection.

For low-risk informational sites, bypass may be acceptable quickly if the origin can absorb normal traffic. For high-risk transaction systems, bypass may require upstream rate limits, origin access changes, or regional traffic shaping. For services already under attack, bypass may be dangerous unless another mitigation path is ready. For regulated services, the decision may require business approval and public notice. This classification should be done before the provider outage, not in the middle of it.

The provider can help by supplying a bypass decision tree. The tree can ask whether the customer is under active attack, whether alternate mitigation exists, whether DNS or BGP changes are faster, whether origin capacity is sufficient, whether firewall rules allow direct access, and whether support can assist with safe return. Such guidance is not a substitute for customer engineering. It makes customer engineering possible under time pressure.

Customers should also test return-to-protection. It is common to test failover and forget failback. After a provider incident resolves, traffic must return to the scrubbing service without breaking sessions, losing route stability, exposing origins, or reintroducing attack traffic. If failback is not rehearsed, organizations may delay restoration of protection or create a second outage. A complete runbook covers bypass and return as one lifecycle.

The Prolexic record is therefore useful even for customers that were not affected. Any organization using routed DDoS mitigation can ask whether its bypass classification is current. It can run a tabletop exercise: Akamai or another provider reports a routed mitigation fault; automatic rerouting works for some prefixes but not all; public users are failing; no attack is visible; what do we do in the first fifteen minutes? The answer will reveal whether the protection dependency is governed.

Multi-provider mitigation can reduce risk and add complexity

Some customers respond to a routed mitigation incident by considering multiple DDoS providers. That can reduce single-provider dependency, but it can also introduce route-policy complexity. Multiple providers may require different prefix announcements, tunnels, DNS strategies, origin restrictions, health checks, contracts, and support contacts. A poorly designed multi-provider plan can create the same confusion it was meant to solve.

The right question is not simply "How many vendors?" It is "Which failure domains are separated?" If two providers rely on the same upstream path, same DNS control, same origin bottleneck, or same internal approval process, the practical resilience gain may be smaller than the vendor count suggests. If the customer cannot operate the second provider under stress, the second provider may become documentation rather than continuity.

Provider diversity also changes attack handling. A DDoS event is adversarial. Switching mitigation providers during an attack can expose origin addresses, reset filtering context, or require rule translation. The customer must know which provider has authority, how traffic shifts, who coordinates with upstreams, and how telemetry is compared. These details are too important to improvise.

Still, diversity can help if it is designed and tested. A customer may maintain a secondary scrubbing path, a cloud-based fallback for less sensitive traffic, or an emergency DNS strategy. It may divide services by criticality and assign different mitigation models. It may contract for provider assistance during bypass. The lesson from Akamai's incident is not that every customer needs two full providers. It is that every customer needs a consciously chosen failure-domain strategy.

Vendors can support that strategy by being transparent about how their routed service fails, how customers can leave and return, and which customer-owned components are prerequisites. When a provider resists any discussion of bypass, it asks customers to trust a single path absolutely. The Prolexic event showed why absolute trust in a single protection path is not a resilience plan.

The protection contract should include outage cooperation

DDoS mitigation contracts often focus on attack capacity, response time, service availability, support, and pricing. The Prolexic incident suggests additional questions. Does the contract define provider responsibilities when the mitigation route is impaired? Does it require automatic rerouting where available? Does it specify how manual rerouting is prioritized? Does it identify customer obligations for prefix data, tunnel configuration, emergency contacts, and bypass approval? Does it include post-incident evidence?

Contract terms cannot solve every operational problem, but they can force preparation. If the contract requires current emergency contacts, both parties have a reason to maintain them. If it requires periodic failover tests, bypass is less likely to be theoretical. If it requires status updates with actionable information, customers can plan downstream communication. If it requires post-incident review, repair commitments are harder to forget.

The contract should also address data and telemetry. During a routed mitigation outage, customers need logs or reports showing when traffic failed, when it rerouted, what regions or prefixes were affected, and when normal protection resumed. Without that evidence, customers cannot explain the event to their own users, auditors, or regulators. Provider telemetry is part of customer accountability.

For public-facing essential services, contract cooperation should include public communication. A bank, government agency, or healthcare service may need to tell users that an upstream mitigation provider is impaired. The provider's wording can help prevent misinformation. It can also confirm that the event is an availability and routing issue rather than a data compromise where that is supported. Clear supplier language reduces the customer's burden.

The broad lesson is that delegated mitigation is a relationship, not a black box. The provider controls specialized defenses. The customer owns the service mission. During provider-side failure, those responsibilities meet. Good contracts, runbooks, status notices, and tests make that meeting predictable. Without them, a routing-table value inside a vendor environment can become a public outage with unclear decision rights.

Return-path evidence should be part of mitigation assurance

Routed mitigation has two public faces: the path into the scrubbing service and the path back to the customer. Buyers often focus on the first because it is easier to understand. Attack traffic enters the provider's defensive network, the provider filters it, and clean traffic reaches the origin. The return side can be just as important. Tunnels, direct connections, route preferences, firewall rules, and origin restrictions all determine whether protected users actually receive service.

The Prolexic incident makes return-path evidence part of assurance. If a provider reroutes traffic automatically or manually, customers need to know whether return paths are valid, whether tunnels are healthy, whether origin allowlists still match, and whether failback will preserve protection. A routed service can be technically restored at the provider level while a customer still has an origin-side mismatch. That mismatch can look like a continuing provider outage, a customer misconfiguration, or a partial recovery problem.

Customers should therefore ask for route and return-path test cases in onboarding. The first test should prove ordinary protected operation. The second should prove provider-side rerouting. The third should prove customer-authorized bypass. The fourth should prove safe return to protection. The fifth should prove communication: who receives alerts, what they say, and what action is expected. A plan that has never moved traffic in a controlled exercise is not a dependable bypass plan.

Akamai's statement that traffic was automatically or manually routed provides a useful starting point, but customers need local evidence. Did their protected prefixes participate in automatic rerouting? Did their application require manual support? Did logs show when route changes occurred? Did users recover when provider status said restored? Did the customer have to change origin controls? These questions make the provider incident actionable without speculating beyond the public record.

Return-path assurance also matters for small organizations. A large enterprise may have network teams that can inspect BGP, GRE, and firewall state. A smaller customer may only know that the site is down. Provider dashboards, plain-language status, and account-team runbooks can bridge that gap. If the provider sells advanced mitigation to organizations without advanced network staff, the provider should make recovery states understandable.

The accountability standard is evidence that protection can be left and re-entered safely. DDoS mitigation is unusual because failure decisions have security consequences either way. Staying on a failed path can deny service. Leaving the path can expose the origin. Returning too quickly or without validation can reintroduce risk. That is why routed mitigation assurance should include traffic-entry, traffic-return, bypass, and failback proof as one control family.

Customer communication should distinguish outage from attack

A DDoS-protection customer may reasonably assume that any availability problem near the mitigation service is an attack. Akamai's update said the Prolexic Routed incident was not caused by a cyberattack. That distinction is operationally valuable. If a customer believes an outage is attack-driven, it may avoid bypass, tighten controls, activate crisis communications, or escalate to security leadership. If the provider can confirm an internal routing service issue, the customer's decision path changes.

The provider should make that distinction quickly when evidence supports it. "We are investigating" is appropriate early. Once known, "this is a service routing issue, not observed attack traffic against your origin" or "attack status remains under review" gives customers a better basis for action. The communication should also say whether the customer should refrain from route changes, prepare bypass, or contact support for manual rerouting.

This is where status notice becomes a shared-control document. The provider knows service state. The customer knows business criticality. Both need a common language. If the provider's notice is too technical, business teams may not act. If it is too vague, network teams may guess. A good notice identifies the affected product, customer symptoms, known cause category, recommended action, and next update time.

Downstream users benefit from that clarity. A bank, SaaS company, or public agency can tell its users that an upstream DDoS mitigation provider is experiencing an availability issue rather than implying a breach or application defect. Accurate phrasing reduces rumor, support load, and unnecessary security panic. It also helps the provider avoid being blamed for harms not supported by the evidence while still owning the service dependency it controls.