Summary

  • Prosimo was founded in 2019 and raised at least US$55 million in Series A (2021) and Series B (2022) rounds; audited revenue, valuation, and acquisition price were not disclosed
  • AXI combined centralised intent, topology, and analytics with distributed edge nodes that discovered cloud assets, connected applications, and inserted security services without owning the physical infrastructure
  • The VM-Series integration announced in June 2024 preceded Prosimo's absorption into Palo Alto Networks around February 2025; the exact date, price, and current product map have not been disclosed
  • Control remains distributed between enterprises, orchestration software, cloud providers, and Palo Alto Networks; the portability of topology, credentials, policies, and route authority is the litmus test for customers

The brand disappeared, but the problem remained

By 2026, it is no longer accurate to describe Prosimo as an independent, active supplier. Public professional histories show its founders and several employees joining Palo Alto Networks around February 2025. Prosimo's corporate page appears marked as an acquired company, and former CTO Nehal Bhau later wrote that the technology had been integrated into Palo Alto Networks products. The evidence shows a change of control and the continuity of the technological value, but does not clarify the exact signing or closing date, the legal form, or the transaction price.

This precision must appear upfront because it changes the tense of every statement about the products. 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 current, separately sold products until Palo Alto Networks publishes an updated product and support map. A historical architecture can survive an acquisition as embedded code, shared service, module, or internal engineering asset; these forms are not equivalent.

The brand disappeared, but the underlying problem remained. Enterprises continue to spread workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation facilities, 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. An organisation may own all the accounts and yet lack a single view of how a request traverses those environments. Prosimo's significance lies in its attempt to assemble and control that operational view.

Hence the acquisition is the narrative's axis, not merely an epilogue. Prosimo built a multicloud control layer capable of discovering assets, interpreting application context, and steering traffic through security services. Palo Alto Networks first appeared as a technical partner whose VM‑Series firewalls could be inserted into those paths. Later, it became the technology's owner. The boundary between route orchestration and deep inspection thus moved inside a single cybersecurity platform.

Multicloud routing is a contest over context

A route table can indicate whether a prefix is reachable via a given next hop. On its own, however, it does not explain which application the user intended to reach, whether the requestor is trusted, whether an inspection service should see the traffic, whether a private endpoint exists, whether one cloud path costs more than another, or whether the transaction is failing after the packet arrives. Multicloud operations turn these questions into a shared control problem.

Prosimo's thesis was that routing decisions should consider more than Layer 3 reachability. Its software tried to combine cloud inventory, network state, application identity, user identity, risk, performance, and transaction telemetry. This broader context allowed expressing policies such as connecting a specific application, separating a segment, choosing an entry point, or steering selected traffic through a firewall. The value was not in inventing a new fibre route but in deciding how existing paths and services should be combined.

This distinction explains the use of the phrase “application experience infrastructure”. The term placed the application request above the individual network component. A VPC, VNet, subnet, transit hub, or private connection became an element of an end‑to‑end path, not management’s final entity. The approach also pushed the product into several markets simultaneously: cloud networking, application delivery, zero‑trust access, network verification, cost optimisation, and security service insertion.

The breadth created opportunity and ambiguity. A product that reaches multiple teams can solve coordination failures that none controls alone. It can also be hard to evaluate because networking, security, cloud, application, and finance teams use different definitions of success. Prosimo needed to prove that a single cross‑cloud model improved operations without becoming yet another privileged layer whose errors affected every environment.

What Prosimo was – and what remains

Prosimo was a private cloud‑networking software company, founded in 2019 and headquartered in the San Francisco Bay Area. Ramesh Prabagaran served as co‑founder and CEO, while Nehal Bhau was co‑founder and CTO during the independent period. Public histories also identify Linus Aranha and Pradeep Aragonda in founding or engineering‑leadership roles, although their exact titles should remain tied to dated biographies.

Its main platform was the Application eXperience Infrastructure, abbreviated AXI. It used a central software layer for intent, topology, analytics, and orchestration, coupled with distributed AXI Edges in cloud regions, colocation environments, or adjacent on‑premises infrastructure. Later the company organised the offering as Full‑Stack Cloud Transit, with Network Transit and App Transit serving different connectivity classes. AIR analysed telemetry and produced operational insights; in 2024, Nebula added a conversational interface.

Prosimo was not a cloud operator. It did not own a global fibre backbone connecting every region. Paths could traverse provider backbones, the public internet, dedicated circuits, colocation links, and enterprise networks. Nor was it a firewall supplier in the same sense as Palo Alto Networks. In the 2024 integration, its role was to discover, segment, and steer; the VM‑Series provided the deep security inspection.

After the acquisition, the safest description is “technology lineage”. The subsequent integration statement highlights multicloud asset discovery and faster deployment of software firewalls for ingress, egress, and east‑west inspection. That confirms that important Prosimo components survived. It does not confirm that the whole historical AXI catalogue, commercial packaging, or customer‑support model continued unchanged.

The problem that came after SD‑WAN

The founding team had experience in large‑scale networking, application delivery, and cloud infrastructure. Prosimo also emerged from the broader Viptela‑linked ecosystem of founders and engineers, which helped establish software‑defined wide‑area networking as an enterprise category. The next problem was different. SD‑WAN could simplify how branch offices accessed networks and applications, but it did not create a single operating model inside and across multiple public clouds.

A multicloud application might 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 at selected boundaries. Each dependency may appear as a distinct native component. The networking team may see prefixes and transit hubs; the cloud team, accounts and resource entities; the application owner, domains and transactions; and the security team, zones and inspection policies.

Prosimo started from the request, not the branch. The relevant question was how a user or workload should reach an application with acceptable levels of security, performance, availability, and cost. This formulation shifted the routing entity: from merely a destination prefix to a transaction with identity and application context. It also required the platform to collect and maintain far more information than a conventional router.

The timing was favourable. AWS, Azure, and Google Cloud were expanding their native transit and private‑connectivity services. Enterprises could build sophisticated networks inside each provider, but the APIs, entities, and policy models remained provider‑specific. Prosimo's opportunity was to coordinate those services, not force every customer to replace them with a separate proprietary backbone.

From 2019 founding to public launch in 2021

Prosimo was founded in 2019 but only announced its public launch on 6 April 2021. General Catalyst led a US$25 million Series A at that time. The investor described the opportunity as delivering application experience across clouds, aligning with the founders’ effort to define a category beyond conventional branch connectivity.

The launch placed the company in a crowded and still‑undefined market. Cloud providers made it easy to consume their own networking services. SD‑WAN and SASE suppliers extended policies to cloud environments. Application‑delivery companies could optimise requests, while network‑security companies could inspect them. Prosimo's proposition depended on bringing these functions together in a cloud‑oriented architecture without claiming it would replace every surrounding system.

The funding gave room to build integrations, software edges, analytics, a commercial organisation, and partner relationships. It did not prove product‑market fit, revenue scale, or lasting differentiation. The evidence provided contains no audited revenue, annual recurring revenue, customer count, or valuation. The funding history shows investors’ commitment to a thesis, not a complete picture of operational performance.

In 2022, Prosimo completed a US$30 million Series B, described as an oversubscribed round. The two clearly identified rounds produce a verified total of at least US$55 million. Some databases may show a larger figure by duplicating announcements or related entries; those totals should not be used without reconciling the underlying events.

AXI put policy above clouds and execution close to workloads

The AXI architecture split the work between a central control‑and‑analytics layer and software‑defined distributed edges. The central layer maintained application and network intent, discovered assets, assembled topology, integrated identity, analysed telemetry, and orchestrated changes. AXI Edges were deployed near workloads or users, enforcing policies without forcing every path through a distant physical hub.

The separation resembled that of other software‑defined systems, but the entities were cloud‑specific and carried application context. The controller needed access to cloud accounts and APIs, while the edge required connectivity with native transit services, workload networks, private endpoints, or external paths. The platform’s authority came from combining those two views: global intent above clouds, and local execution close to relevant traffic.

The architecture also created a practical deployment boundary. Each edge consumed cloud resources, required high‑availability design, and needed updating, monitoring, and securing. The control layer needed credentials with enough privilege to discover assets and alter network state. The company gained a common workflow but added a new management system whose availability and correctness mattered for production connectivity.

Prosimo sometimes used the language of autonomous cloud networking. The evidence supports automation, recommendations, and API‑driven orchestration. It does not support a network capable of operating independently of human policies, provider services, or the underlying transport. Operators still defined intent, approved access, resolved exceptions, and were accountable for the outcome.

The AXI Edge was a placement decision, not a generic appliance

An AXI Edge could be deployed in a cloud VPC or VNet, in a colocation environment, or on adjacent infrastructure. The AWS technical guide showed an edge VPC connected to workload VPCs via 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, not at a distant corporate perimeter.

The 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 what telemetry the platform could collect. A poorly placed edge could create hairpins and extra cost; a well‑placed one could shorten the path or keep traffic close to the workload.

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

The edge was therefore part of a larger operating system. Its value depended on asset discovery, topology, policy, and analytics remaining consistent with the surrounding cloud environment. Treating it as a standalone virtual appliance would miss the architecture Prosimo tried to sell.

The underlay always belonged to another organisation

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

This boundary matters when evaluating performance claims. A controller can choose a path observed as better or bring the user’s entry closer. It cannot guarantee that a carrier will not fail, that a cloud region will stay 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 full authority.

The absence of a proprietary backbone was not only a weakness. It allowed Prosimo to use infrastructure that enterprises had already contracted and to benefit from provider investments. The company could reach regions without building fibre and coordinate native systems such as AWS Cloud WAN. The trade‑off was dependence on API stability, service limits, commercial terms, and provider‑specific semantics.

The platform’s claim, therefore, was about operational control, not physical ownership. It tried to make heterogeneous underlays work as a managed system while preserving their native strengths. Whether this abstraction reduced lock‑in or merely shifted it depended on the portability of policy, topology, and edge deployment.

Network Transit handled reachability between network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites, and segments. It coordinated native transit and cloud‑routing components so that teams could create connectivity through a common flow, rather than configuring each provider separately. The product met the conventional networking requirement: a source prefix or segment must reach a destination over an allowed path.

That did not mean cloud differences disappeared. AWS, Azure, and Google Cloud expose different entities, limits, and route behaviours. Overlapping address spaces, asymmetric paths, private endpoints, and provider‑specific service limits still required engineering. Prosimo could normalise common operations and show relationships, but the underlying systems kept their constraints.

Network Transit also carried segmentation. Route domains and policies could separate environments or limit reachability. The controller needed to understand where a segment existed across clouds and how native components enforced that boundary. A policy expressed once could still generate multiple provider‑specific changes.

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

App Transit turned the application into a routing entity

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 would reach 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 stably represented 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 the user can be more durable than a rule written only around addresses and ports.

The model required accurate discovery. The controller needed to know which domains and endpoints belonged to an application, which dependencies were necessary, and which identity‑provider assertions were trusted. An outdated mapping could send the request along the wrong path or apply the wrong security rule. The application abstraction did not eliminate the need to understand network state; it added another semantic layer above it.

The combination of Network Transit and App Transit recognised that enterprises contain both worlds. Legacy systems, private subnets, and IP‑based controls remain, while newer applications depend 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 widened the routing decision and the trust boundary

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

Identity increased precision but introduced another dependency. The route or application policy now depended on the identity provider, its assertions, session state, and group data. A network path could fail because authentication was unavailable or an attribute had changed, even though routers and edges were healthy. Investigation needed 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 results. This dataset improved diagnosis and optimisation but widened the consequences of unauthorised access. Least privilege, retention, audit, and separation of duties were architectural requirements, not after‑the‑fact administrative niceties.

Prosimo's approach illustrates a broader infrastructure shift. Routing and access policies increasingly depend on identity and application semantics. The more context a platform sees, the more useful its decisions can be – and the more carefully its authority must be governed.

Asset discovery created the graph on which all subsequent decisions depended

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

Discovery was strategically important because cloud environments change outside central networking flows. Application teams can create accounts, networks, endpoints, and managed services through their own automation. A manually maintained diagram goes stale. An API‑driven inventory can provide a more current graph, though its completeness still depends on covered accounts, permissions, interpretation logic, and provider APIs.

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

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

AIR turned edge telemetry into operational recommendations

Application‑driven Intelligent Results, or AIR, analysed the telemetry collected by AXI Edges. The AWS guide 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, rather than displaying isolated device counters.

This correlation attacked a known operational 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 investigation scope faster than separate consoles, and can also underpin 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 passed through it. External application dependencies and internal provider conditions could remain invisible. A recommendation could guide analysis without, by itself, proving root cause.

Telemetry also had governance value. Historical observations could help the enterprise explain why a route or policy changed. They could also expose sensitive application usage and user behaviour. The public material does not provide a full description of data retention or governance after the acquisition, so these points remain part of customer due diligence.

AWS provided the best‑documented public implementation

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

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

The Marketplace flow simplified the first deployment step by packaging the AXI Edge through an approved channel. It did not eliminate the subsequent work of account permissions, route design, high availability, capacity, and operations. Day‑zero automation can reduce installation friction without solving the long‑term control problem.

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

Azure and Google Cloud completed the multicloud claim

Prosimo also supported Microsoft Azure and Google Cloud environments. Its materials described orchestration around Azure Virtual WAN and Google Cloud networking and private‑service components. The goal was to present a single operating model while keeping each provider’s native network.

The existence of support does not prove identical capabilities across providers. Cloud APIs mature at different rates, and comparable product names can hide distinct semantics. A route, segment, private endpoint, or service insertion may require provider‑specific treatment. The evidence provided does not reconstruct a feature‑by‑feature equivalence matrix for every region and version.

The multicloud abstraction is therefore best understood as a translation system. It can normalise intent and common workflows, but it must preserve the details that affect security, cost, and failure. A platform becomes dangerous when the interface appears uniform while the implementation differences are hidden from operators.

The same holds after the acquisition. Palo Alto Networks can use the common graph to place security across clouds, but the providers still control the native entities that implement the path. Owning the orchestration layer does not mean owning the cloud underlay.

The product broadened from connection to lifecycle

By 2023, Prosimo was describing flows to design, build, investigate, and manage multicloud networks. The product had moved beyond establishing a tunnel or gateway. Asset discovery supported design; orchestration created connectivity; maps and telemetry aided investigation; policy and historical state underpinned ongoing management.

This lifecycle framing widened the potential buyer group. A network engineer could use topology and path analysis; a cloud‑platform team, integrate accounts and services; a security team, review segmentation and inspection; a migration team, plan changes; and FinOps, examine route and egress implications. The value grew when several groups used the same evidence.

Shared evidence can also create governance conflict. A central platform may reveal that a cloud team’s native configuration diverges from enterprise policy. The organisation must decide which system holds authority and who can approve the correction. The software alone does not resolve that institutional question.

The lifecycle narrative also raised the switching cost. When a controller holds the asset graph, policies, telemetry, edge placement, and automation integrations, replacing it requires more than moving a circuit. The customer must export or rebuild the operational model. Prosimo sold less cloud fragmentation, while simultaneously creating the possibility of controller dependence.

Segmentation went from network reachability to application policy

Prosimo presented Layers 3‑7 segmentation. 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 refined the rule.

The layered model could shrink the gap between a network zone and an application policy. An enterprise service could be allowed even when broad subnet‑to‑subnet reachability remained blocked. Conversely, a reachable network path could still be denied because identity or application context failed.

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

A segment is effective only if every relevant path is represented. An unknown route, a native cloud exception, or a failed service insertion can bypass the intended control. Validation requires comparing declared policy with provider state and observed traffic, not relying only on the controller’s configuration screen.

Service insertion linked route control to firewall economics

Cloud security design must decide where inspection will occur. Centralised firewalls can simplify policy and reduce appliance count, but can create backhaul, concentration, and scale pressure. Distributed firewalls sit close to workloads and reduce some path distortions, but multiply deployment, licensing, updating, and policy operations.

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

The architecture made route orchestration commercially valuable for a security vendor. A software firewall does not protect traffic that never reaches it. Discovery, placement, and route updates reduce the operational friction between buying security capacity and inserting it into an active path. This is a plausible strategic reason for Palo Alto Networks to absorb Prosimo’s technology.

It also widens the controller’s blast radius. An incorrect policy can bypass inspection, create a loop, produce asymmetric routing, or take down an application. Health checks, staged changes, simulation, audit, and rollback are necessary because a service‑insertion failure is simultaneously a network and a security event.

The 2024 partnership should not be reinterpreted as an acquisition

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

Still, the partnership created a bridge. Prosimo could demonstrate how its route‑and‑policy system eased VM‑Series deployment across clouds. Palo Alto Networks could evaluate the technology inside a real integration before the later corporate transition. The public evidence does not describe the acquisition process, so any claim that the partnership was designed as a formal pre‑acquisition step would be speculative.

By early 2025, the founders’ and employees’ histories had changed. The company page later came to indicate acquisition. In late 2025, Bhau stated that the technology was fully integrated into Palo Alto Networks products. Together, these records support the conclusion of an acquisition while leaving its legal mechanics unanswered.

This sequence matters for editorial accuracy and for customers. A partnership means two suppliers, two support structures, and a defined integration boundary. An acquisition can transfer roadmaps, data, contracts, and authority to a single company. The transition changes more than the brand, 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 multicloud networking. The assistant was designed to answer, in natural language, questions about overlay networks, costs, route health, security‑policy violations, and other conditions represented in the platform’s graph and telemetry.

The useful asset was not the language interface itself, but the structured cross‑cloud context underneath it. A general model cannot diagnose a private route or a segment it does not see. Nebula could draw on the asset inventory, topology, policies, and observations that Prosimo already collected. That made the earlier investment in a common graph relevant for AIOps.

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

Prosimo reported potential gains such as a 60‑80% reduction in mean time to resolution and over 60% lower cloud‑network costs. These numbers were company claims in a product announcement. No independent methodology or customer baseline in the provided evidence proves general applicability. They can be cited as a benefit proposed by Prosimo, not as measured market fact.

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

The same 2024 announcement positioned Prosimo’s architecture as useful for AI workloads. Distributed AI systems may need private access to data, cross‑cloud and data‑centre connections, compliance controls, and routing that reflects application behaviour. Those requirements fit the already existing model of assets, policies, and paths.

The label did not change the underlay. Prosimo remained dependent 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.

Positioning for AI was strategically coherent 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 independent operation. The evidence does not establish separate AI‑product revenue, identified production deployments, or audited workload results.

The lasting point is that multicloud telemetry can become input for machine‑assisted operations. The current product question is whether Palo Alto Networks preserved that context and how it exposes the capability. The public evidence available at the research cut‑off does not provide a complete answer.

The business model depended on third‑party infrastructure

Prosimo’s independent business followed a subscription‑software and services model, not a carrier model. Customers deployed AXI Edges in their own environments and connected cloud accounts to the control layer. Revenue likely came from licences or subscriptions, support, professional services, and channels, although exact pricing and contract metrics do not appear in the provided evidence.

The model could grow without owning fibre. A software platform could coordinate many regions and customer environments. However, gross economics cannot be inferred from this architecture. Engineering support for vendor APIs, edge lifecycle, security integrations, and enterprise deployments can be expensive, while the cloud resources consumed by edges could be paid for by the customer, not the vendor.

Prosimo used cloud marketplaces, integration partners, channel organisations, and named customer references to reach enterprises. These relationships are not equivalent. A marketplace listing proves a procurement and deployment path. A technical integration shows that two systems can be combined under defined conditions. A customer testimonial offers a reference. None of these, in isolation, establishes paying customer numbers or recurring revenue.

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

Partners, customers, and investors held different stakes

Amazon Web Services was simultaneously the underlay provider and commercial integration partner. Azure and Google Cloud were supported environments. Identity providers supplied authentication context. Firewall vendors provided 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 does not reveal the full 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 its investor involvement. Investors linked to WRVI or Celesta appeared in company materials, and later Prosimo communications cited other prominent entities, including a name associated with BlackRock whose exact vehicle was not clarified by the research. These records support a well‑connected financial foundation, not a complete capitalisation picture.

Palo Alto Networks held the most important relationship. It moved from security partner in 2024 to acquirer in early 2025. The sequence shows how an ecosystem dependency can become a control relationship when one entity buys the software layer that coordinates the path to its own product.

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

The verified funding history 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. The evidence provided does not include an audited cap table, valuation, debt structure, or subsequent round.

The amount paid in the acquisition was not disclosed or independently verified. Without a price, it is not responsible to categorise the outcome as a strategic premium, modest technology purchase, acqui‑hire, or distress sale. The continuity of integration proves technological value; it does not reveal the return obtained by investors or founders.

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

The absence of a formal acquisition announcement is itself relevant. Customers, employees, and researchers ordinarily use such announcements to determine chronology, support, and strategic logic. In this case, the status must be reconstructed from professional histories, the company‑page label, and a later founder statement. It is sufficient to correct the company’s condition, but limited public evidence to invent transaction details.

Competition came from platforms, clouds, and internal engineering

Prosimo competed with specialist multicloud‑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 an in‑house model in which the enterprise uses infrastructure‑as‑code, provider transit services, route tables, and firewalls directly. These alternatives solved different pieces of the same problem.

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

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

The acquisition changes the competitive picture. Prosimo no longer needs to win as a standalone company, but its technology must justify itself within Palo Alto Networks. The relevant comparison becomes whether integrated discovery and orchestration improve the deployment of Palo Alto security products and whether customers accept the resulting platform dependency.

Native cloud services were both foundation and substitute

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

This relationship created a moving boundary. As a provider added global routing, segmentation, private service access, or central policy, some third‑party functions became easier to reproduce natively. At the same time, each new native service added another entity that a multicloud controller could discover and coordinate. Cloud progress could reduce one part of Prosimo’s value and enlarge the need for cross‑provider translation.

The deciding factor was as much organisational as technical. A company concentrated on one cloud with strong in‑house engineering might prefer native tools. A multicloud organisation with fragmented teams might value a single control plane. A regulated institution might prefer an independent evidence layer but worry about privileged credentials and data concentration.

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

Failure could occur in the controller, edge, API, identity, or underlay

Prosimo’s distributed architecture reduced reliance on a single traffic hub but created multiple linked 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 stop. The underlay could lose capacity or follow 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 the real cloud state. Traffic may follow an asymmetric path or bypass inspection. A reliable system needs reconciliation, idempotent operations, gradual change, explicit error state, and rollback that considers each provider’s behaviour.

The public evidence describes availability and optimisation at a high level but does not include an independent fault‑injection study, full incident history, or universal service‑level outcomes. Resilience claims must remain tied to the documented architecture or to evidence from named customers.

The 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 remain unclear.

Cloud credentials placed the controller in 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 without owning the workloads.

Credential compromise could expose topology or allow broad changes. A software defect or operator error could propagate policies across multiple clouds. The risk grew with the platform’s utility: the more accounts and services it governed, the larger the potential blast radius.

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

The telemetry graph was equally sensitive. It could reveal application names, network structure, policies, user relationships, route health, and cost patterns. Post‑acquisition governance should clarify where these data are stored, which Palo Alto Networks products can use them, and how old customer permissions were migrated. The public evidence at the research cut‑off does not answer these questions.

The acquisition moved a formerly neutral control layer into a security platform

The independent position allowed Prosimo to present itself as a common layer across clouds and security services. When Palo Alto Networks became the owner, the incentives changed. The acquired technology could ease deployment of the VM‑Series and other Palo Alto products. That may offer better integration while raising questions about support for third‑party inspection services.

Ownership does not prove that neutrality disappeared. The evidence does not contain a current partner matrix or the contemporary product architecture. However, the customer question shifts. It is necessary to know whether the routing controller remains open to multiple security vendors, whether policies and telemetry can be exported, and whether 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 have become part of a security‑deployment system. It does not prove that App Transit, user access, cost optimisation, or the full historical cloud‑networking flow survived as separate capabilities.

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

The current product map is the main information gap

Public records confirm the acquisition and integration, but do not identify a complete mapping of AXI, Network Transit, App Transit, AIR, and Nebula to current Palo Alto Networks products or SKUs. They also do not publish legacy support timelines, migration procedures, or a feature‑by‑feature continuity table.

This gap prevents a current product assessment. Historical descriptions explain what Prosimo built and why it mattered. They do not tell which capabilities are available, licensed, or supported today. Contemporary deployment recommendations must be based on current Palo Alto Networks documentation, not on archived Prosimo announcements.

The missing map also limits strategic analysis. Full absorption of the graph and orchestration layer would be different from selectively using asset discovery and firewall placement. One outcome would create a broad multicloud control service; the other would use Prosimo mainly to accelerate security deployment. The co‑founder’s statement supports technological continuity but leaves this architectural boundary unanswered.

A future product document, migration guide, or customer case study could resolve much of the uncertainty. Until then, the accurate formulation is that, according to a co‑founder, Prosimo’s technology has been integrated into Palo Alto Networks products, while the scope and packaging have not been verified.

Who controls multicloud 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 policies, choose paths, and alter native route state. Providers control their APIs, transit services, private endpoints, backbone, and many failure domains. Carriers and colocation companies control other parts of the transport. Security services control whether inspected traffic is allowed.

Prosimo aimed for the most strategically useful middle position. It did not own the underlay, but 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 power over routing, even when the fibre belongs to another organisation.

After the acquisition, Palo Alto Networks owns the remnant Prosimo technology and determines how it is integrated, packaged, and developed. The providers remain sovereign within their own environments, and the enterprise can revoke credentials or choose another architecture. The exit may, however, be expensive if topology, policies, and operational flows have become dependent on the controller.

The answer is therefore distributed by layer, not absolute: the enterprise authorises; the controller coordinates; cloud and carrier underlays transport; the security platform enforces. Prosimo’s story matters because it shows that ownership of the coordination layer can change without a cloud account or physical route changing hands.

Primary

Why Prosimo still matters after the acquisition

Prosimo captured a real infrastructure shift. The unit of network management is moving from the device and the prefix to the application, identity, service dependency, and policy graph. Native APIs make network state programmable, while distributed edges make the enforcement point movable. A controller that sees multiple clouds can coordinate actions that no single console can complete alone.

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

The acquisition by Palo Alto Networks makes the control question more visible. Networking and security converge around service insertion, workload discovery, and policy. A security vendor that knows the topology and alters routes is not limited to inspecting the traffic it receives; it can help determine which traffic reaches inspection and where it happens.

Prosimo should be remembered neither as a failed standalone brand nor as proof that one platform solved multicloud. Its lasting contribution was defining the cross‑cloud graph as infrastructure. The remaining question is whether that graph, now inside a larger security company, remains transparent, portable, and governable enough to deserve customer trust.