Summary

  • Prosimo was founded in 2019 and raised at least $55 million through a 2021 Series A and a 2022 Series B; audited revenue, valuation, and acquisition price were not disclosed.
  • AXI combines a central intent, topology, and analytics layer with distributed edges to discover cloud assets, connect applications, insert security services, and collect telemetry, but it does not own a physical backbone.
  • The VM-Series integration announced in June 2024 preceded Prosimo's integration into Palo Alto Networks around February 2025; public information does not provide an exact date, price, or current product mapping.
  • Control remains distributed among enterprises, orchestration software, cloud providers, and Palo Alto Networks; whether topology, credentials, policies, and routing privileges can be migrated is the most critical test for customers.

The company disappeared, but the questions remain

Describing Prosimo as a vendor still operating independently in 2026 would be inaccurate. Public career histories show that its founders and several employees joined Palo Alto Networks around February 2025. Prosimo’s corporate page is marked as acquired, and former CTO Nehal Bhau later stated that the company’s technology has been integrated into Palo Alto Networks products. This evidence is sufficient to confirm a change in control and that the technology retains continuing value; however, it does not confirm the signing date, closing date, legal form, or transaction price.

This fact must be addressed at the outset, because it determines the appropriate tense for all product descriptions. AXI, Network Transit, App Transit, Application-driven Intelligent Results, and Nebula were all well-documented capabilities during Prosimo’s independent period. Until Palo Alto Networks publishes current product and support mappings, they should not be written about as active products still sold independently under the Prosimo name. Post-acquisition, the historical architecture may persist as embedded code, shared services, product modules, or internal engineering assets—and these forms are not equivalent.

The disappearance of a brand does not mean the underlying problems have become outdated. Enterprises continue to distribute workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation facilities, SaaS platforms, and remote users. Each environment has its own routing, gateways, private endpoints, identity controls, security services, quotas, and billing rules. Even if an enterprise owns all the accounts, it may not have a unified view that explains how requests flow between these environments. Prosimo’s significance lies in its attempt to provide that view.

Therefore, the acquisition is not a footnote at the end; it is the central thread of this article. Prosimo built a cross-cloud control system that could discover assets, interpret application context, and steer traffic toward security services. Palo Alto Networks initially appeared as a technology partner whose VM‑Series firewalls could be inserted into those paths; subsequently it became the owner of the technology. The boundary that once separated routing orchestration from deep inspection has been moved inside a single cyber‑security platform.

Multi-cloud routing is really a fight over context

A routing table can tell you whether a prefix is reachable through a next hop. By itself, however, it cannot tell you which application the user wants to reach, whether the requester is trustworthy, whether traffic must be inspected, whether a private endpoint is available, whether one cloud path is more expensive than another, or why a transaction still fails after the packet arrives. Multi-cloud operations turn these questions into a shared-control problem.

Prosimo’s judgment was that routing authority cannot rest on Layer‑3 reachability alone. It tried to combine cloud asset inventory, network state, application identity, user identity, risk, performance, and transaction telemetry. That context can support more specific policies: connect to an application, isolate a segment, choose an ingress location, or steer specific traffic through a firewall. The value lies not in creating a new fibre path but in deciding how to combine existing paths and services.

This also explains why Prosimo used the term “application experience infrastructure.” Application requests are placed above individual network entities; a VPC, VNet, subnet, transit hub, or private link is merely a component in the end-to-end path, not the endpoint of management. This approach causes the product to fall into multiple markets at once: cloud networking, application delivery, zero‑trust access, network assurance, cost optimisation, and security‑service insertion.

That functional breadth brings opportunity but also ambiguity. A platform that spans multiple teams can resolve coordination failures that no single team owns; but it is also harder to evaluate, because network, security, cloud, application, and finance teams use different success criteria. Prosimo had to demonstrate that a unified model improves operations without becoming yet another centralised layer that holds high privileges and can affect every environment with a single mistake.

What Prosimo was, and what remains today

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 during its independent operation, and Nehal Bhau served as co‑founder and CTO. Public biographies also associate Linus Aranha and Pradeep Aragonda with founding or senior engineering leadership roles, but their precise positions should be confirmed against date‑specific profiles.

The company’s flagship platform was Application eXperience Infrastructure, abbreviated AXI. AXI managed intent, topology, analytics, and orchestration through a central software layer, while distributed AXI Edges were deployed in cloud regions, colocation facilities, or adjacent on‑premises infrastructure. Later, the company reorganised its product structure under Full‑Stack Cloud Transit, with Network Transit and App Transit handling different classes of connectivity. AIR analysed telemetry and produced operational insights, while Nebula added natural‑language interaction in 2024.

Prosimo was not a cloud operator, nor did it own a global fibre backbone connecting every region. Paths might traverse cloud‑provider backbones, the public Internet, Direct Connect or ExpressRoute, colocation links, carrier circuits, or an enterprise’s own network. Nor was it a firewall vendor in the same category as Palo Alto Networks. In the 2024 integration, Prosimo handled discovery, segmentation, and traffic steering, while VM‑Series performed deep security inspection.

After the acquisition, the most prudent label is “technology lineage.” Later integration statements emphasised multi‑cloud asset discovery and faster deployment of software firewalls for ingress, egress, and east‑west traffic. This confirms that important components of Prosimo survive, but it does not prove that the full historical AXI product catalogue, commercial packaging, and support model continue unchanged.

The new puzzle that emerged after SD‑WAN

The founding team brought experience in large‑scale networking, application delivery, and cloud infrastructure. Prosimo also emerged from a wider founder‑and‑engineer ecosystem associated with Viptela, a company that helped establish SD‑WAN as a distinct category in the enterprise market. But the next puzzle was different. SD‑WAN can simplify the relationship between branches and networks or applications, but it does not automatically create a unified operating model across 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 that sits outside both, private links that connect to data centres, and security inspection deployed at a specific boundary. Each dependency may be expressed with different cloud‑native entities. Network teams see prefixes and transit hubs; cloud teams see accounts and resources; application owners see domain names and transactions; security teams see zones and inspection policies.

Prosimo started from the request rather than the branch. The real question was: how should a user or workload access an application with acceptable security, performance, availability, and cost? This shifts the routing entity from a destination prefix to a transaction that carries identity and application context. The platform must also collect and maintain far more information than a traditional router.

Market timing was also favourable. AWS, Azure, and Google Cloud were expanding native transit and private connectivity services. An enterprise could build complex networks inside a single cloud, but the APIs, entities, and policy models remained distinct. Prosimo’s opportunity was not to replace those with a private backbone, but to orchestrate those cloud‑native capabilities.

From 2019 founding to 2021 public launch

Prosimo was founded in 2019 but formally launched only on 6 April 2021. General Catalyst led a $25 million Series A at the time of the launch. The investor described the opportunity as delivering application experience across multiple clouds, aligning with the founding team’s goal of moving beyond traditional branch connectivity and establishing a new category.

The market at launch was both crowded and undefined. Cloud providers were lowering the barriers to using their networking services; SD‑WAN and SASE vendors were extending policies to the cloud; application‑delivery vendors could optimise requests; security vendors could inspect traffic. Prosimo had to demonstrate that these capabilities could work together in a cloud‑oriented architecture without claiming to replace every adjacent system.

Funding gave the company the capacity to develop integrations, software edges, analytics systems, commercial teams, and partnership channels. Funding alone, however, does not prove product‑market fit, revenue scale, or long‑term differentiation. Available material does not provide audited revenue, annual recurring revenue, total customer count, or valuation. Fundraising records attest to an investor’s commitment to a market thesis, not to a complete operational scorecard.

In 2022, Prosimo closed a Series B round reported as oversubscribed and totalling $30 million. Adding the two explicitly identified rounds gives a verified total of at least $55 million. Some databases may show higher figures because of duplicate entries for announcements or associated entries; such figures should not be used until the underlying events are reconciled.

AXI places policy above the clouds and enforcement close to workloads

The AXI architecture splits work between a central control-and-analytics layer and distributed software edges. The central layer holds application and network intent, discovers assets, assembles topology, integrates identity, analyses telemetry, and orchestrates changes. AXI Edges are deployed near workloads or users so that policy can be enforced without depending on a distant physical centre.

This separation resembles other software‑defined systems, but it deals with cloud‑native entities that carry application semantics. The controller needs access to cloud accounts and APIs; the edges need access to native transit services, workload networks, private endpoints, or external paths. The platform’s power comes from combining two views: global intent above the clouds, and local enforcement close to the traffic.

The architecture also introduces concrete deployment boundaries. Each edge consumes cloud resources, requires a high‑availability design, and must be upgraded, monitored, and secured. The control layer requires sufficient privileges to discover assets and alter network state. The enterprise gains a unified workflow while adding a management system whose availability and correctness feed directly into production reachability.

Prosimo sometimes used the phrase “autonomous cloud networking.” The evidence supports automation, recommendations, and API‑driven orchestration, but it does not support a network that operates independently of human policy, cloud services, and the underlying transport. Operators still needed to define intent, approve access, handle exceptions, and bear responsibility for outcomes.

AXI Edge is a placement choice, not a universal virtual appliance

An AXI Edge can be deployed in a cloud VPC or VNet, a colocation environment, or adjacent infrastructure. AWS technical documentation shows an Edge VPC connected to workload VPCs through Transit Gateway, with an optional firewall in the chain, while also connecting on‑premises sites or remote users. The enforcement point sits inside the cloud topology, rather than at a distant enterprise boundary.

Placement affects more than latency. It determines where traffic enters the policy domain, which cloud backbone or Internet path is used, where encryption and inspection occur, and which telemetry the platform can see. Poor placement can introduce detours or costs; good placement can shorten paths and keep traffic close to workloads.

Distributed deployment increases the number of fault domains. Capacity, software version, availability‑zone design, route convergence, and access permissions may differ across regions. High availability is not just running two instances; the controller, cloud routing tables, security services, and return paths must also reach consistent decisions about failover state.

Consequently, the Edge is part of a larger operating system. Its value depends on whether asset discovery, topology, policy, and analytics remain consistent with the surrounding cloud environment. Viewing it as a stand‑alone virtual appliance misses the architecture Prosimo was actually selling.

The underlying transport always belongs to other players

Prosimo orchestrated transport but did not own the physical paths. Application traffic could use AWS or other cloud‑provider backbones, the public Internet, Direct Connect, ExpressRoute, colocation connectivity, carrier circuits, or the enterprise’s own network. The platform could select and orchestrate among available options, but it could not eliminate the latency, packet loss, fault domains, or billing rules that those providers introduce.

This boundary is essential for understanding performance claims. The controller can select an observed path that is better or place an ingress closer to users; but it cannot guarantee that a carrier won’t fail, a cloud region won’t experience an outage, or external dependencies will always respond quickly. Application experience is also affected by DNS, server processing, storage, browser behaviour, and third‑party services—areas that lie well outside a network controller’s remit.

Not owning a private backbone is not only a weakness. Prosimo could leverage infrastructure the enterprise had already procured and benefit from cloud‑provider investment; it could enter more regions without laying fibre and could orchestrate native systems such as AWS Cloud WAN. The trade‑off is dependence on API stability, service quotas, commercial terms, and provider‑specific semantics.

Therefore, Prosimo’s claim was operational control, not physical ownership. It tried to make heterogeneous underlays work under a unified management model while preserving their native advantages. Whether such an abstraction reduces lock‑in or merely shifts it to the controller depends on whether policies, topologies, and edge deployments are portable.

Network Transit handles reachability between network entities

Network Transit targets VPCs, VNets, subnets, regions, sites, and segments. It orchestrates cloud‑native transit hubs and routing entities so that teams can establish connectivity through a unified workflow rather than operating each cloud individually. It addresses a classic networking need: a source or segment must be able to reach a target over a permitted path.

This does not mean differences between clouds disappear. AWS, Azure, and Google Cloud expose different entities, quotas, and routing behaviours. Address overlap, asymmetric paths, private endpoints, and vendor‑specific service constraints still require engineering. Prosimo can normalise common operations and show relationships, but the underlying systems retain their own constraints.

Network Transit also handles segmentation. Routing domains and policies can isolate environments or limit reachability. The controller must understand how a segment exists across multiple clouds and how native entities enforce that boundary. A single unified policy may still translate into multiple sets of vendor‑specific changes.

A unified intent interface is the advantage; translation is the risk. If the declared policy diverges from real cloud configuration, the enterprise may believe a segment is protected when the actual state is different. Reconciliation, auditing, and explicit failure states are just as important as initial configuration.

App Transit makes the application itself a routing entity

App Transit extends the model from subnets to applications. It can decide how a user or workload should access a service based on application domain name, identity, request type, transaction health, risk, and performance. This is one of the clearest differentiators between Prosimo and a traditional cloud router.

The application view is valuable because modern services do not necessarily map to stable addresses. Managed platforms, SaaS endpoints, and distributed components change, but the application identity still makes sense. Policies written around a service or user may be more durable than rules written only around addresses and ports.

This model depends on accurate discovery. The controller must know which domain names and endpoints belong to the application, which dependencies are essential, and which identity‑provider claims are trustworthy. Out‑of‑date mappings can cause requests to travel wrong paths or receive incorrect policies. The application abstraction does not remove the need to understand network state; it adds a semantic layer on top.

The combination of Network Transit and App Transit recognises that two classes of system coexist inside an enterprise: traditional IP workloads and private subnets still exist, while new applications depend on domain names, identity, and managed services. Full‑Stack Cloud Transit aims to place both models inside the same operating framework, rather than forcing one to replace the other.

Identity broadens routing decisions—and the trust boundary

Application‑aware access requires identity integration. The platform can decide whether to establish a connection, and which path to use, based on user or workload context. This enables a zero‑trust‑style policy: location alone is limited public evidence to prove access rights.

Identity increases policy precision while introducing new dependencies. Routing or application policies now rely on identity providers, their assertions, session state, and group data. Even when routers and edges are healthy, an unavailable authentication service or a change in attributes can cause path failures. Troubleshooting must span network and identity operations boundaries.

The controller also concentrates sensitive context. It may hold topology, application relationships, user attributes, risk signals, and policy outcomes. These data can aid diagnostics and optimisation but also raise the stakes of unauthorised access. Least privilege, retention periods, auditing, and separation of duties are therefore architectural requirements, not bolt‑on compliance.

Prosimo reflected a broader infrastructure shift: routing and access policy increasingly depend on identity and application semantics. The more context the platform sees, the more valuable its decisions can be, and the more rigorously its privileges must be governed.

Asset discovery builds the graph on which all subsequent decisions depend

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

Discovery matters because cloud environments often change outside central networking processes. Application teams can create accounts, networks, endpoints, and managed services through their own automation. Manually maintained diagrams quickly become stale. API‑driven inventories are normally more current, but completeness still depends on account coverage, permissions, parsing logic, and cloud APIs.

The graph is not just for documentation. Routing, segmentation, service insertion, and optimisation may all be computed from it. A missing asset or dependency can skew the conclusions derived above it. Topology must therefore retain provenance: when it was collected, from which account, covering which regions, and whether any requests failed.

This also helps explain the acquisition. Palo Alto Networks can deploy security capabilities more effectively only when it knows where workloads and traffic paths are. A system that can discover cloud assets and change routing can shorten the distance between buying a software firewall and putting it in the right place. Bhau’s subsequent statements emphasise asset discovery and faster deployment of software firewalls precisely in this context.

AIR turns edge telemetry into operational recommendations

Application‑driven Intelligent Results (AIR) analysed telemetry collected by the AXI Edges. AWS technical documentation references round‑trip latency, processing time, application response time, transaction type, risk, and policy results. The platform could correlate user, network, and application observations instead of presenting isolated device counters.

This correlation targets common operational questions: a slow transaction could come from the user path, the edge, the cloud backbone, a security service, or the application itself. A cross‑layer view can narrow the troubleshooting scope faster than multiple independent consoles, and it can provide recommendations for path, placement, risk, and cost.

The quality of recommendations depends on telemetry coverage and the interpretation model. The edge can only see traffic that passes through it; external application dependencies and cloud‑provider internal state may be invisible. Hence a recommendation can have directional value without necessarily identifying root cause.

Telemetry also carries governance value. Historical data can explain why a route or policy changed, but it can also reveal sensitive application usage and user behaviour. Public material does not fully describe data retention and post‑acquisition data governance, so these questions remain in due‑diligence territory.

AWS provided the cleanest implementation example in the public record

Prosimo’s collaboration with AWS produced the strongest publicly available technical evidence. The company integrated with AWS Transit Gateway, Cloud WAN, PrivateLink, and Marketplace for Containers Anywhere. AWS published workflows for AXI Edge placement, application access, identity, security, and optimisation.

AWS Cloud WAN is particularly important. It provides a cloud‑native backbone and segmentation capability that Prosimo orchestrated rather than replaced. The division of labour was clear: AWS owned the native network and global infrastructure; Prosimo provided cross‑cloud intent, application context, edge software, and analytics.

The Marketplace workflow simplified day‑one deployment but did not eliminate account permissions, routing design, high availability, capacity planning, and long‑term operational concerns. Day‑0 automation reduces installation friction but does not substitute for ongoing governance.

Prosimo’s material also referenced a customer testimonial from Flexport, supporting the AWS Cloud WAN use case. This demonstrates that an enterprise customer was willing to endorse the architecture, but it is not an independent audit of deployment scale, savings, or availability. Customer quotes should be treated as adoption examples, not as universal performance proof.

Azure and Google Cloud complete the multi‑cloud story

Prosimo also supported Microsoft Azure and Google Cloud. Product material described orchestration around Azure Virtual WAN, as well as Google Cloud networking and private‑service entities. The aim was to provide a unified operating model while preserving each cloud’s native networking.

Support does not imply feature parity. Cloud APIs evolve at different rates, and similar product names can hide different semantics. Routing, segmentation, private endpoints, or service insertion may require vendor‑specific handling. Available evidence does not reconstruct a per‑feature mapping covering all regions and versions.

Thus the multi‑cloud abstraction is closer to a translation system. It can normalise common intent and workflows, but it must preserve differences that affect security, cost, and failure. Abstraction becomes dangerous when the interface looks uniform but the implementation differences are invisible to the operator.

The same holds after the acquisition. Palo Alto Networks can use a unified graph to place security across clouds, but cloud providers still control the native entities that implement those paths. Owning the orchestration layer is not the same as owning the cloud underlay.

The product stretched from connectivity to the full operational lifecycle

By 2023, Prosimo was describing the product as supporting a complete workflow for designing, building, troubleshooting, and managing multi‑cloud networks—not merely tunnels or gateways. Asset discovery fed design; orchestration created connectivity; maps and telemetry enabled diagnostics; policy and historical state supported ongoing management.

This positioning widened the potential buyer pool. Network teams used topology and path analysis; cloud‑platform teams onboarded accounts and services; security teams examined segmentation and inspection paths; migration teams planned changes; FinOps teams assessed egress costs and paths. Platform value increases when multiple teams work from the same evidence.

Shared evidence also creates governance tensions. A central platform may reveal that a cloud team’s native configuration is inconsistent with enterprise policy. The organisation must decide which system is authoritative and who can approve remediation. Software alone cannot resolve that institutional question.

The lifecycle narrative also raises switching costs. Once a controller holds the asset graph, policies, telemetry, edge placements, and automation integrations, replacing it is not just moving cables—it is exporting or rebuilding an operating model. Prosimo solved cloud fragmentation, but it could also create controller dependency.

Segmentation spans Layer‑3 reachability to Layer‑7 application policy

Prosimo described segmentation as covering Layer‑3 through Layer‑7. At the network layer, routing domains and segments determine which subnets or sites can communicate; at higher layers, application identity, user context, and transaction attributes can further qualify the rules.

This model can narrow the gap between network zones and application policies. A specific business service may be allowed while broad subnet‑to‑subnet communication remains blocked; conversely, a network path may be reachable yet denied because the identity or application context does not match.

This did not turn Prosimo into a full next‑generation firewall. The 2024 Palo Alto integration explicitly divided labour: Prosimo handled traffic steering, segmentation, and service insertion; VM‑Series performed deep inspection. Policy steering and security enforcement have different failure modes, and the two must not be conflated.

Segmentation is effective only when all relevant paths are represented. Unknown routes, cloud‑native exceptions, or failed service insertion can allow traffic to bypass controls. Assurance requires reconciling declared policy, real cloud state, and observed traffic, not trusting the console configuration alone.

Service insertion links routing control to firewall economics

Cloud security design must decide where inspection happens. Centralised firewalls can simplify policy and reduce instance count, but they can create backhaul, concentration risk, and capacity pressure. Distributed firewalls sit closer to workloads but increase the number of deployments, licences, upgrades, and policy operations.

Prosimo’s VM‑Series integration supported both patterns. Policy could steer specific traffic toward a central inspection point or toward firewalls distributed inside application VPCs. Prosimo modified the surrounding routes; Palo Alto Networks provided the inspection function.

This architecture made routing orchestration commercially valuable to a security vendor. A software firewall cannot protect traffic that never reaches it. Discovery, placement, and routing updates can shorten the distance between buying a security capability and actually placing it in the production path. This is one rational strategic motivation for Palo Alto Networks’ acquisition of Prosimo’s technology.

At the same time, the controller’s blast radius expands. An incorrect policy could bypass inspection, create loops, cause asymmetric routing, or disrupt applications. Health checks, staged changes, simulation, auditing, and rollback are necessary because a service‑insertion error is both a network incident and a security incident.

The 2024 partnership cannot be back‑dated into a completed acquisition

Prosimo and Palo Alto Networks announced the VM‑Series integration on 12 June 2024. The announcement described a joint technical and commercial solution; it did not claim that Palo Alto Networks had acquired Prosimo. Treating the partnership as proof of ownership conflates two distinct events.

The partnership did build a bridge. Prosimo could demonstrate how its routing and policy system simplified cross‑cloud VM‑Series deployment; Palo Alto Networks could evaluate the technology in a real integration. Publicly available material does not document the acquisition process, so the partnership cannot be inferred to be a formal pre‑acquisition step.

By early 2025, founder and employee biographies shifted; the company page subsequently showed an acquired status; in late 2025, Bhau stated that the technology had been fully integrated. Taken together, these three classes of evidence are sufficient to support the conclusion of an acquisition, but they still leave the legal deal details unfilled.

This timeline also matters to customers. A partnership implies two vendors, two support organisations, and a clear integration boundary. An acquisition can transfer roadmaps, data, contracts, and privileges into a single entity. Even when the technical path looks similar on the surface, the governance implications have changed.

Nebula turned the topology graph into a conversational interface

Prosimo launched Nebula in February 2024 as part of the Multi‑Cloud Networking AI Suite. It was designed to answer natural‑language questions about address overlap, cost, route health, security‑policy violations, and similar topics—all drawing on the platform’s graph and telemetry.

The genuinely valuable asset is not the language interface itself but the underlying structured context. A generic model cannot diagnose private routes it cannot see. Nebula could query the assets, topology, policies, and observations that Prosimo had already collected, so the earlier investment in a unified graph became the foundation for AIOps.

Conversational access can put complex data in front of more operators, but it can also create false confidence: answers may omit unsupported assets, misinterpret questions, or present recommendations as approved actions. High‑risk changes still require deterministic controls, authorisation boundaries, and human review.

Prosimo once claimed that mean time to repair might fall by 60–80 per‑cent and that cloud‑networking costs could drop by more than 60 per‑cent. These figures come from vendor product announcements and lack independent methodology or customer baselines to prove general applicability. They may be cited as targets Prosimo set, but not as established industry fact.

AI workloads are a new use case, not proof that a new market is already established

The same 2024 announcement also described the Prosimo architecture as suitable for AI workloads. Distributed AI systems may require private data access, connectivity across clouds and data centres, compliance controls, and application‑aware routing. These needs align with the existing asset, policy, and path models.

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

This positioning has strategic logic, because the more data and services are dispersed, the more valuable cross‑cloud topology becomes; yet it was also a marketing category introduced shortly before the company ceased independent operation. Available evidence contains no separate AI revenue, named production deployments, or audited results.

The sustainable conclusion is that multi‑cloud telemetry can serve as an input to machine‑assisted operations. The open question today is whether Palo Alto Networks has preserved that context and how it exposes the capability to customers. The public record does not provide a complete answer.

The business model was selling software on top of other people’s infrastructure

Prosimo’s independent business followed a software‑subscription and services model, not a carrier model. Customers deployed AXI Edges in their own environments and connected their cloud accounts to the control layer. Revenue could come from licences or subscriptions, support, professional services, and channel arrangements, but available material does not provide specific pricing or contract metrics.

This model could scale without owning fibre. One platform could coordinate many regions and customer environments. Gross margins cannot be inferred from architecture, however; ongoing support for vendor APIs, edge lifecycling, security integrations, and enterprise deployments can be expensive, and the cloud resources consumed by edges may also be directly borne by the customer.

Prosimo used cloud marketplaces, integration partners, channels, and customer references to reach enterprises. These relationships are not interchangeable. Marketplace listings prove that a procurement and deployment channel exists; a technical integration proves that two systems can work together under specific conditions; a customer quote provides a reference. No single one of these independently proves paid‑customer count or recurring revenue.

The product breadth may also have increased selling difficulty. Network, security, cloud, and application teams could all benefit, but budget ownership remained unclear. Prosimo needed a buyer willing to pay for a common control layer rather than letting each team continue operating independently.

Partners, customers, and investors play different roles

AWS served simultaneously as an underlay infrastructure provider and a marketplace integration partner; Azure and Google Cloud were supported environments; identity providers supplied authentication context; firewall vendors furnished inspection; colocation and carrier services could host or connect edges; channel partners could design and operate deployments.

Flexport is the named customer reference in the AWS Cloud WAN material. This proves enterprise interest in the architecture but does not describe the full scope, duration, or commercial value of the deployment; it cannot substitute for total customer scale.

General Catalyst led the Series A and participated in investment governance. Company material also references WRVI/Celesta‑associated investors, and later information mentions a notable involvement linked to BlackRock, though research could not identify the specific investment vehicles. These details suggest a strong funding network but are not a complete cap table.

Palo Alto Networks is the most important relationship. It moved from being a security partner in 2024 to the acquirer in early 2025. This progression illustrates how technology dependence becomes a control relationship when an ecosystem partner buys the coordination software layer that sits between its own products.

Verified funding of at least $55 million, exit economics remain unknown

Confirmed funding includes the $25 million Series A in April 2021 and the $30 million Series B in 2022. Available material contains no audited cap table, valuation, debt arrangements, or follow‑on financing.

The acquisition consideration has not been disclosed or independently verified. Without a price, the outcome cannot responsibly be classified as a strategic premium, an ordinary technology acquisition, an acqui‑hire, or a distressed transaction. Continued integration of the technology indicates value but does not reveal actual returns to investors and founders.

Neither can Palo Alto Networks’ revenue and market scale be attributed to Prosimo. After the acquisition, Prosimo is no longer an independently observable economic unit; there is no separate revenue, profit, or customer segment to analyse. A larger owner may expand the technology’s reach while making its standalone economics more opaque.

The absence of a formal acquisition announcement is itself an important fact. Normally, customers, employees, and researchers use an announcement to judge timing, support, and strategic rationale. Here the status must be reconstructed from career histories, company‑state labels, and a subsequent founder statement. This is sufficient to correct the corporate identity but limited public evidence to fabricate deal terms.

Competition comes from specialist platforms, cloud‑native services, and in‑house engineering

Prosimo faced specialist multi‑cloud networking platforms such as Aviatrix and Alkira, enterprise‑networking and SASE vendors, and the native services of AWS, Azure, and Google Cloud. It also competed with enterprises’ own build‑it‑yourself models that used infrastructure‑as‑code, cloud transit services, route tables, and firewalls directly. Different alternatives solve different parts of the same problem.

Specialist controllers offer unified cross‑cloud topology and policy; cloud‑native designs reduce third‑party dependency and stay close to a single provider; carrier services provide physical transport; SASE or security platforms combine connectivity with enforcement; in‑house engineering trades staffing and integration cost for control.

Prosimo’s differentiation was the combination of application and network transit, distributed edges, cloud‑native orchestration, topology, telemetry, and service insertion. That same breadth also makes comparison harder. Buyers must test against the cloud services, routing, identity, and security patterns they actually operate, rather than comparing category labels alone.

The acquisition changes the competitive frame. Prosimo no longer needs to win as a standalone company; its technology must prove value inside Palo Alto Networks. The key comparisons become: does integrated discovery and routing orchestration improve the deployment of Palo Alto security products, and do customers accept the resulting increase in platform dependence?

Cloud‑native services are both foundation and substitute

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN, and Google Cloud networking capabilities offer enterprises a powerful native choice. Prosimo depended on them while also competing with customers operating them directly.

This boundary keeps moving. As cloud providers add global routing, segmentation, private services, or centralised policy, some third‑party functions become easier to replicate natively; at the same time, each new native service creates still more entities that a cross‑cloud controller needs to discover and coordinate. Cloud progress may shrink one part of Prosimo’s value while enlarging the need for cross‑provider translation.

Organisational capability is again the deciding factor. A single‑cloud enterprise with strong in‑house engineering may prefer native tooling. A multi‑cloud enterprise with fragmented teams may need a unified control layer. Regulated organisations may value third‑party evidence but worry about credential and data concentration.

No architecture eliminates lock‑in completely. Native tools depend on one cloud’s APIs and semantics; a cross‑cloud controller depends on its graph, policies, and edges. The right question to ask is whether the dependency is transparent, portable, and matched to the organisation’s operating model.

Failure can originate in the controller, the edge, cloud APIs, identity systems, or the underlay

A distributed architecture reduces dependence on a single traffic centre but creates multiple interacting fault domains. A central service could be unavailable or hold stale intent; an edge could fail or become isolated; cloud APIs could reject partial changes; identity systems could experience an outage; the underlay could degrade or reroute; inserted firewalls could exhaust resources.

Partial failure is especially difficult. One cloud accepts a route update while another rejects it, causing the controller’s desired state and the real state to diverge; traffic may follow asymmetric paths or bypass inspection. A reliable system must offer reconciliation, idempotent operations, staged changes, explicit errors, and per‑vendor‑adapted rollback.

Public evidence describes high‑level availability and optimised architecture, but there are no independent fault‑injection studies, complete incident histories, or universal service‑outcome data. Therefore, resilience conclusions should be limited to the documented architecture or named‑customer evidence.

The acquisition adds a new failure domain: product continuity. Customers need to know which console, APIs, edge images, policy models, and support organisation replace the historical Prosimo system. Even a technically successful code integration can create migration risk if the commercial and operational boundaries are unclear.

Cloud credentials put the controller inside the critical management plane

Asset discovery and orchestration require access to cloud accounts. A read‑only inventory can work with limited permissions; routing, segmentation, and service‑insertion changes need stronger privileges. Hence the controller, although it does not own workloads, sits inside a highly privileged management plane.

Credential compromise could expose topology or enable widespread changes; a software defect or operational error could propagate policy across multiple clouds. The more accounts and services the platform governs, the larger the potential blast radius.

Enterprises need least‑privilege roles, separate credentials for discovery and write operations, multi‑person approval, comprehensive auditing, rotation, emergency revocation, and recovery paths that do not depend on the same controller. Public material lacks a full independent security assessment, so these are necessary deployment controls, not verified guarantees.

The telemetry graph is similarly sensitive. It can reveal application names, network structure, policies, user relationships, route health, and cost patterns. Post‑acquisition governance should explain where these data reside, which Palo Alto Networks products can consume them, and how historical customer permissions migrate. The public record has not yet answered this.

An acquisition puts a control layer once seen as neutral inside a security platform

When independent, Prosimo could describe itself as a common control layer across clouds and across security services. Once Palo Alto Networks became the owner, the incentive structure changed. Acquiring the technology makes it easier to deploy VM‑Series and other Palo Alto products. This may bring tighter integration, but it also raises the question of whether third‑party inspection services continue to receive equal support.

A change in ownership does not prove that neutrality has disappeared. Available material contains no current partner matrix or full architecture. The questions customers need to ask have changed, however: does the controller still support multiple security vendors, can policies and telemetry be exported, and does the optimisation logic favour the owner’s product portfolio?

Integration statements emphasise ingress, egress, and east‑west inspection. This indicates that Prosimo’s topology and orchestration may become part of a security‑deployment system, but it does not prove that the historical App Transit, user access, cost optimisation, and all cloud‑networking workflows continue as standalone features.

This is a recurring pattern in infrastructure: a start‑up abstracts a complex coordination problem; a large platform vendor buys that abstraction layer to increase deployment and control of its core products. Customers may gain better integration while losing some supplier independence.

Current product mapping is the biggest missing fact

The public record confirms an acquisition and integration, but it does not state which current Palo Alto Networks products or SKUs correspond to AXI, Network Transit, App Transit, AIR, and Nebula. Nor has it published legacy‑system support timelines, migration processes, or a per‑feature continuity table.

Therefore, a present‑tense product review is impossible. Historical material can explain what Prosimo built and why it mattered, but it cannot state which capabilities are available today, how they are licensed, or who supports them. Any recommendation for current deployment must rely on Palo Alto Networks’ current documentation, not on archived announcements.

The missing mapping also limits strategic analysis. Fully absorbing the topology graph and orchestration layer is a different outcome from merely using asset discovery and firewall placement. The former could become a broad multi‑cloud control service; the latter primarily accelerates security deployment. The co‑founder’s statement confirms technology continuity but does not resolve this architectural boundary.

Future product documentation, migration guides, or customer case studies may clarify most questions. Until then, the accurate statement is: according to a co‑founder, Prosimo technology has been integrated into Palo Alto Networks products, but the scope and packaging remain publicly unverified.

Who controls multi‑cloud routing?

No single party controls the full path alone. The enterprise controls account ownership, business intent, application design, and the credentials it grants. A cross‑cloud controller can discover topology, translate policy, select paths, and alter native routing state. Cloud providers control APIs, transit services, private endpoints, backbones, and many fault domains; carriers and colocation providers control other transport segments; security services decide whether inspected traffic is allowed.

Prosimo sought the most strategically valuable middle position. It did not own the underlay, but it tried to own the graph and the policy translation that sit above it. The party that 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 treated as authoritative. Even when someone else owns the fibre, this is effective routing power.

After the acquisition, Palo Alto Networks owns the retained Prosimo technology and determines its integration, commercial packaging, and development direction. Cloud providers remain dominant within their own environments, and enterprises can revoke credentials or choose another architecture; but if topology, policies, and operational workflows are all anchored to the controller, exit costs can be high.

The answer, therefore, is layered: the enterprise authorises, the controller coordinates, cloud and carrier underlays transport, and the security platform enforces. Prosimo’s history illustrates that the ownership of the coordination layer can change even when cloud accounts and physical paths do not change hands.

Primary

Why post‑acquisition Prosimo still matters

Prosimo captured a real shift. Network operating units are moving from devices and prefixes toward applications, identity, service dependencies, and policy graphs. Cloud‑native APIs make network state programmable, and distributed software edges make enforcement points movable. A controller that sees multiple clouds can orchestrate actions that a single‑cloud console cannot.

The company also exposed the cost of coordination: a common control layer requires high‑privilege credentials, ongoing API maintenance, accurate discovery, semantic translation, telemetry, and operational discipline. It can reduce fragmented work while creating new centralisation points; the same system that simplifies routing can also amplify the blast radius of a single mistake.

Palo Alto Networks’ acquisition makes the control question starker. Network and security are converging around service insertion, workload discovery, and policy. A security vendor that understands topology and can alter routing does not merely inspect traffic that is handed to it; it can also help decide which traffic reaches the inspection point—and where inspection occurs.

Therefore, Prosimo should not be remembered only as a vanished independent brand, nor should it be treated as proof that some platform has solved the multi‑cloud problem. Its lasting contribution is defining the cross‑cloud graph as infrastructure. The remaining question is whether that graph, once inside a major security company, remains transparent, portable, and governable enough for customers to trust it.