Summary

  • Prosimo was founded in 2019 and raised at least US$55 million across its 2021 Series A and 2022 Series B; audited revenue, valuation and acquisition price were not disclosed.
  • AXI combined central intent, topology and analytics with distributed edges that discovered cloud assets, connected applications, inserted security services and collected telemetry without owning the physical backbone.
  • A June 2024 VM-Series integration preceded Prosimo’s transition into Palo Alto Networks around February 2025; no source supplies an exact acquisition date, price or current product map.
  • Control remains layered among enterprises, orchestration software, cloud providers and Palo Alto Networks, making portability of topology, credentials, policy and route authority the decisive customer test.

The company disappeared before the problem did

Prosimo cannot be profiled accurately as an active independent vendor in 2026. Public professional histories show its founders and several employees moving into Palo Alto Networks around February 2025. The Prosimo company identity is marked as acquired, and former chief technology officer Nehal Bhau later wrote that its technology had been integrated into Palo Alto Networks products. The evidence establishes a change of control and continuing technical value. It does not establish the transaction’s exact signing date, closing date, legal form or price.

That correction belongs at the beginning because it changes the tense of every product claim. AXI, Network Transit, App Transit, Application-driven Intelligent Results and Nebula were documented Prosimo capabilities during the independent period. They should not be presented as separately sold current products unless Palo Alto Networks publishes a contemporary product and support map. A historical architecture can survive an acquisition as embedded code, a shared service, a module or an internal engineering asset; those outcomes are not interchangeable.

The disappearance of the brand does not make the underlying problem obsolete. Enterprises still distribute workloads among Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation sites, software-as-a-service platforms and remote users. Each environment has its own routes, gateways, private endpoints, identity controls, security services, quotas and billing rules. The enterprise may own the accounts and still lack one view of how a request moves among them. Prosimo’s importance lies in the attempt to own that view.

The acquisition therefore supplies the narrative spine rather than an epilogue. Prosimo built a cross-cloud control layer that could discover assets, interpret application context and steer traffic through security services. Palo Alto Networks first appeared as a technical partner whose VM-Series firewalls could be inserted into those paths. It later became the owner of the technology. A boundary that had separated routing orchestration from deep inspection moved inside one cybersecurity platform.

Multi-cloud routing is a contest over context

A route table can answer whether one prefix is reachable through another next hop. It cannot, by itself, explain which application a user intended to reach, whether the requester is trusted, whether an inspection service must see the traffic, whether a private endpoint is available, whether one cloud path costs more than another or whether a transaction is failing after the packet arrives. Multi-cloud operations turn those questions into a shared control problem.

Prosimo’s thesis was that routing authority should be informed by more than Layer 3 reachability. Its software attempted to combine cloud inventory, network state, application identity, user identity, risk, performance and transaction telemetry. That broader context allowed the platform to express policies such as connecting a defined application, separating a segment, choosing an ingress point or steering selected traffic through a firewall. The value did not come from inventing a new fibre path. It came from deciding how existing paths and services should be assembled.

This distinction explains why the company used the phrase “application experience infrastructure”. The term placed the application request above the individual network construct. A VPC, VNet, subnet, transit hub or private link became one component in an end-to-end path rather than the final object of management. The approach also pulled the product into several markets at once: cloud networking, application delivery, zero-trust access, network assurance, cost optimisation and security service insertion.

Breadth created both opportunity and ambiguity. A product that touches several teams can solve coordination failures that no single team owns. It can also be difficult to evaluate because network, security, cloud, application and finance teams use different definitions of success. Prosimo needed to prove that one cross-cloud model improved operations without turning into another privileged layer whose mistakes affected every environment.

What Prosimo was—and what remains

Prosimo was a privately held, Bay Area cloud-networking software company founded in 2019. Ramesh Prabagaran served as co-founder and chief executive, while Nehal Bhau served as co-founder and chief technology officer during the independent period. Public histories also identify Linus Aranha and Pradeep Aragonda in founding or senior engineering roles, though their exact titles should remain tied to dated biographies.

Its main platform was Application eXperience Infrastructure, commonly shortened to AXI. AXI used a central software layer for intent, topology, analytics and orchestration, together with distributed AXI Edges placed in cloud regions, colocation environments or adjacent on-premises infrastructure. The company later organised the offer as Full-Stack Cloud Transit, with Network Transit and App Transit handling different classes of connectivity. AIR analysed telemetry and produced operational insights; Nebula added a conversational interface in 2024.

Prosimo was not a cloud carrier. It did not own a global fibre backbone connecting every region. Paths could traverse cloud-provider backbones, the public internet, direct circuits, colocation links and enterprise networks. It was also not a firewall vendor in the same sense as Palo Alto Networks. Its role in the 2024 integration was to discover, segment and steer; VM-Series supplied deep security inspection.

After the acquisition, the safest description is “technology lineage”. The later integration statement highlights multi-cloud asset discovery and faster deployment of software firewalls for ingress, egress and east-west inspection. That is evidence that important Prosimo components survived. It is not evidence that the full historical AXI catalogue, commercial packaging or customer support model continued unchanged.

The post-SD-WAN problem

The founding team came from large-scale networking, application delivery and cloud infrastructure. Prosimo also emerged from the broader founder and engineering ecosystem associated with Viptela, the company that helped establish software-defined wide-area networking as an enterprise category. The next problem was different. SD-WAN could simplify how branches reached networks and applications, but it did not create one operating model inside and across several public clouds.

A multi-cloud application can depend on a web endpoint in one environment, a database or managed service in another, an identity provider outside both, private connectivity to a data centre and security inspection placed at selected boundaries. Each dependency can be represented through a different native construct. A network team may see prefixes and transit hubs; a cloud team may see accounts and resource objects; an application owner may see domains and transactions; a security team may see zones and inspection policy.

Prosimo began from the request rather than the branch. The relevant question was how a user or workload should reach an application with acceptable security, performance, availability and cost. That framing changed the object of routing from a destination prefix alone to a transaction carrying identity and application context. It also required the platform to collect and maintain considerably more information than a conventional router.

The timing was favourable. AWS, Azure and Google Cloud were expanding native transit and private-connectivity services. Enterprises could build sophisticated networks within each provider, yet the APIs, objects and policy models remained provider-specific. Prosimo’s opportunity was to coordinate those services rather than force every customer to replace them with a separate proprietary backbone.

From a 2019 foundation to the 2021 public launch

Prosimo was founded in 2019 but did not announce its public launch until 6 April 2021. General Catalyst led a US$25 million Series A at launch. The investor described the opportunity in terms of delivering application experience across clouds, which matched the founders’ effort to define a category beyond conventional branch connectivity.

The public launch placed the company in a crowded and unsettled market. Cloud providers were making their own networking services easier to consume. SD-WAN and SASE vendors were extending policy into cloud environments. Application-delivery vendors could optimise requests, while network-security companies could inspect them. Prosimo’s case depended on joining those functions through one cloud-oriented architecture without claiming to replace every surrounding system.

The funding gave the company room to build integrations, software edges, analytics, a commercial organisation and partner relationships. It did not prove product-market fit, revenue scale or durable differentiation. No audited revenue, annual recurring revenue, customer count or valuation was published in the supplied evidence. The financing record shows investor commitment to a thesis, not a complete account of operating performance.

In 2022, Prosimo completed a US$30 million Series B described as oversubscribed. Counting the two clearly identified rounds produces a verified total of at least US$55 million. Some databases may display a larger figure when they duplicate announcements or related records; those totals should not be used without resolving the underlying events.

AXI placed policy above the clouds and execution near workloads

The AXI architecture divided work between a central control and analytics layer and distributed software edges. The central layer held application and network intent, discovered assets, assembled topology, integrated identity, analysed telemetry and orchestrated changes. AXI Edges were deployed near workloads or users so that policy could be applied without forcing every path through one distant physical hub.

This separation resembles other software-defined systems, but the objects were cloud-specific and application-aware. The controller needed access to cloud accounts and APIs, while the edge needed connectivity to native transit services, workload networks, private endpoints or external paths. The platform’s authority came from combining those two views: global intent above the clouds and local execution close to the relevant traffic.

The architecture also created a practical deployment boundary. Each edge consumed cloud resources, needed high-availability design and had to be upgraded, monitored and secured. The control layer required credentials with enough privilege to discover assets and alter network state. An enterprise gained a common workflow but added a new management system whose availability and correctness mattered to production reachability.

Prosimo sometimes used autonomous-cloud-networking language. The evidence supports automation, recommendations and API-driven orchestration. It does not support a network that could operate independently of human policy, cloud-provider services or the underlying transport. Operators still defined intent, approved access, resolved exceptions and carried responsibility for the result.

AXI Edge was a placement decision, not a generic appliance

An AXI Edge could be deployed in a cloud VPC or VNet, a colocation environment or adjacent infrastructure. AWS’s technical walkthrough showed an edge VPC connected to workload VPCs through Transit Gateway, with optional firewall chaining and access from remote users or on-premises sites. The design placed Prosimo’s execution point inside the cloud topology rather than at a remote corporate perimeter.

Placement affected more than latency. It determined where traffic entered the policy domain, which cloud backbone or internet path it used, where encryption and inspection occurred, and which telemetry the platform could collect. A poorly placed edge could create backhaul or cost; a well-placed edge could shorten a path or keep traffic close to a workload.

Distributed placement increased the number of failure domains the platform had to manage. Capacity, software versions, cloud-zone design, route convergence and access permissions could differ by region. High availability required more than running two instances: the controller, cloud route tables, security services and return paths also had to agree on the failover state.

The edge was therefore part of a wider operating system. Its value depended on asset discovery, topology, policy and analytics remaining consistent with the cloud environment around it. Treating it as a self-contained virtual appliance would miss the architecture Prosimo was trying to sell.

The underlay always belonged to someone else

Prosimo coordinated transport but did not own the physical route. An application path could use AWS or another cloud backbone, a public internet connection, Direct Connect or ExpressRoute, a colocation service, a carrier circuit or an enterprise network. The platform could select and orchestrate among available options; it could not remove the latency, packet loss, outage domains or pricing rules created by those providers.

That boundary matters when evaluating performance claims. A controller can choose a better observed path or move ingress closer to a user. It cannot guarantee that a carrier will not fail, that a cloud region will remain available or that an external dependency will respond quickly. Application experience also includes DNS, server processing, storage, browser behaviour and third-party services outside the network controller’s authority.

The lack of a proprietary backbone was not simply a weakness. It allowed Prosimo to use infrastructure that enterprises had already purchased and to benefit from cloud-provider investment. It could reach regions without building fibre and could coordinate native systems such as AWS Cloud WAN. The trade-off was dependence on API stability, service quotas, commercial terms and provider-specific semantics.

The platform’s claim was therefore about operational control, not physical ownership. It attempted to make heterogeneous underlays behave as one managed system while preserving their native advantages. Whether that abstraction reduced or merely relocated lock-in depended on how portable the policy, topology and edge deployment were.

Network Transit handled reachability among network objects

Network Transit focused on VPCs, VNets, subnets, regions, sites and segments. It coordinated native cloud transit and route constructs so that teams could build connectivity through a common workflow rather than configuring every provider separately. The product supported the conventional network requirement: a source prefix or segment must reach a destination through an allowed path.

This was not a claim that cloud differences vanished. AWS, Azure and Google Cloud expose different objects, quotas and route behaviour. Overlapping address space, asymmetric paths, private endpoints and provider-specific service limits still required engineering. Prosimo could normalise common operations and show relationships, but the underlying systems retained their own constraints.

Network Transit also carried segmentation. Route domains and policy could separate environments or limit reachability. The controller needed to understand where a segment existed across clouds and how native constructs implemented the boundary. A policy expressed once could still produce several provider-specific changes.

The benefit was a unified intent surface. The risk was translation. If the common policy and the cloud configuration diverged, the enterprise could believe a segment was protected while the provider state said otherwise. Reconciliation, audit and explicit failure reporting were therefore as important as the initial provisioning workflow.

App Transit made the application a routing object

App Transit extended the model beyond subnets. It could use application domain, identity, request type, transaction health, risk and performance when deciding how a user or workload reached a service. This was Prosimo’s clearest attempt to distinguish its platform from a conventional cloud router.

The application view was useful because modern services are not always represented cleanly by fixed addresses. Managed platforms, SaaS endpoints and distributed components can change while the application identity remains meaningful. A policy that refers to the service or user can be more durable than one written only around addresses and ports.

The model demanded accurate discovery. The controller had to know which domains and endpoints belonged to an application, which dependencies were required and which identity provider assertions were trustworthy. Stale mapping could route a request through the wrong path or apply the wrong security rule. The application abstraction did not eliminate the need to understand network state; it placed another semantic layer above it.

Prosimo’s combination of Network Transit and App Transit acknowledged that enterprises contain both worlds. Legacy systems, private subnets and IP-based controls remain, while newer applications rely on domains, identity and managed services. Full-Stack Cloud Transit was the product name for operating those models together rather than forcing one to replace the other.

Identity expanded the routing decision and the trust boundary

Application-aware access required identity integration. The platform could use a user or workload context to decide whether and how a connection should be established. This supported a zero-trust style of policy in which location alone was not sufficient evidence of authority.

Identity improved precision but introduced another dependency. The route or application policy now relied on the identity provider, its claims, session state and group data. A network path could fail because authentication was unavailable or because an attribute changed, even when the routers and edges were healthy. Troubleshooting had to cross the boundary between networking and identity operations.

The controller also became a concentration point for sensitive context. It could hold topology, application relationships, user attributes, risk signals and policy outcomes. That dataset improved diagnosis and optimisation while increasing the consequences of unauthorised access. Least privilege, retention, audit and separation of duties were therefore architectural requirements, not administrative afterthoughts.

Prosimo’s approach illustrates a wider change in infrastructure. Routing and access policy increasingly depend on identity and application semantics. The more context a platform sees, the more useful its decisions can become—and the more carefully its authority must be governed.

Asset discovery created the graph on which every later decision depended

A cross-cloud controller cannot govern what it cannot see. Prosimo developed cloud asset discovery and maps that represented VPCs, VNets, subnets, applications, connectivity and security relationships. These views supported onboarding, design, troubleshooting and policy.

Discovery was strategically important because cloud estates change outside central network workflows. Application teams can create accounts, networks, endpoints and managed services through their own automation. A manually maintained diagram becomes stale. An API-driven inventory can provide a more current graph, though its completeness still depends on account coverage, permissions, parser logic and provider APIs.

The graph was not only documentation. It was the data structure from which routing, segmentation, service insertion and optimisation could be calculated. If an asset or dependency was missing, every conclusion above it could be wrong. The topology therefore needed provenance: when it was collected, which account supplied it, which regions were covered and whether any request failed.

This graph also helps explain the acquisition. Palo Alto Networks can create security value when it knows where workloads and traffic paths exist. A system that discovers cloud assets and can alter routes can shorten the distance between buying a software firewall and placing it correctly. Nehal Bhau’s later integration statement specifically emphasised asset discovery and accelerated deployment of software firewalls.

AIR turned edge telemetry into operational recommendations

Application-driven Intelligent Results, or AIR, analysed telemetry collected through AXI Edges. AWS’s walkthrough described visibility into round-trip time, processing time, application response time, transaction type, risk and policy outcomes. The platform could correlate user, network and application observations instead of presenting isolated device counters.

That correlation addressed a familiar operations problem. A slow transaction can be caused by the user path, the edge, the cloud backbone, a security service or the application itself. A cross-layer view can narrow the search more quickly than separate consoles. It can also support recommendations about path, placement, risk or cost.

The quality of a recommendation depended on telemetry coverage and the model used to interpret it. An edge could observe only the traffic that traversed it. External application dependencies and provider-internal conditions might remain invisible. A recommendation could be directionally useful without proving the root cause.

The telemetry also had governance value. Historical observations could help an enterprise explain why a route or policy changed. They could also expose sensitive application usage and user behaviour. Public material did not provide a complete account of retention or post-acquisition data governance, so those questions remain part of customer due diligence.

AWS supplied the clearest documented implementation

Prosimo’s AWS work produced the strongest public technical evidence. The company integrated with AWS Transit Gateway, Cloud WAN, PrivateLink and the Marketplace for Containers Anywhere deployment workflow. AWS published a walkthrough of AXI Edge placement, application onboarding, identity, security and optimisation.

AWS Cloud WAN was particularly significant. It supplied a cloud-native backbone and segmentation service that Prosimo could orchestrate rather than replace. The arrangement showed the product’s cooperative model: AWS owned the native network and global infrastructure; Prosimo provided cross-cloud intent, application context, edge software and analytics.

The Marketplace workflow simplified the first deployment step by packaging AXI Edge through an approved channel. It did not eliminate the later work of account permissions, route design, high availability, capacity and operations. Day-zero automation can reduce installation friction while leaving the long-term control problem intact.

A named Flexport reference supported the AWS Cloud WAN use case in company material. It is evidence that an enterprise customer was willing to endorse the architecture, not an independent audit of deployment scale, savings or availability. Customer quotations should therefore be used as examples of adoption rather than as universal performance evidence.

Azure and Google Cloud completed the multi-cloud claim

Prosimo also supported Microsoft Azure and Google Cloud environments. Its product material described orchestration around Azure Virtual WAN and Google Cloud networking and private-service constructs. The goal was to present one operating model while allowing each provider’s native network to remain in place.

The existence of support does not prove identical features across providers. Cloud APIs mature at different speeds, and comparable product names can hide different semantics. A route, segment, private endpoint or service insertion may need provider-specific treatment. The supplied evidence does not reconstruct a feature-by-feature parity matrix for every region and release.

Multi-cloud abstraction is therefore best understood as a translation system. It can standardise common intent and workflow, but it must preserve the details that affect security, cost and failure. A platform becomes dangerous when the interface looks uniform while the implementation differences are hidden from operators.

The same point applies after acquisition. Palo Alto Networks may use the common graph to place security across clouds, but cloud providers still control the native objects that implement the path. Ownership of the orchestration layer does not create ownership of the cloud underlay.

The product expanded from connection to lifecycle

By 2023, Prosimo described workflows for designing, building, troubleshooting and managing multi-cloud networks. The product had moved beyond establishing a tunnel or gateway. Asset discovery supported design; orchestration created connectivity; maps and telemetry supported troubleshooting; policy and historical state supported ongoing management.

This lifecycle framing broadened the commercial buyer. A network engineer could use topology and path analysis; a cloud platform team could onboard accounts and services; a security team could review segmentation and inspection; a migration team could plan changes; a FinOps team could examine route and egress implications. The platform’s value increased when several groups used the same evidence.

Shared evidence can also create governance conflict. A central platform may expose that a cloud team’s native configuration differs from enterprise policy. The organisation must decide which system is authoritative and who can approve remediation. Software cannot resolve that institutional question by itself.

The lifecycle story also strengthened switching costs. Once a controller holds the asset graph, policy, telemetry, edge placements and automation integrations, replacing it requires more than moving a circuit. The customer must export or reconstruct the operating model. Prosimo sold reduced cloud fragmentation while creating the possibility of controller dependence.

Segmentation ran from network reachability to application policy

Prosimo presented segmentation across Layers 3 through 7. At the network layer, route domains and segments determined which subnets or sites could communicate. At higher layers, application identity, user context and transaction properties could refine the rule.

The layered model could reduce the gap between a network zone and an application policy. A business service might be permitted even when broad subnet-to-subnet reachability remained blocked. Conversely, a reachable network path could still be denied because the identity or application context failed.

This did not turn Prosimo into a full next-generation firewall. The 2024 Palo Alto Networks integration separated responsibilities: Prosimo orchestrated routes, segmentation and service insertion; VM-Series performed deep inspection. The distinction matters because policy steering and security enforcement fail in different ways.

A segment is effective only if all relevant paths are represented. An unknown route, native cloud exception or failed service insertion can bypass the intended control. Assurance therefore requires comparing declared policy with provider state and observed traffic—not trusting the controller’s configuration screen alone.

Service insertion joined route control to firewall economics

Cloud security design must decide where inspection occurs. Centralised firewalls can simplify policy and reduce the number of appliances, but they can create backhaul, concentration and scale pressure. Distributed firewalls stay closer to workloads and reduce some path distortion, but they multiply deployment, licensing, upgrades and policy operations.

Prosimo supported both patterns in its VM-Series integration. Policy could steer selected traffic through a central inspection point or through firewalls distributed in application VPCs. The controller updated the surrounding routes while Palo Alto Networks supplied the inspection function.

The architecture made route orchestration commercially valuable to a security vendor. A software firewall cannot protect traffic that never reaches it. Discovery, placement and route updates reduce the operational friction between purchasing security capacity and inserting it into a live path. That is a plausible strategic reason for Palo Alto Networks to absorb Prosimo technology.

It also increases the controller’s blast radius. An incorrect policy can bypass inspection, create a loop, produce asymmetric routing or take an application offline. Health checks, staged change, simulation, audit and rollback are necessary because a service-insertion error is both a network and a security event.

The 2024 partnership should not be backdated into an acquisition

Prosimo and Palo Alto Networks announced their VM-Series integration on 12 June 2024. The release described a joint technical and commercial solution. It did not say that Palo Alto Networks had acquired Prosimo. Treating the announcement as proof of ownership would collapse two distinct events.

The partnership nevertheless created a bridge. Prosimo could show how its route and policy system made VM-Series easier to deploy across clouds. Palo Alto Networks could evaluate the technology inside a real integration before the later corporate transition. Public evidence does not describe the acquisition process, so any claim that the partnership was designed as a formal pre-acquisition step would be speculation.

By early 2025, founder and employee histories had changed. The company page later carried an acquired status. In late 2025, Bhau said the technology was fully integrated into Palo Alto Networks products. Together, those records support the acquisition conclusion while leaving the legal mechanics unresolved.

This sequencing matters to editorial accuracy and to customers. A partnership means two vendors, two support structures and a defined integration boundary. An acquisition can move roadmaps, data, contracts and authority into one company. The transition changes more than branding even when the technical path initially looks similar.

Nebula turned the topology graph into a conversational interface

Prosimo introduced Nebula in February 2024 as part of an AI Suite for multi-cloud networking. The assistant was designed to answer natural-language questions about overlapping networks, cost, route health, security-policy violations and other conditions represented in the platform’s graph and telemetry.

The useful asset was not the language interface by itself. It was the structured cross-cloud context beneath it. A general model cannot diagnose a private route or segment it cannot see. Nebula could draw on asset inventory, topology, policy and observations that Prosimo already collected. This made the earlier investment in a common graph relevant to AIOps.

Conversational access could make complex data available to more operators. It could also create false confidence if the response omitted an unsupported asset, misunderstood the question or treated a recommendation as an approved action. High-risk changes still needed deterministic controls, permission boundaries and human review.

Prosimo reported possible improvements such as 60–80% lower mean time to resolution and more than 60% lower cloud-networking cost. Those numbers were company claims in a product announcement. No independent methodology or customer baseline in the supplied evidence proves that they apply generally. They can be cited as Prosimo’s proposed benefit, not as measured market fact.

AI workloads were a new use case, not proof of a new market

The same 2024 announcement framed Prosimo’s architecture as useful for AI workloads. Distributed AI systems may need private access to data, connections among clouds and data centres, compliance controls and routing that reflects application behaviour. Those requirements are compatible with the platform’s existing asset, policy and path model.

The label did not change the underlay. Prosimo still depended on cloud networks, carriers and customer infrastructure. Nor did it supply GPU compute or model-development software. Its potential role was the connectivity and security layer around distributed data and services.

AI positioning was strategically logical because the value of cross-cloud topology grows as data and services become more distributed. It was also a marketing category introduced shortly before the company ceased to operate independently. The supplied evidence does not establish separate AI-product revenue, named production deployments or audited workload outcomes.

The durable point is that multi-cloud telemetry can become an input to machine-assisted operations. The current product question is whether Palo Alto Networks retained that context and how it exposes the capability. Public evidence at the cutoff does not provide the complete answer.

The commercial model sold software over infrastructure it did not own

Prosimo’s independent business was a software subscription and services proposition rather than a carrier model. Customers deployed AXI Edges in their environments and connected cloud accounts to the control layer. Revenue would have depended on licences or subscriptions, support, professional services and channel activity, though exact pricing and contract metrics were not published in the supplied evidence.

The model could scale without owning fibre. One software platform could coordinate many cloud regions and customer environments. Gross economics, however, cannot be inferred from that architecture. Engineering support for vendor APIs, edge lifecycle, security integrations and enterprise deployment can be expensive, while cloud resources consumed by the edges may be paid by the customer rather than the vendor.

Prosimo used cloud marketplaces, integration partners, channel organisations and named customer references to reach enterprises. Those relationships are not equivalent. A marketplace listing proves a procurement and deployment path. A technical integration proves that two systems can be combined under defined conditions. A customer quotation provides a reference. None of them, alone, establishes the number of paying customers or recurring revenue.

The company’s breadth may have increased sales complexity. Network, security, cloud and application teams could all benefit, but budget ownership might be unclear. The product needed a buyer willing to fund a common control layer rather than allowing each cloud and team to operate separately.

Partners, customers and investors occupied different positions

Amazon Web Services was both an underlay provider and a go-to-market integration partner. Azure and Google Cloud were supported environments. Identity providers supplied authentication context. Firewall vendors supplied inspection. Colocation and carrier services could host or connect edges. Channel partners could design and operate deployments.

Flexport appeared as a named customer reference in the AWS Cloud WAN material. The reference demonstrates enterprise interest in the architecture, but the supplied evidence does not disclose the complete scope, duration or commercial value of the deployment. It should not be turned into a proxy for the entire customer base.

General Catalyst led the Series A and participated in governance through investor involvement. WRVI or Celesta-related investors appeared in company material, and later Prosimo messaging referred to additional prominent investment participation, including a BlackRock-related name whose exact vehicle was not resolved in the research. These records support a well-connected financing base, not a complete cap table.

Palo Alto Networks occupied the most consequential relationship. It moved from security partner in 2024 to acquirer by early 2025. The sequence illustrates how an ecosystem dependency can become a control relationship when one participant purchases the software layer coordinating the path to its product.

At least US$55 million was raised; the exit economics remain unknown

The verified financing record consists of a US$25 million Series A in April 2021 and a US$30 million Series B in 2022. The total is at least US$55 million. No audited cap table, valuation, debt schedule or later financing round is available in the supplied evidence.

The acquisition consideration was not disclosed or independently verified. Without a price, the outcome cannot be classified responsibly as a strategic premium, a modest technology purchase, an acqui-hire or a distressed sale. Continuing product integration supports the view that the technology had value; it does not reveal the return earned by investors or founders.

Palo Alto Networks’ revenue and market scale should not be attributed to Prosimo after the acquisition. Once the startup ceased to be separately observable, there was no standalone revenue, profit or customer segment to analyse. A larger owner can make the technology more widely available while making its individual economics less visible.

The absence of a formal acquisition announcement is itself relevant. Customers, employees and researchers normally use such releases to determine timing, support and strategic rationale. Here, status must be reconstructed from professional histories, a company-page label and a later founder statement. That is enough to correct the company’s status and not enough to invent transaction detail.

Competition came from platforms, clouds and internal engineering

Prosimo competed with specialist multi-cloud networking platforms such as Aviatrix and Alkira, with enterprise networking and SASE vendors, and with native services from AWS, Azure and Google Cloud. It also competed with a do-it-yourself model in which an enterprise uses infrastructure as code, provider transit services, route tables and firewalls directly. The alternatives solved different portions of the same problem.

A specialist controller could offer one topology and policy model across providers. A cloud-native design could reduce third-party dependence and fit closely with one provider. A carrier-backed service could supply physical transport. A SASE or security platform could combine connectivity with enforcement. Internal engineering could preserve control at the cost of staffing and integration burden.

Prosimo’s differentiation was the combination of application and network transit, distributed edges, cloud-native orchestration, topology, telemetry and service insertion. The same breadth made comparison difficult. Buyers needed to test the exact cloud services, routes, identity systems and security pattern they intended to use rather than compare category labels.

Acquisition changes the competitive frame. Prosimo no longer has to win as a standalone company, but its technology must justify itself inside Palo Alto Networks. The relevant comparison becomes whether integrated discovery and route orchestration improve deployment of Palo Alto security products and whether customers accept the resulting platform dependence.

Native cloud services were both foundation and substitute

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN and Google Cloud networking gave enterprises powerful native options. Prosimo relied on those services and competed against the possibility that customers could operate them directly.

This relationship created a moving boundary. As a cloud provider added global routing, segmentation, private service access or central policy, some third-party functions became easier to reproduce natively. At the same time, every new native service added another object that a cross-cloud controller could discover and coordinate. Cloud progress could narrow one part of Prosimo’s value while expanding the need for translation across providers.

The deciding factor was organisational as much as technical. A single-cloud company with strong internal engineering might prefer native tools. A multi-cloud enterprise with fragmented teams could value one control plane. A regulated organisation might prefer a third-party evidence layer but worry about privileged credentials and data concentration.

No architecture removed lock-in. Native tools increased dependence on one cloud’s APIs and semantics. A cross-cloud controller increased dependence on its graph, policy and edge software. The useful question was whether the dependency was visible, portable and matched to the organisation’s operating model.

Failure could occur at the controller, edge, cloud API, identity system or underlay

Prosimo’s distributed architecture reduced dependence on one traffic hub but created several interacting failure domains. The central service could become unavailable or hold stale intent. An edge could fail or become isolated. A cloud API could reject part of a change. The identity provider could become unavailable. The underlay could lose capacity or take an unexpected route. An inserted firewall could exhaust resources.

Partial failure is especially difficult. One provider may accept a route update while another rejects it. The controller’s intended state can then diverge from actual cloud state. Traffic may take an asymmetric path or bypass inspection. A reliable system needs reconciliation, idempotent operations, staged change, explicit error state and rollback that accounts for each provider’s behaviour.

The public evidence describes high-level availability and optimisation but does not include an independent failure-injection study, complete incident record or universal service-level result. Claims about resilience should therefore remain tied to documented architecture or named customer evidence.

Acquisition introduces another failure domain: product continuity. Customers need to know which console, API, edge image, policy model and support organisation replaces the historical Prosimo system. A technically successful code integration can still create migration risk when commercial and operational boundaries are unclear.

Cloud credentials made the controller part of the critical management plane

Asset discovery and orchestration required access to cloud accounts. Read-only inventory could use limited privileges, while route, segment and service-insertion changes needed stronger authority. The controller therefore sat inside the privileged management plane even though it did not own the workloads.

Credential compromise could expose topology or permit broad changes. A software defect or operator mistake could propagate policy across several clouds. The risk grew with the platform’s usefulness: the more accounts and services it could govern, the larger the potential blast radius.

Enterprises needed least-privilege roles, separate credentials for discovery and change, multi-party approval, complete audit, rotation, emergency revocation and a recovery path that did not depend solely on the same controller. The supplied public material does not provide a full independent security assessment, so these remain necessary deployment controls rather than verified product guarantees.

The telemetry graph was equally sensitive. It could reveal application names, network structure, policy, user relationships, route health and cost patterns. Post-acquisition governance should clarify where that data is stored, which Palo Alto Networks products can use it and how legacy customer permissions were migrated. Public evidence at the cutoff does not answer those questions.

The acquisition moved a cloud-neutral layer into a security platform

Prosimo’s independent position allowed it to present itself as a common layer across clouds and security services. Once Palo Alto Networks became the owner, the incentives changed. The acquired technology could make VM-Series and other Palo Alto products easier to deploy. That may produce a better integrated experience while raising questions about support for third-party inspection services.

Ownership does not prove that neutrality disappeared. The supplied evidence does not provide a current partner matrix or product architecture. It does, however, change the question customers should ask. They need to know whether the route controller remains open to several security vendors, whether policy and telemetry can be exported, and whether the platform’s optimisation favours the owner’s portfolio.

The integration statement emphasised ingress, egress and east-west inspection. That focus suggests that Prosimo’s topology and orchestration became part of a security-deployment system. It does not establish that historical App Transit, user access, cost optimisation or every cloud-networking workflow survived as a separate capability.

This is a common infrastructure pattern. A startup abstracts a difficult coordination problem; a larger platform vendor buys the abstraction because it increases consumption and control of the platform’s core product. The buyer gains a route to deployment. The customer may gain integration and lose some supplier independence.

The current product map is the largest missing fact

The public record confirms acquisition and integration but does not identify a complete mapping from AXI, Network Transit, App Transit, AIR and Nebula to current Palo Alto Networks products or stock-keeping units. It does not publish legacy-support deadlines, migration procedures or a feature-by-feature continuity table.

That gap prevents a present-tense product review. Historical descriptions can explain what Prosimo built and why it mattered. They cannot tell a buyer which capabilities are available, licensed or supported today. Contemporary deployment advice must rely on current Palo Alto Networks documentation rather than archived Prosimo releases.

The missing map also limits strategic analysis. Full absorption of the topology graph and orchestration layer would differ from selective use of asset discovery and firewall placement. One outcome would create a broad multi-cloud control service; the other would use Prosimo mainly to accelerate security deployment. The founder statement supports continuing technology and leaves this architectural boundary unresolved.

A future product document, migration guide or customer case study could resolve much of the uncertainty. Until then, the precise formulation is that Prosimo technology was integrated into Palo Alto Networks products, according to a co-founder, while the scope and packaging remain unverified.

Who controls multi-cloud routing?

No single party controls the entire path. The enterprise controls account ownership, business intent, application design and the credentials it grants. A cross-cloud controller can discover topology, translate policy, select paths and alter native route state. Cloud providers control their APIs, transit services, private endpoints, backbone and many failure domains. Carriers and colocation providers control other portions of transport. Security services control whether inspected traffic is allowed.

Prosimo sought the most strategically useful middle position. It did not own the underlay, but it tried to own the graph and the policy translation above it. Whoever controls that layer can decide which assets are visible, how segments are represented, where edges are placed, which service inspects traffic and which telemetry is considered authoritative. That is practical routing power even when the fibre belongs to someone else.

After the acquisition, Palo Alto Networks owns the surviving Prosimo technology and determines how it is integrated, packaged and developed. The cloud providers remain sovereign inside their environments, and the enterprise can revoke credentials or choose another architecture. Yet exit may be costly if the topology, policy and operating workflows have become dependent on the controller.

The answer is therefore layered rather than absolute: the enterprise authorises; the controller coordinates; the cloud and carrier underlays transport; the security platform enforces. Prosimo’s history matters because it shows that ownership of the coordinating layer can change without any cloud account or physical route changing hands.

Principal source record

Why Prosimo still matters after acquisition

Prosimo captured a real shift in infrastructure. The unit of network operations is moving from the device and prefix toward the application, identity, service dependency and policy graph. Cloud-native APIs make network state programmable, while distributed software edges make enforcement movable. A controller that sees several clouds can coordinate actions that no individual cloud console can complete alone.

The company also exposed the cost of that coordination. A common layer needs privileged credentials, continuous API maintenance, accurate discovery, semantic translation, telemetry and operational discipline. It can reduce fragmented work while creating a new concentration point. The same system that simplifies routing can enlarge the blast radius of one bad decision.

Palo Alto Networks’ acquisition makes the control issue more visible. Networking and security are converging around service insertion, workload discovery and policy. A security vendor that knows the topology and can change routes does not simply inspect traffic presented to it; it can help determine which traffic reaches inspection and where.

Prosimo should therefore be remembered neither as a failed standalone brand nor as proof that one platform solved multi-cloud. Its durable contribution was to define the cross-cloud graph as infrastructure. The remaining question is whether that graph, now inside a larger security company, stays transparent, portable and governable enough for customers to trust it.

The signals that will show what survived the acquisition

Prosimo’s historical architecture is well documented; its current product form is not. The next stage should be evaluated through evidence that connects the acquired code to active products, customers and operating outcomes. A broad statement that technology is “fully integrated” is useful status evidence and an incomplete product description.

A current feature and product map

The first signal is a Palo Alto Networks document that maps historical Prosimo functions to present products, APIs and licences. Monitor asset discovery, Network Transit, App Transit, edge deployment, topology, service insertion, AIR-style analytics and Nebula-style interaction separately. A map that mentions only firewall placement would indicate selective absorption rather than complete platform continuity.

Legacy-customer migration and support

Monitor migration guides, end-of-life notices, support dates, contract changes and the treatment of existing AXI Edges. The decisive evidence is whether customers can move policy, topology history and integrations without rebuilding the environment. Silence on migration is not proof of abandonment, but it prevents assessment of continuity.

Multi-vendor security-service neutrality

The 2024 design separated Prosimo steering from VM-Series inspection. Monitor whether the integrated platform still supports third-party firewalls and service chains on equal technical terms. Restricting the graph to Palo Alto enforcement may improve integration while changing the product’s role from neutral orchestration to security-platform distribution.

Activated firewall-deployment outcomes

Monitor named customer evidence for faster asset discovery, firewall placement and route updates across ingress, egress and east-west paths. Useful metrics include deployment time, route-change failure, policy exceptions, bypass incidents and rollback performance. Counts of discovered assets or deployed firewalls are stronger than general AI or automation claims.

Cloud-API and regional coverage

AWS, Azure and Google Cloud continue to change native transit, private-service and security constructs. Monitor which accounts, regions and services the integrated platform supports, how quickly it adapts to API changes and where feature parity is intentionally absent. The common interface is valuable only when its coverage and exceptions are explicit.

Topology and telemetry governance

Monitor where legacy Prosimo topology, application and user data is stored; how long it is retained; which Palo Alto products can query it; and how customers export or delete it. The graph may become a shared security-platform asset. That can improve correlation and increase the consequences of one access-control error.

Evidence for AI-assisted operations

Monitor whether Nebula’s natural-language workflows appear in a current product, which tools they can invoke, how answers cite underlying evidence and whether changes require deterministic approval. Independent customer baselines should replace the historical vendor claims about MTTR and cost before those figures are repeated as outcomes.

Five evidence-supported scenarios

Broad integration into a multi-cloud security control plane

Palo Alto Networks exposes discovery, routing, service insertion and analytics as shared capabilities across its cloud-security portfolio. Customers gain one operating model for finding workloads and placing enforcement. The value rises with product integration; switching costs rise with the same graph and policy dependence.

Selective absorption around firewall placement

Only asset discovery and route orchestration needed for software-firewall deployment survive as visible functions. Historical App Transit, application experience and cost optimisation fade or become internal components. This scenario is consistent with the emphasis of the late-2025 founder statement and cannot be confirmed without a current product map.

Legacy retirement and customer re-architecture

Standalone Prosimo contracts, consoles or edges reach end of support, and customers move to Palo Alto products or another multi-cloud platform. The operational risk depends on export, policy translation and whether native cloud state can be preserved during migration.

Hyperscaler-native services reduce the value of a common controller

Cloud providers improve cross-region and cross-cloud functions, while enterprises consolidate workloads. The market for a separate multi-cloud transit controller narrows. Prosimo-derived technology remains useful mainly for security discovery and service insertion rather than as a broad network operating layer.

Security-led control-plane consolidation accelerates

Other cybersecurity vendors acquire or build routing, topology and cloud-asset control. Networking becomes an embedded function of security platforms rather than a separate market. Enterprises receive tighter enforcement integration and face greater pressure to govern platform concentration.

Professional implications by stakeholder

Cloud and network teams should inventory the policy, credentials and edge functions that depend on historical Prosimo components. Security teams should verify inspection paths independently of the controller. Procurement teams should require current product names, support and export terms. Application owners should test transaction paths during migration. Executives should treat the topology graph as strategic infrastructure whose ownership can change through acquisition even when the cloud accounts remain with the enterprise.

Governing the layer that can see and change every cloud

The real control map

Formal ownership of cloud accounts is only the first layer of control. Operating power sits with whoever holds credentials, maintains the topology graph, translates policy, deploys edges, selects service chains and interprets telemetry. Cloud providers control native implementation and transport; Palo Alto Networks controls the acquired technology; enterprise leaders decide how much authority to delegate and how costly exit will become.

The governance objective is not to eliminate delegation. Multi-cloud coordination requires automation. The objective is to make authority bounded, observable and reversible. A platform should be able to change what it is authorised to change, prove what it changed and leave enough independent evidence for the enterprise to recover when the platform is unavailable or replaced.

Decision one: publish the lineage before expanding the promise

Palo Alto Networks should identify which Prosimo components remain active, which were rewritten, which are internal and which are retired. Product names, APIs, support boundaries, data migration and commercial ownership should be explicit. Without that map, customers cannot distinguish a maintained control plane from a useful set of acquired engineering components.

Decision two: preserve portability of policy and topology

Customers should be able to export asset inventory, topology relationships, routing intent, segmentation policy, service-chain definitions and historical events in documented formats. Portability does not require another vendor to reproduce every feature. It requires that leaving the platform does not erase the enterprise’s own operating knowledge.

The incentive of an integrated security vendor is to make the common graph increase consumption of its products. The customer’s incentive is to retain the ability to compare and substitute enforcement. Contract and architecture should reconcile those interests before the graph becomes irreplaceable.

Decision three: separate discovery authority from change authority

Read access and write access should not share one undifferentiated cloud role. Discovery can operate continuously with narrow permissions. Route, segment and service-insertion changes should use separate credentials, time-limited elevation, approval and policy-specific scopes. Compromise of the analytics layer should not automatically become authority to alter every production path.

Decision four: make every cross-cloud change a staged transaction

A controller cannot assume that AWS, Azure, Google Cloud and inserted security services commit one atomic change. Leadership should require pre-checks, per-provider state, bounded rollout, health criteria, reconciliation and rollback. A change is complete only when intended and observed state agree across the relevant domains.

The operating metric should not be “automation success” as reported by the controller. It should be the rate of fully reconciled changes, partial failures, policy bypasses and recoveries. This shifts incentives from speed of execution to correctness of outcome.

Decision five: keep independent observability outside the same control plane

The system that makes the change should not be the only system proving that the change worked. Route collectors, cloud-native logs, firewall telemetry, application tests and independent monitoring should validate critical paths. Otherwise, a shared model error can produce a false picture of both intent and result.

Decision six: govern the topology graph as sensitive infrastructure

The graph can reveal workloads, identities, dependencies, security boundaries, cost and traffic behaviour. Leaders should define data residency, retention, encryption, access review, product-to-product sharing and deletion. Acquisition should trigger a new data-governance review because the controller’s owner and product ecosystem have changed.

Decision seven: contract for continuity through ownership and product change

Support, export and migration rights should survive acquisition, rebranding and product consolidation. Contracts should identify the responsible legal entity, notice periods, assistance obligations and the treatment of deployed edges. A customer should not discover during an end-of-life event that the policy and topology required for exit were never exportable.

Second-order effects

Routing orchestration can become a distribution channel for security

When the owner of the route controller also sells the firewall, the controller can reduce deployment friction and increase security-product adoption. This may improve coverage and standardisation. It can also make a routing decision inseparable from a commercial product choice.

A shared graph can improve operations and centralise error

One topology and telemetry model can shorten incident response and reduce conflicting inventories. The same model can propagate an incorrect assumption across several clouds, teams and enforcement points. Scale magnifies both the benefit and the error.

Abstraction can reduce cloud lock-in and create controller lock-in

A common policy layer can make cloud-specific objects easier to manage. If the enterprise loses the ability to operate those objects without the controller, dependency has moved rather than disappeared. Portability must include knowledge and policy, not only data export.

Third-order effects

Security platforms may absorb more network control

If Prosimo-derived capabilities improve firewall deployment, competitors will have an incentive to combine asset discovery, route orchestration and enforcement. The boundary between cloud networking and cybersecurity will continue to narrow, affecting procurement, team structure and accountability.

Cloud providers may expose more cross-cloud control to defend their position

A strong third-party orchestration layer weakens the cloud console as the enterprise’s primary control surface. Hyperscalers can respond with broader native policy, partnerships or managed cross-cloud services. The result may be more choice and a larger number of overlapping controllers.

Operational knowledge can migrate from engineers into proprietary graphs

As topology, policy and diagnosis become machine-readable, organisations may rely less on engineers who understand provider-specific behaviour. Productivity can improve while recovery becomes harder if the graph is unavailable, wrong or no longer licensed. Leadership must preserve human and documentary knowledge of the underlay.

Irreversible risks

Loss of an exportable operating model

Once years of policy, dependencies and incident history exist only inside one platform, reconstruction can become more expensive than renewal. This is the deepest lock-in risk because it concerns knowledge, not a replaceable circuit.

Correlated cross-cloud failure

A privileged controller can propagate one bad policy or compromised credential across environments that were expected to provide diversity. Logical multi-cloud deployment does not guarantee independent control planes.

Security-service monoculture

Tight integration may gradually make third-party inspection impractical even without a formal prohibition. The enterprise can lose negotiating leverage and architectural diversity before it notices that the route graph assumes one enforcement stack.

Unrecoverable data-governance ambiguity

If topology and user-context data are merged into a broader product ecosystem without clear lineage, later separation or deletion may be difficult. Governance should be set before integration creates shared derived data.

Dependence on a product whose public boundary is unclear

An acquired capability can remain technically important while becoming commercially invisible. If customers cannot identify its owner, support and roadmap, they may carry critical dependency without a clear continuity contract.

The leadership judgement

Prosimo’s history shows that multi-cloud control belongs to the layer that can turn business intent into coordinated changes across several administrative domains. That layer does not own the clouds, yet it can become more influential than any single route table because it decides what the organisation sees and how policies are translated.

Palo Alto Networks acquired that capability by early 2025. The opportunity is a security platform that discovers assets and places enforcement with less manual work. The danger is a combined graph, routing and inspection authority that becomes difficult to audit or leave. Leadership should accept the efficiency only with bounded credentials, independent evidence, portable policy and contractual continuity.

The decisive asset is not the edge image or the route itself. It is the operating model that connects topology, identity, policy, telemetry and action. Whoever controls that model can shape multi-cloud routing. The enterprise remains in control only when it can verify, limit and replace the controller.