Summary

  • Prosimo was founded in 2019 and raised at least USD 55 million in Series A (2021) and Series B (2022). Audited revenue, valuation and acquisition price have not been disclosed.
  • AXI combined a central intent, topology and analytics layer with distributed edges, performing cloud asset discovery, application connectivity, security insertion and telemetry collection without owning a physical backbone.
  • After announcing a VM-Series integration in June 2024, Prosimo moved under the Palo Alto Networks umbrella by around February 2025; the exact acquisition date, price and mapping to current products remain unconfirmed.
  • Control is distributed across the enterprise, orchestration software, cloud providers and Palo Alto Networks. The portability of topology, credentials, policies and routing authority is a critical consideration for customers.

Even after losing its independence, the problems remain

Referring to Prosimo in 2026 as an active independent vendor is no longer accurate. Public career records show that the founders and several employees moved to Palo Alto Networks around February 2025. Prosimo’s company page displays as acquired, and the former CTO, Nehal Bhau, later stated that the technology had been integrated into Palo Alto Networks products. These pieces of evidence confirm a transfer of control and continued technical value, but they do not reveal the contract date, closing date, legal form or price.

This correction must appear at the outset because the tense of every product description changes. AXI, Network Transit, App Transit, Application-driven Intelligent Results and Nebula are recorded as capabilities of independently operated Prosimo. Unless Palo Alto Networks publishes a current product–SKU mapping, they should not be written about as individually available, current products. The underlying architecture may survive post‑acquisition as embedded code, shared services, modules or internal engineering assets, but it is not in the same state.

The disappearance of a brand does not mean the underlying problems have disappeared. Enterprises still distribute workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation sites, SaaS and remote users. Each environment has its own routes, gateways, private endpoints, identity controls, security services, limits and billing rules. Even when an enterprise owns the accounts, it may not be able to see, on a single screen, how a request moves between environments. Prosimo’s significance lies in its attempt to understand and control that entire picture from a single operational layer.

The acquisition is therefore not an epilogue but the axis that runs through the whole article. Prosimo built a cross‑cloud control layer capable of discovering assets, interpreting application context and steering traffic to security services. Palo Alto Networks first appeared as a technology partner that could insert its VM‑Series firewalls into those paths. It then became the owner of the technology. The boundary that once separated routing orchestration from deep inspection moved inside a single cybersecurity platform.

Multi‑cloud routing is a competition over context

A routing table can answer whether a prefix is reachable via a different next‑hop. It cannot explain, on its own, which application the user was trying to reach, whether the requester should be trusted, whether traffic needs to pass through an inspection service, whether a private endpoint is available, which cloud path is expensive, or whether a transaction is failing after the packet arrives. Multi‑cloud operations bundle all of these into a single control problem.

Prosimo’s proposition was that routing authority should not be determined by Layer‑3 reachability alone. Its software aimed to combine cloud asset inventory, network state, application identity, user identity, risk, performance and transaction telemetry. This allowed operators to express policies such as connecting a specific application, isolating segments, choosing an ingress point, or sending selected traffic through a firewall. The value lay not in inventing new fibre paths but in deciding how to combine existing paths and services.

This difference explains why the company used the term “application experience infrastructure.” The centre of management was the application request, not individual network components. VPCs, VNets, subnets, transit hubs and private links became components of an end‑to‑end path rather than the final unit of management. This thinking positioned the product simultaneously across several markets: cloud networking, application delivery, zero‑trust access, network assurance, cost optimisation and security service insertion.

The broad scope created both opportunity and ambiguity. A product that spans multiple teams can resolve the co‑ordination gaps that no single team owns. It is also hard to evaluate, because networking, security, cloud, application and finance teams define success differently. Prosimo needed to demonstrate that a cross‑cloud model could improve operations while not becoming a new privileged layer whose mistakes would propagate into every environment.

What Prosimo was, and what remains

Prosimo was a privately held cloud networking software company founded in 2019 and based in the San Francisco Bay Area. During its independent period, Ramesh Prabagaran served as co‑founder and CEO, and Nehal Bhau as co‑founder and CTO. Public career records also list Linus Aranha and Pradeep Aragonda in founding or senior engineering roles, though exact titles should be aligned with dated biographical material.

The main platform was Application eXperience Infrastructure, known as AXI. AXI combined a central software layer handling intent, topology, analytics and orchestration with distributed AXI Edges placed in cloud regions, colocation environments or adjacent on‑premises infrastructure. Later, the product was organised as Full‑Stack Cloud Transit, with Network Transit and App Transit handling different connection types. AIR analysed telemetry to provide operational insights, and Nebula added a conversational interface in 2024.

Prosimo was not a cloud carrier. It did not own a global fibre backbone connecting all regions. Paths could run over cloud‑provider backbones, the public internet, dedicated links, colocation interconnects and enterprise networks. Nor was it a firewall vendor in the same sense as Palo Alto Networks. In the 2024 integration, Prosimo’s role was discovery, segmentation and steering, while the VM‑Series performed deep security inspection.

The safest post‑acquisition description is “technical lineage.” Later integration statements emphasised faster multicloud asset discovery and software‑firewall deployment for ingress, egress and east‑west inspection. That is evidence that important Prosimo components survive. It is not evidence that the historical AXI product family, commercial packaging and customer‑support models continue unchanged.

The problem that appeared after SD‑WAN

The founding team had experience in large‑scale networking, application delivery and cloud infrastructure. Prosimo also emerged from the wider network of founders and engineers connected to Viptela, which played a significant role in establishing SD‑WAN as a distinct enterprise market. But the next problem was different. SD‑WAN could simplify branch‑office connectivity to the network and to applications, but it did not create a single operating model across and inside multiple public clouds.

A multi‑cloud application may 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 chosen perimeters. Each dependency is expressed through a different set of native constructs. The networking team sees prefixes and transit hubs; the cloud team sees accounts and resource entities; the application owner sees domains and transactions; the security team sees zones and inspection policies.

Prosimo started thinking from the request rather than from the branch. The question to answer was how a user or workload could reach the application with adequate security, performance, availability and cost conditions. This framework broadened the routing entity from a mere destination prefix to a transaction carrying an identity and application context. In return, it required far more information to be collected and maintained than a traditional router would need.

The market environment was also favourable. AWS, Azure and Google Cloud were expanding their native transit and private connectivity services. Enterprises could build sophisticated networks inside each cloud, but the APIs, entities and policy models differed between providers. Prosimo’s opportunity was not to replace those services with its own backbone, but to co‑ordinate them with each other.

From founding in 2019 to public launch in 2021

Prosimo was founded in 2019 but announced its public launch on 6 April 2021. The USD 25 million Series A at launch was led by General Catalyst. That investor emphasised the opportunity of delivering application experiences across multiple clouds, consistent with the founders’ ambition to define a space beyond conventional branch connectivity.

At the time of launch, the market was crowded and its boundaries were fluid. Cloud providers were making their own networking services easier to use. SD‑WAN and SASE vendors were extending policies into the cloud, application‑delivery vendors could optimise requests, and network‑security vendors could inspect them. Prosimo’s credibility rested not on claiming to replace everything around it, but on whether it could tie these functions together in a single cloud‑oriented architecture.

The funding gave it room to build integrations, software edges, analytics, a sales organisation and partner relationships. It did not, however, prove product–market fit, revenue scale or sustained differentiation. The available materials contain no audited revenue, annual recurring revenue, customer count or valuation. Funding records show that investors placed capital behind a hypothesis, not a complete picture of performance.

In 2022, Prosimo completed a Series B of USD 30 million, described as oversubscribed. The two clearly confirmed rounds sum to at least USD 55 million. Some databases may show larger figures by double‑counting announcements or related entries, so they should not be used without verifying the underlying transactions.

AXI placed policy above the clouds and execution near the workloads

The AXI architecture split roles 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 placed close to workloads or users so that policy could be applied without back‑hauling all paths to a remote physical hub.

This separation resembles other software‑defined systems, but its target was cloud‑specific and application‑aware. The controller needed access to cloud accounts and APIs; the edge needed connectivity to native transit services, workload networks, private endpoints and external paths. Combining holistic intent above the clouds with local execution close to the relevant traffic created a foundational authority.

It also created implementation boundaries. Each edge consumed cloud resources, required a high‑availability design, and needed updating, monitoring and protection. The control layer required credentials with enough privilege to discover assets and change network state. Enterprises gained a common workflow, but they also added a new management system whose availability and correctness could affect production reachability.

Prosimo sometimes used the phrase “autonomous cloud networking.” The evidence supports automation, recommendations and API‑driven orchestration. It does not support a network that operates independently of human policy, cloud‑provider services and underlying transport paths. Operators still set intent, authorised access, handled exceptions and remained accountable for outcomes.

AXI Edge was not a generic appliance but a deployment decision

AXI Edges could be placed in cloud VPCs/VNets, colocation environments or adjacent infrastructure. AWS technical documentation showed configurations where an Edge VPC connected to workload VPCs through a Transit Gateway, chained firewalls when needed, and provided access from remote users or on‑premises sites. Prosimo’s enforcement point sat inside the cloud topology, not at a distant enterprise perimeter.

Placement determined more than latency: it decided where traffic entered the policy domain, which cloud backbone or internet path it used, where encryption and inspection occurred, and what telemetry could be collected. Poor placement could create tromboning and cost; good placement could shorten paths and keep traffic near the workloads.

Distributed placement also increased the number of failure domains to manage. Capacity, software version, cloud‑zone design, route convergence and access rights could vary by region. High availability was not simply a matter of running two instances. The controller, cloud route tables, security services and return paths also needed to share the same failover state.

Edges were therefore part of a larger operational system. Their value depended on asset discovery, topology, policies and analytics aligning with the surrounding cloud environment. Treating them as standalone virtual appliances misses the architecture Prosimo was selling.

The underlay was always someone else’s property

Prosimo co‑ordinated transport but did not own the physical paths. Application paths could use cloud backbones such as AWS, the public internet, Direct Connect or ExpressRoute, colocation services, carrier circuits and enterprise networks. The controller could select and chain paths from the available options, but it could not eliminate the latency, packet loss, failure domains or billing rules that each provider imposes.

This boundary matters when evaluating performance claims. A controller can pick an observably better path and move the ingress point closer to the user. It cannot guarantee to prevent a carrier outage, a cloud‑region failure or a delay in an external dependency. Application experience also includes DNS, server processing, storage, browser behaviour and third‑party services that lie outside the full control of a network controller.

Not owning a backbone was not simply a weakness. It allowed Prosimo to use infrastructure that enterprises had already bought and to benefit from cloud‑provider investment. It could reach regions without laying fibre and could co‑ordinate with native systems such as AWS Cloud WAN. In exchange, it depended on API stability, service limits, commercial terms and provider‑specific semantics.

The claim, therefore, was about operational control rather than physical ownership. Prosimo tried to make heterogeneous underlays behave as a single managed system while preserving their native advantages. Whether that abstraction reduced lock‑in or merely shifted it to another place depended on the portability of policies, topology and edge placement.

Network Transit handled reachability between network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites and segments. It co‑ordinated cloud‑native transit and route configurations so that connections could be created through a common workflow rather than by configuring each provider individually. It helped meet the basic requirement of traditional networking: that a source prefix or segment should reach a destination over an allowed path.

It was not a claim that differences between clouds had vanished. AWS, Azure and Google Cloud have different entities, limits and routing behaviour. Overlapping address spaces, asymmetric paths, private endpoints and provider‑specific service constraints still required design. Prosimo could normalise common operations and make relationships visible, but the native constraints of the underlying systems remained.

Network Transit also handled segmentation. Route domains and policies could isolate environments and limit reachability. The controller needed to understand where a segment existed across multiple clouds and how the native configuration implemented the boundary. A policy expressed once could expand into several, provider‑specific changes.

The benefit was handling intent on a single surface. The risk lay in the translation. If a common policy and the cloud configuration drifted apart, an enterprise could believe a segment was protected while the actual provider state was different. Reconciliation, auditing and explicit failure reporting were therefore as important as initial provisioning.

App Transit made the application the entity of routing

App Transit extended the model beyond subnets. When deciding how a user or workload should reach a service, it could use application domain, identity, request type, transaction health, risk and performance. This was where Prosimo tried most clearly to differentiate itself from conventional cloud routers.

An application view made sense because modern services are rarely represented cleanly by fixed addresses. Managed platforms, SaaS endpoints and distributed components change while the application identifier can retain meaning. A policy that references a service or a user can outlast rules based solely on addresses and ports.

This model required accurate discovery. The controller needed to know which domains and endpoints belonged to an application, which dependencies were required, and which identity‑provider claims it could trust. Stale mappings could send requests down the wrong path or apply the wrong security rules. The application abstraction did not remove the need to understand network state; it added a layer of meaning on top of it.

The combination of Network Transit and App Transit acknowledged that two worlds coexist in the enterprise. 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 both together rather than replacing one with the other.

Identity broadened routing decisions and trust boundaries

Application‑aware access required identity integration. The platform could use user or workload context to decide whether to allow a connection and how to establish it. This underlay a zero‑trust policy that says location alone is limited public evidence grounds for authority.

Identity increased precision while creating new dependencies. A route or application policy could depend on an identity provider, its claims, session state and group information. Even when routers and edges were healthy, an authentication outage or an attribute change could cause a network path to fail. Troubleshooting then had to cross the boundary between network operations 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. This data improved diagnostics and optimisation, but it also raised the impact of unauthorised access. Least privilege, retention periods, auditing and separation of duties were architectural requirements, not an afterthought.

Prosimo’s approach reflects a wider change. Routing and access policies increasingly depend on identity and application semantics. The more context a platform sees, the more useful its decisions can be. At the same time, that authority must be governed more strictly.

Asset discovery built the graph that all subsequent decisions rested on

A cross‑cloud controller cannot control what it cannot see. Prosimo developed cloud‑asset discovery and mapping to represent VPCs, VNets, subnets, applications, connections and security relationships. These views supported onboarding, design, troubleshooting and policy.

Discovery had strategic value because cloud assets change outside central network processes. Application teams can create accounts, networks, endpoints and managed services through their own automation. Hand‑drawn diagrams go stale. An API‑driven inventory can build a fresher graph, but its completeness depends on account scope, permissions, parsing logic and provider APIs.

The graph was more than documentation. It was the data structure on which routing, segmentation, service insertion and optimisation were computed. A missing asset or dependency could make every conclusion built on top of it wrong. Topology therefore needed provenance: when it was collected, which account supplied it, which regions were included, and whether any requests had failed.

This graph also explains the acquisition rationale. Palo Alto Networks can create security value if it knows where workloads and traffic paths are. A system that can discover cloud assets and change routes shortens the distance from buying a software firewall to placing it correctly. Bhau’s later integration statement specifically highlighted faster asset discovery and software‑firewall deployment.

AIR turned edge telemetry into operational recommendations

Application‑driven Intelligent Results (AIR) analysed the telemetry that AXI Edges collected. AWS documentation described visibility into round‑trip time, processing time, application response time, transaction type, risk and policy outcome. The platform could correlate observations of users, networks and applications rather than relying on isolated device counters.

This correlation addresses a common operational problem. A slow transaction could originate in the user path, the edge, the cloud backbone, a security service or the application itself. A cross‑layer view can narrow the investigation faster than separate consoles and can also support recommendations on routing, placement, risk and cost.

Recommendation quality depended on the scope of telemetry and the interpretation model. An edge could observe only traffic that passed through it. External application dependencies or internal cloud‑provider state might be invisible. Recommendations could be directionally useful without proving a root cause.

Telemetry also had governance value. Historical observations could help explain why routes and policies changed. At the same time, they could reveal sensitive application usage and user behaviour. Public materials do not fully describe retention periods or post‑acquisition data governance, leaving these as customer due‑diligence items.

AWS provided the clearest implementation evidence

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

The AWS Cloud WAN integration was particularly important. It offered a cloud‑native backbone and segmentation service that Prosimo could orchestrate rather than replace. This configuration illustrates the cooperative model: AWS owned the native networking and global infrastructure, while Prosimo provided cross‑cloud intent, application context, edge software and analytics.

The Marketplace workflow packaged AXI Edges through an approved channel and simplified initial deployment steps. However, subsequent account permissions, route design, high availability, capacity and operations remained. Day‑0‑plus automation can reduce onboarding friction without eliminating long‑term control challenges.

Company materials cited a named customer reference for Flexport, supporting the AWS Cloud WAN use case. This is evidence that an enterprise customer endorsed the architecture, not an independent audit of deployment scale, savings or availability. Customer comments should be treated as adoption examples rather than universal performance evidence.

Azure and Google Cloud completed the multi‑cloud claim

Prosimo also supported Microsoft Azure and Google Cloud environments. Product materials described orchestrating around Azure Virtual WAN, Google Cloud networking and private service configurations. The goal was to present a single operating model while leaving each provider’s native networking in place.

Supporting multiple clouds does not prove identical functionality across them. Cloud APIs mature at different rates, and similarly named products can carry different semantics. Routes, segments, private endpoints and service insertion could require provider‑specific handling. Available materials cannot reproduce a feature‑parity matrix covering all regions and releases.

The multi‑cloud abstraction is therefore best understood as a translation system. It can normalise common intent and workflows, but it cannot eliminate the details that affect security, cost and failure. If the screen is unified but implementation differences are hidden from the operator, the platform becomes dangerous.

The same applies after the acquisition. Palo Alto Networks may be able to place security across multiple clouds using a common graph, but the native entities that implement the paths are still controlled by the cloud providers. Owning the orchestration layer is not the same as owning the cloud underlay.

The product expanded from connectivity to lifecycle

By 2023, Prosimo was describing workflows for designing, building, troubleshooting and managing multi‑cloud networks. The product extended beyond establishing tunnels and gateways. Asset discovery informed design; orchestration created connectivity; maps and telemetry supported troubleshooting; policies and historical state supported ongoing management.

This lifecycle framework broadened the commercial buyer set. Network engineers could use topology and route analysis; cloud infrastructure teams could bring in accounts and services; security teams could verify segmentation and inspection; migration teams could plan changes; FinOps teams could examine path and egress implications. The more organisational groups used the same evidence, the higher the platform’s value became.

Shared evidence also created governance conflicts. A central platform could reveal that a cloud team’s native configuration differed from enterprise policy. Organisations had to decide which system was authoritative and who could authorise remediation. Software alone cannot resolve these institutional questions.

The lifecycle narrative also increased switching costs. When a controller held the asset graph, policies, telemetry, edge deployments and automation integrations, replacing it was more than a circuit migration. Customers would need to export or rebuild their operating model. While Prosimo sold reduced cloud fragmentation, it also created the potential for controller dependence.

Segmentation spanned network reachability to application policy

Prosimo claimed segmentation from Layer 3 to Layer 7. At the network layer, route domains and segments determined which subnets and sites could communicate. At higher layers, application identity, user context and transaction characteristics could refine the rules.

A layered model could close the gap between network zones and application policies. It might allow only a specific business service while blocking broad subnet‑to‑subnet reachability. Conversely, it could deny access even when a network path was reachable if the identity or application context was inappropriate.

This did not make Prosimo a full next‑generation firewall. The 2024 Palo Alto Networks integration divided responsibilities: Prosimo orchestrated routing, segmentation and service insertion; the VM‑Series performed deep inspection. The distinction matters because policy‑driven routing and security enforcement fail in different ways.

A segment is effective only when all relevant paths are represented. Unknown routes, cloud‑native exceptions or failed service insertions could bypass the intended controls. Assurance therefore requires comparing declared policies, provider state and observed traffic, not trusting the controller screen alone.

Service insertion linked route control to firewall economics

Cloud security design must decide where to place inspection. A central firewall simplifies policy and reduces instance count, but can create tromboning, concentration and scaling pressure. Distributed firewalls can be placed close to workloads, reducing path distortion, but increase deployment, licensing, updating and policy operations.

Prosimo supported both configurations through the VM‑Series integration. Policies could send selected traffic to a central inspection point or to firewalls distributed into application VPCs. Palo Alto Networks provided the inspection function, while the controller updated the surrounding routes.

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

It also widened the controller’s blast radius. A mis‑policy could bypass inspection, create loops, produce asymmetric routing or halt applications. A service‑insertion failure is as much a network outage as a security event, which demands health checks, staged changes, simulation, auditing and rollback.

The 2024 partnership must not be back‑dated to acquisition

Prosimo and Palo Alto Networks announced the VM‑Series integration on 12 June 2024. The announcement described a joint technical and commercial solution but did not say that Palo Alto Networks had acquired Prosimo. Treating that announcement as evidence of ownership conflates two separate events.

The partnership did, however, bridge the gap. It allowed Prosimo to demonstrate that its route‑and‑policy system could make it easier to deploy VM‑Series across multiple clouds. It allowed Palo Alto Networks to evaluate the technology through a real integration before the corporate transition. Public materials do not describe the acquisition process, so it is speculation to assert that the partnership was deliberately structured as a formal pre‑acquisition phase.

By early 2025, founder and employee career records had changed. The company page later displayed as acquired. In late 2025, Bhau stated that the technology was fully integrated into Palo Alto Networks products. Taken together, these records support an acquisition judgment, but the legal mechanics remain unpublished.

The sequence matters for both editorial accuracy and for customers. A partnership involves two vendors, two support organisations and clear integration boundaries. An acquisition can shift roadmaps, data, contracts and authority to a single entity. Even when the technical path looks similar at the start, the transition changes more than a logo.

Nebula turned the topology graph into a conversational interface

In February 2024, Prosimo announced Nebula as part of an AI Suite for multi‑cloud networking. The assistant was designed to answer natural‑language questions about states represented in the platform’s graph and telemetry: overlapping networks, cost, route health, security‑policy violations and so on.

The valuable asset was not the language interface itself but the structured cross‑cloud context beneath it. A generic model cannot diagnose private routes or segments it cannot see. Nebula could draw on the inventory, topology, policies and observations that Prosimo had already collected. The prior investment in a common graph fed into AIOps.

Conversational access can open complex data to more operators. On the other hand, it can create misplaced confidence if it drops uncovered assets from an answer, misinterprets a question, or treats a recommendation as an approved operation. High‑risk changes still required deterministic controls, authority boundaries and human confirmation.

Prosimo indicated the potential to reduce mean time to recovery by 60‑80% and to cut cloud networking costs by more than 60%. These are company claims from a product announcement. The available materials contain no independent methodology or customer baselines that prove they are generally applicable. They can be cited as benefits that Prosimo presented, but not as measured market facts.

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

The same 2024 announcement positioned Prosimo’s architecture as relevant to AI workloads. Distributed AI systems can require private access to data, connectivity between clouds and data centres, compliance controls, and routing that reflects application behaviour. These requirements aligned with the existing asset, policy and path models.

A new label did not change the underlay. Prosimo still depended on cloud networks, carriers and customer infrastructure. It also did not provide GPU compute or model‑development software. Its assumed role was the connectivity‑and‑security layer around distributed data and services.

The AI positioning had strategic logic, because more distributed data and services increase the value of a cross‑cloud topology. At the same time, it was a marketing category that was introduced just before the company ceased independent operations. Available materials do not show standalone AI product revenue, named production deployments or audited workload outcomes.

The durable point is that multi‑cloud telemetry can be an input to machine‑assisted operations. The current product question is whether Palo Alto Networks preserved that context and how it is offering the capability. Public evidence at the research cut‑off date does not provide a complete answer.

The commercial model sold software on infrastructure it did not own

During its independent period, Prosimo was a software‑subscription‑and‑services business, not a carrier‑style operation. Customers deployed AXI Edges in their own environments and connected cloud accounts to the control layer. Revenue likely depended on licence or subscription fees, support, professional services and channel activity, though exact prices and contract metrics are not publicly available.

The model could scale without owning fibre. A single software platform could co‑ordinate many cloud regions and customer environments. But gross‑margin structure cannot be inferred from the architecture alone. Maintaining vendor‑API compatibility, edge lifecycles, security integrations and enterprise adoption cost money, and the cloud resources that edges consumed were probably paid by the customer rather than by the vendor.

Prosimo reached enterprises through cloud marketplaces, integration partners, sales channels and named customer references. These are not the same evidence. A marketplace listing shows a procurement and deployment path. A technical integration shows that two systems can be combined under defined conditions. A customer comment shows an adoption example. None of them, taken alone, proves a count of paying customers or recurring revenue.

The breadth of scope may also have increased sales complexity. Networking, security, cloud and application teams could all benefit, but the budget owner might not be obvious. The product required a buyer who would fund a shared control layer rather than operate clouds and teams separately.

Partners, customers and investors held different positions

Amazon Web Services was both an underlay provider and an integration partner for go‑to‑market reach. Azure and Google Cloud were supported environments. Identity providers supplied authentication context, and firewall vendors supplied inspection. Colocation providers and carriers could host and connect edges, while channel partners could design and operate deployments.

In the AWS Cloud WAN materials, Flexport appeared as a named customer reference. This is evidence that an enterprise was interested in the architecture, but the full scope, duration and commercial value of the deployment are not known from the available materials. It should not be used as a proxy for the entire customer base.

General Catalyst led the Series A and was involved in governance as an investor. Company materials also show other investors such as those connected to WRVI or Celesta, and later Prosimo communications referenced prominent investment participation that included a BlackRock‑related name, though the precise investment vehicle has not been resolved by research. These records suggest an influential funding base, but not a complete capitalisation table.

The most important relationship was with Palo Alto Networks. In 2024 it was a security partner; by early 2025 it became the acquirer. This sequence shows how an ecosystem dependency can turn into a control relationship when it purchases the software layer that co‑ordinates the paths into its own products.

At least USD 55 million raised, but the exit economics are unknown

The confirmed funding rounds are a USD 25 million Series A in April 2021 and a USD 30 million Series B in 2022. The total is at least USD 55 million. Available materials do not contain an audited cap table, valuations, debt schedule or subsequent funding rounds.

The acquisition consideration has not been disclosed or independently verified. Without a price, it is not possible to responsibly classify the outcome as a strategic premium, a limited technology purchase, an acqui‑hire or a distress sale. The continued integration of technology into products indicates value, but does not reveal investor or founder returns.

Post‑acquisition Palo Alto Networks revenue or market‑size figures should not be attributed to Prosimo. Once a start‑up is no longer separately observable, there is no standalone revenue, profit or customer segment to analyse. A large owner can deploy the technology widely while making its separate economics less visible.

The absence of a formal acquisition announcement is itself meaningful. Customers, employees and researchers ordinarily look to such announcements for timing, support and strategic rationale. In this case, the state has to be reconstructed from career records, company‑page indicators and a later founder statement. It is enough to correct that the entity is no longer independent, but not enough to fabricate deal details.

Competition was specialist platforms, clouds and in‑house engineering

Prosimo competed with specialist multi‑cloud networking platforms such as Aviatrix and Alkira, with enterprise networking and SASE vendors, and with the native services of AWS, Azure and Google Cloud. It also competed with the in‑house model where enterprises use infrastructure‑as‑code, cloud‑provider transit services, route tables and firewalls directly. Each alternative solved a different part of the same problem.

A specialist controller can offer a single topology‑and‑policy model across multiple providers. A cloud‑native design can reduce third‑party dependencies and align tightly with a single provider. A carrier‑assisted service can supply physical transport. A SASE or security platform can unify connectivity and security enforcement. In‑house engineering can retain control at the cost of additional staffing and integration work.

Prosimo’s differentiation lay in combining application‑ and network‑aware transit, distributed edges, cloud‑native orchestration, topology, telemetry and service insertion. The same breadth made it hard to compare. Buyers needed to test against the specific cloud services, routes, identity systems and security configurations they actually used, rather than comparing category names.

The acquisition changes the competitive frame. Prosimo no longer had to win as an independent company, but its technology must now show value inside Palo Alto Networks. The relevant comparison is whether integrated discovery and route orchestration improve deployment of Palo Alto Networks security products, and whether customers accept the resulting platform dependence.

Cloud‑native services were both foundation and alternative

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN and Google Cloud networking offered powerful native choices to enterprises. Prosimo depended on these while also competing with the possibility that customers could operate them directly.

This relationship created a moving boundary. As cloud providers added global routing, segmentation, private service access and central policy, some of the third‑party functionality became easier to reproduce natively. At the same time, every new native service added an entity that a cross‑cloud controller needed to discover and co‑ordinate. Cloud progress could narrow some of Prosimo’s value while widening the need for inter‑provider translation.

The decision‑making factors were not only technical but organisational. A single‑cloud enterprise with strong in‑house engineering might favour native tools. A multi‑cloud enterprise with fragmented teams might value a single control surface. An organisation in a regulated industry might appreciate a third‑party evidence layer, while also worrying about privileged credentials and data concentration.

No architecture eliminates lock‑in entirely. Native tools increase dependence on one cloud’s APIs and semantics. Cross‑cloud controllers increase dependence on their graph, policies and edge software. The useful question was whether that dependence was visible, portable and aligned with the organisation’s operating model.

Failure could come from controllers, edges, cloud APIs, identity or underlays

Prosimo’s distributed architecture reduced dependence on a single traffic hub but created several interacting failure domains. A central service could fail or hold stale intent. Edges could crash or become isolated. Cloud APIs could reject parts of a change. Identity providers could experience an outage. The underlay could lose capacity or take an unintended path. Inserted firewalls could exhaust resources.

Partial failures are especially difficult. One provider might accept a route update while another rejects it. The controller’s intent state and the actual cloud state would then drift. Traffic could take asymmetric paths and bypass inspection. A trustworthy system requires reconciliation, idempotent operations, staged changes, explicit error states and rollback that accounts for provider‑specific behaviour.

Public evidence describes high‑level availability and optimisation but does not include independent fault‑injection tests, complete incident records or universal service‑level outcomes. Resilience claims should therefore be tied to the documented architecture or to named customer deployment examples.

The acquisition introduces another failure domain: product continuity. Customers need to know which console, API, edge image, policy model and support organisation will replace the historical Prosimo system. Even if the code integration is technically successful, migration risk remains while the commercial and operational boundaries are unclear.

Cloud credentials made the controller part of the critical control plane

Asset discovery and orchestration required access to cloud accounts. A read‑only inventory can be obtained with narrower permissions, but changing routes, segments and service insertion requires stronger rights. The controller therefore sat inside the privileged management plane even though it did not own the workloads.

Compromised credentials could leak topology and allow widespread changes. A software defect or an operator error could propagate policies into multiple clouds. The more useful the platform became, the greater the risk grew; the more accounts and services it could manage, the wider the potential blast radius.

Enterprises needed least‑privilege roles, separation of discovery and change credentials, multi‑party approval, full auditing, rotation, emergency revocation, and recovery paths that did not depend on the same controller alone. Public materials lack a full independent security assessment, so these are controls that implementation requires, not product guarantees.

The telemetry graph is similarly sensitive. It can reveal application names, network structures, policies, user relationships, route health and cost patterns. Post‑acquisition governance should clarify where that data is stored, which Palo Alto Networks products can access it, and how former customer rights have transferred. Public evidence at the research cut‑off does not answer these.

The acquisition moved a cloud‑neutral layer inside a security platform

As an independent company, Prosimo could position itself as a common layer that spanned clouds and security services. Once Palo Alto Networks became the owner, incentives changed. The acquired technology can make it easier to deploy Palo Alto Networks products such as VM‑Series. The integrated experience may improve, but new questions arise about support for third‑party inspection services.

Ownership alone does not prove loss of neutrality. The available materials do not include a current partner list or product architecture. However, what customers need to ask changes. They must verify whether the route controller remains open to multiple security vendors, whether they can export policy and telemetry, and whether optimisation favours the owner’s product portfolio.

Integration statements emphasised ingress, egress and east‑west inspection. This focus makes it plausible that Prosimo’s topology and orchestration have become part of a security‑deployment system. It does not prove that the historical App Transit, user access, cost optimisation and all cloud‑networking workflows survive as separate capabilities.

This follows a recurring pattern in infrastructure. A start‑up abstracts a difficult co‑ordination problem; a large platform company acquires it because the abstraction can increase the use and control of its flagship products. The buyer gains a deployment path. Customers gain integration while potentially losing some supplier independence.

The largest missing piece is the current product mapping

Public records confirm the acquisition and integration, but they do not fully show how AXI, Network Transit, App Transit, AIR and Nebula map to current Palo Alto Networks products or SKUs. Nor do they disclose end‑of‑life dates for the legacy products, migration procedures or a feature‑by‑feature continuity table.

This gap prevents a current product review. The historical descriptions show what Prosimo built and why it mattered. They do not show which capabilities are currently available, licensed and supported. Current deployment advice requires current Palo Alto Networks documentation, not historical Prosimo announcements.

The missing mapping also limits strategic analysis. A full absorption of the topology graph and orchestration layer is different from selectively using asset discovery and firewall placement. The former creates a broad multi‑cloud control service; the latter mainly accelerates security deployment. The co‑founder’s statement supports technology continuity but does not resolve this architectural boundary.

Future product documentation, migration guides and customer stories could resolve much of the uncertainty. Until then, the accurate formulation is that Prosimo technology has been integrated into Palo Alto Networks products, according to the co‑founder, but the scope and packaging are unverified.

Who controls multi‑cloud routing

No single entity controls the entire path. The enterprise manages account ownership, business intent, application design and the credentials it grants. A cross‑cloud controller can discover topology, translate policy, select paths and change native routing state. Cloud providers control APIs, transit services, private endpoints, backbones and many failure domains. Carriers and colocation providers manage other transport segments. Security services decide whether inspected traffic is allowed.

Prosimo aimed at the most strategically useful middle position. It did not own the underlay, but it tried to own the graph and policy translation above it. Whoever controls that layer decides which assets are visible, how segments are expressed, where edges are placed, which services inspect traffic, and which telemetry is considered authoritative. Even when someone else owns the fibre, this amounts to practical routing authority.

After the acquisition, Palo Alto Networks owns the surviving Prosimo technology and decides how it is integrated, packaged and developed. Cloud providers retain sovereignty over their own environments, and enterprises can revoke credentials and choose a different architecture. However, if topology, policies and operational workflows become dependent on the controller, departure becomes expensive.

The answer is therefore not absolute but layered. The enterprise grants authority; the controller co‑ordinates; the cloud and carrier underlays transport; the security platform enforces policy. The history of Prosimo shows that the ownership of the co‑ordination layer can change even when cloud accounts and physical paths remain with the same owners.

Key sources

Why Prosimo matters after the acquisition

Prosimo captured a genuine shift in infrastructure. The unit of network operations is moving from devices and prefixes to applications, identity, service dependencies and policy graphs. Cloud‑native APIs make network state programmable, and distributed software edges make policy enforcement points movable. A controller that sees across multiple clouds can co‑ordinate operations that no single cloud console can complete.

The company also revealed the cost of that co‑ordination. A common layer requires privileged credentials, ongoing API maintenance, accurate discovery, semantic translation, telemetry and operational discipline. It reduces fragmentation while creating a new concentration. The same system that simplifies routing can widen the impact of a single wrong decision.

The acquisition by Palo Alto Networks made the control problem more visible. Networking and security are converging around service insertion, workload discovery and policy. A security vendor that knows the topology and can change the routes is not limited to inspecting the traffic that is presented to it; it can also influence which traffic reaches inspection and where.

Prosimo should therefore be seen neither as an independent‑brand failure nor as proof that one platform has solved multi‑cloud. Its lasting contribution was to define the cross‑cloud graph as infrastructure. The remaining question is whether that graph, now inside a large security company, retains the transparency, portability and governability that customers need to trust it.