Summary

  • Prosimo was founded in 2019 and raised at least $55 million in its 2021 Series A and 2022 Series B funding rounds; audited revenue data and details regarding valuation and purchase price remained undisclosed
  • AXI combined central policies, topology and analytics with distributed edges that discovered cloud resources, connected applications and steered security services without owning the physical backbone
  • The VM-Series integration announced in June 2024 was followed by Prosimo's transition to Palo Alto Networks around February 2025; an exact date, the price and today’s product mapping are unverified
  • Control remains distributed across enterprises, orchestration software, cloud providers and Palo Alto Networks; therefore, whether topology, credentials, policies and routing authority remain portable is critical

The brand vanished, the problem remained

By 2026, Prosimo can no longer be described as an active, independent provider. Public professional profiles show that the founders and several employees moved to Palo Alto Networks around February 2025. Prosimo's company profile is marked as acquired, and the former Chief Technology Officer Nehal Bhau later wrote that the technology had been integrated into Palo Alto Networks products. The evidence demonstrates a change of control and ongoing technical value. It does not prove the exact signing or closing date, the legal form or the price of the transaction.

This assessment comes first because it shifts the tense of every product statement. AXI, Network Transit, App Transit, Application-driven Intelligent Results and Nebula were documented Prosimo features during the independent phase. They should not be portrayed as products still sold separately unless Palo Alto Networks publishes an up‑to‑date product and support mapping. A historic architecture can persist as embedded code, shared service, module or internal engineering asset after an acquisition; those forms are not equivalent.

The disappearance of the brand does not make the underlying problem obsolete. Enterprises continue to distribute workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation sites, Software‑as‑a‑Service platforms and remote users. Each environment has its own routes, gateways, private endpoints, identity controls, security services, quotas and billing rules. An enterprise may own the accounts and still lack a unified view of how a request travels between environments. Prosimo's significance lies in the attempt to bring that view together in a shared control layer.

The acquisition therefore forms the narrative core, not just an epilogue. Prosimo built a cross‑cloud control layer that could discover resources, evaluate application context and steer traffic through security services. Palo Alto Networks first appeared as a technical partner whose VM‑Series firewalls could be inserted into those paths. Later, Palo Alto Networks acquired the technology. This shifted the boundary between routing orchestration and deep security inspection into a single cybersecurity platform.

In multi‑cloud routing, context decides

A routing table can answer whether a prefix is reachable via a particular next hop. On its own it cannot explain which application a user wanted to reach, whether the requester is trustworthy, whether an inspection service must see the traffic, whether a private endpoint is available, whether one cloud path costs more than another or whether a transaction fails after packet delivery. Multi‑cloud operations turn these questions into a shared control problem.

Prosimo's thesis was that routing decisions should rest on more than Layer‑3 reachability. The software tried to combine cloud inventory, network state, application identity, user identity, risk, performance and transaction telemetry. This broader context enabled policies that could connect a particular application, isolate a segment, select an ingress point or steer chosen traffic through a firewall. The value arose not from a new fibre‑optic path but from deciding how existing paths and services should be composed.

This distinction explains the term “application experience infrastructure”. It placed the application request at the centre, not the individual network entity. A VPC, a VNet, a subnet, a transit hub or a private link became a component of an end‑to‑end path rather than the ultimate management entity. The approach also pulled the product into several markets: cloud networking, application delivery, zero‑trust access, network assurance, cost optimisation and security‑service insertion.

The breadth created opportunity and ambiguity. A product that touches several teams can solve coordination problems that no single team owns. But it is harder to evaluate because network, security, cloud, application and finance teams define success differently. Prosimo had to show that a cross‑cloud model improved operations without creating another privileged layer whose failures would ripple across every environment.

What Prosimo was and what remains of it

Prosimo was a privately held cloud‑networking software company founded in 2019 and based in the San Francisco Bay Area. Ramesh Prabagaran was a co‑founder and Chief Executive Officer, while Nehal Bhau served as co‑founder and Chief Technology Officer during the independent phase. Public profiles also name Linus Aranha and Pradeep Aragonda in founding or senior engineering roles; their exact titles should remain tied to dated biographies.

The main platform was called Application eXperience Infrastructure, usually referred to as AXI. AXI used a central software layer for policies, topology, analytics and orchestration together with distributed AXI Edges in cloud regions, colocation sites or adjacent on‑premises infrastructure. Later Prosimo structured the offering as Full‑Stack Cloud Transit, with Network Transit and App Transit covering different classes of connectivity. AIR analysed telemetry and supplied operational insights; Nebula added a conversational interface in 2024.

Prosimo was not a cloud carrier. It did not own a global fibre backbone linking all regions. Paths could run over cloud‑provider backbones, the public internet, direct connections, colocation links and enterprise networks. Nor was Prosimo a firewall vendor in the same sense as Palo Alto Networks. Its role in the 2024 integration was resource discovery, segmentation and traffic steering; the VM‑Series handled deep security inspection.

After the acquisition, “technological continuity” is the most precise description. The later integration statement emphasised discovery of multi‑cloud resources and faster deployment of software firewalls for ingress, egress and east‑west inspection. That confirms that important Prosimo components persist. It does not confirm that the full historic AXI catalogue, commercial packaging or support model were carried forward unchanged.

The problem after SD‑WAN

The founding team brought experience in large‑scale networking, application delivery and cloud infrastructure. Prosimo also emerged from the wider founder and engineering circle around Viptela, the company that helped establish software‑defined WAN as an enterprise category. The next problem, however, lay elsewhere. SD‑WAN could simplify how branch offices reached networks and applications, but it did not create a unified operating model within and across multiple public clouds.

A multi‑cloud application can depend on a web endpoint in one environment, a database or managed service in another, an external identity provider, a private data‑centre link and security inspection at selected boundaries. Each dependency can appear as a different native entity. The network 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 from the request, not the branch. The critical question was how a user or workload should reach an application with acceptable security, performance, availability and cost. That shifted the entity of the routing decision from the destination prefix alone to a transaction with identity and application context. At the same time, the platform had to collect and maintain far more information than a conventional router.

The market entry came at a favourable moment. AWS, Azure and Google Cloud were expanding native transit and private‑connectivity services. Enterprises could build sophisticated networks inside one provider, but APIs, entities and policy models remained provider‑specific. Prosimo's opportunity was to coordinate those services rather than forcing each customer to replace them with a separate proprietary backbone.

From founding in 2019 to public launch in 2021

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

The launch thrust the company into a crowded and still‑unsettled segment. Cloud providers were making their own networking services easier to consume. SD‑WAN and SASE vendors were extending policies into cloud environments. Application‑delivery vendors could optimise requests, network‑security companies could inspect them. Prosimo's argument rested on joining those functions in a cloud‑native architecture without claiming to replace every surrounding system.

The funding created room for integrations, software edges, analytics, a sales organisation and partner relationships. It demonstrated neither product‑market fit nor revenue scale nor durable differentiation. The provided evidence contains no audited revenue data nor figures for annual recurring revenue, customer count or valuation. The funding history shows investor confidence in a thesis, not a full account of operating performance.

In 2022 Prosimo closed a Series B described as oversubscribed, raising $30 million. The two clearly identified rounds total at least $55 million in verified funding. Some databases may show a higher figure if they double‑count announcements or related records; such totals should not be used without untangling the underlying events.

AXI placed policies above the clouds and execution close to the workloads

The AXI architecture split responsibilities between a central control and analytics layer and distributed software edges. The central layer managed application and network policies, discovered resources, merged the topology, integrated identity, analysed telemetry and orchestrated changes. AXI Edges were placed close to workloads or users so that policies could be enforced without forcing every path through a distant physical hub.

The separation resembles other software‑defined systems, but the entities were cloud‑specific and application‑centric. The controller needed access to cloud accounts and APIs, while the edge required connectivity to native transit services, workload networks, private endpoints or external paths. The platform's authority came from combining both views: global policies above the clouds and local execution close to the relevant traffic.

The architecture also created a practical deployment boundary. Each edge consumed cloud resources, needed a high‑availability design and had to be updated, monitored and secured. The control layer needed credentials with sufficient rights to discover resources and alter network state. The customer gained a unified workflow but added a management system whose availability and correctness were critical for production‑application reachability.

Prosimo sometimes used the term “autonomous cloud networking”. Automation, recommendations and API‑driven orchestration are documented. What is not documented is a network that operates independently of human policies, cloud‑provider services or the underlying transport. Operators continued to define policies, authorise access, handle exceptions and bear responsibility for the outcome.

An AXI Edge was a placement decision, not an ordinary appliance

An AXI Edge could be deployed in a cloud VPC or VNet, in a colocation site or in adjacent infrastructure. The technical AWS documentation showed an edge VPC connected to workload VPCs via Transit Gateway, with optional firewall chaining and access from remote users or on‑premises locations. The design placed Prosimo's enforcement point inside the cloud topology, not at a remote enterprise perimeter.

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

Distributed placement increased the number of fault domains that had to be mastered. Capacity, software versions, cloud‑zone design, route convergence and access rights could differ by region. High availability meant more than two instances: the controller, cloud route tables, security services and return paths all had to reflect a consistent failover state.

The edge was therefore part of a broader operating system. Its value depended on resource discovery, topology, policies and analytics staying consistent with the surrounding cloud environment. Anyone who sees it as a standalone virtual appliance misses the architecture that Prosimo sought to sell.

The underlay network remained in others’ hands

Prosimo coordinated transport but neither owned the underlay network nor the physical path. An application path could use the AWS backbone or another cloud provider's backbone, the public internet, Direct Connect or ExpressRoute, colocation, a carrier link or an enterprise network. The platform could choose among available options and orchestrate them; it could not eliminate the latency, packet loss, failure domains or pricing models of those providers.

This boundary is critical for performance claims. A controller can select an observably better path or bring ingress closer to the user. It cannot guarantee that a carrier will not fail, that a cloud region will remain up or that an external dependency will respond quickly. Application experience also includes DNS, server processing, storage, browser behaviour and third‑party services outside the direct control of the network controller.

The absence of a proprietary backbone was not only a weakness. Prosimo could use infrastructure that enterprises already paid for and benefit from the cloud providers’ investments. It could reach regions without its own fibre build‑out and co‑ordinate native systems such as AWS Cloud WAN. The price was dependence on API stability, service quotas, commercial terms and provider‑specific semantics.

The platform's claim therefore concerned operational control, not physical ownership. It aimed to unify heterogeneous underlays into a managed system while preserving their native advantages. Whether the abstraction reduced lock‑in or merely displaced it depended on the portability of policies, topology and edge deployment.

Network Transit governed reachability between network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites and segments. It co‑ordinated native cloud transit and routing entities so that teams could build connectivity through a single workflow instead of configuring each provider separately. The product met the conventional networking requirement: a source prefix or segment must be able to reach a destination over an allowed path.

This did not claim that cloud differences disappear. AWS, Azure and Google Cloud expose different entities, quotas and routing behaviours. Overlapping address spaces, asymmetric paths, private endpoints and provider‑specific boundaries still required engineering. Prosimo could normalise common operations and show relationships; the underlying systems retained their own constraints.

Network Transit also handled segmentation. Routing domains and policies could separate environments or limit reachability. The controller had to understand where a segment existed across clouds and how native entities enforced the boundary. A policy expressed once could still trigger several provider‑specific changes.

The benefit was a single surface for policy declaration. The risk lay in translation between the shared model and the native cloud configurations. If the shared policy and the cloud configuration diverged, the enterprise might believe a segment was protected while the provider state said otherwise. Reconciliation, audit and clear error reporting were therefore as important as the initial provisioning workflow.

App Transit made the application the entity of the routing decision

App Transit extended the model beyond subnets. It could incorporate application domain, identity, request type, transaction state, risk and performance into the decision about how a user or workload reached a service. This was Prosimo's clearest attempt to differentiate the platform from a conventional cloud router.

The application view was useful because modern services are not always represented cleanly by fixed addresses. Managed services, SaaS endpoints and distributed components can change while the application identity remains meaningful. A policy that references a service or a user can be more persistent than a rule based only on addresses and ports.

The model required precise mapping. The controller had to know which domains and endpoints belonged to an application, which dependencies were needed and which identity‑provider assertions could be trusted. Stale mapping could direct a request over the wrong path or apply the wrong security rule. The application abstraction did not eliminate the need to understand network state; it added another semantic layer on top.

The combination of Network Transit and App Transit acknowledged that both worlds coexist in enterprises. Legacy systems, private subnets and IP‑based controls persist while newer applications rely on domains, identity and managed services. Full‑Stack Cloud Transit was the product name for operating these models together, not for replacing one with the other.

Identity extended the routing decision and the trust boundary

Application‑aware access required identity integration. The platform could use user or workload context to decide whether and how a connection should be built. This supported a zero‑trust policy where location alone did not constitute sufficient proof of authority.

Identity added precision and introduced another dependency. The routing or application policy now depended on the identity provider, its assertions, session state and group data. A network path could fail because authentication was unavailable or an attribute changed, even though routers and edges were working properly. Troubleshooting had to cross the boundary between network and identity operations.

The controller also became a concentration point for sensitive context. It could store topology, application relationships, user attributes, risk signals and policy results. This dataset improved diagnosis and optimisation but enlarged the impact of unauthorised access. Least privilege, retention, audit and separation of duties were therefore architectural requirements, not administrative afterthoughts.

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

Resource discovery created the graph on which every later decision depended

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

The collection was strategically important because cloud landscapes change outside central networking workflows. Application teams can create accounts, networks, endpoints and managed services through their own automation. Manually maintained diagrams become stale. An API‑based inventory can produce a more current graph, but its completeness depends on account coverage, permissions, parser logic and provider APIs.

The graph was not merely documentation. It was the data structure from which routing, segmentation, service insertion and optimisation were computed. If a resource or dependency was missing, all the inferences above it could be wrong. The topology therefore needed provenance: when it was collected, the source account, covered regions and failed queries.

The graph also helps explain the acquisition. Palo Alto Networks can add more security value if it knows where workloads and traffic paths lie. A system that discovers cloud resources and can change routes shortens the journey from buying a software firewall to placing it correctly. Bhau later explicitly emphasised resource discovery and accelerated software‑firewall deployment.

AIR derived operational recommendations from edge telemetry

Application‑driven Intelligent Results, abbreviated AIR, analysed telemetry from the AXI Edges. The AWS documentation described insights into round‑trip time, processing time, application response time, transaction type, risk and policy outcome. The platform could correlate user, network and application data rather than presenting isolated device counters.

This correlation addressed a familiar operational problem. A slow transaction can originate on the user path, at the edge, in the cloud backbone, in the security service or in the application itself. A cross‑stack view can narrow the search faster than separate consoles and support recommendations about path, placement, risk or cost.

The quality of a recommendation depended on telemetry coverage and the interpretation model. An edge saw only traffic that passed through it. External application dependencies and provider‑internal states could remain invisible. A recommendation could suggest direction without proving cause.

Telemetry also had governance value. Historical observations could explain why a route or policy had changed. They could also reveal sensitive information about application usage and user behaviour. Public material does not fully describe retention and data governance after the acquisition; these points remain part of customer due diligence.

AWS provided the clearest documented implementation

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

AWS Cloud WAN was particularly significant. It supplied a cloud‑native backbone and a segmentation service that Prosimo could orchestrate rather than replace. This architecture showed the co‑operative model: AWS owned the native network and global infrastructure; Prosimo provided cross‑cloud policies, application context, edge software and analytics.

The Marketplace workflow simplified the initial deployment step by packaging the AXI Edge through an approved channel. The later work on account permissions, routing design, high availability, capacity and operations remained. Day‑zero automation can lower installation effort without eliminating the long‑term control problem.

A named Flexport reference supported the AWS Cloud WAN use case in marketing material. It shows that an enterprise customer publicly endorsed the architecture, but it is not an independent audit of scale, savings or availability. Customer testimonials should therefore serve as adoption examples, not as general proof of performance.

Azure and Google Cloud completed the multi‑cloud offering

Prosimo also supported Microsoft Azure and Google Cloud. Product material described orchestration of Azure Virtual WAN and Google Cloud network and private‑service entities. The goal was a shared operating model while each provider’s native network remained.

Support for these platforms does not prove identical functionality. Cloud APIs mature at different speeds, and comparable product names can hide different semantics. Routes, segments, private endpoints and service insertion could require provider‑specific treatment. The available evidence does not permit a full feature‑comparison matrix for all regions and releases.

Multi‑cloud abstraction is therefore best understood as a translation system. It can standardise common policies and workflows but must preserve the details that affect security, cost and failure. A platform becomes risky when the surface looks uniform and implementation differences are hidden from operators.

The same applies after the acquisition. Palo Alto Networks can use the shared graph to place security controls across multiple clouds, but cloud providers still control the native entities that carry the path. Ownership of the orchestration layer does not create ownership of the cloud underlay.

The product evolved from connectivity to a lifecycle model

By 2023 Prosimo was describing workflows for design, build, troubleshooting and operation of multi‑cloud networks. The product went beyond setting up individual tunnels or gateways. Resource discovery informed design; orchestration created connectivity; maps and telemetry aided troubleshooting; policies and historical states supported ongoing management.

The lifecycle perspective widened the set of potential buyers. Network engineers could use topology and path analysis; cloud platform teams could on‑board accounts and services; security teams could verify segmentation and inspection; migration teams could plan changes; FinOps teams could examine routing and egress impacts. The platform’s value rose when several groups accessed the same dataset.

A shared dataset can also trigger governance conflict. A central platform can show that a cloud team’s native configuration deviates from enterprise policy. The organisation must decide which system is authoritative and who authorises remediation. Software alone does not resolve this institutional question.

The lifecycle model also raised switching costs. When a controller manages the asset graph, policies, telemetry, edge placements and automation integrations, replacing it requires more than swapping a connection. The customer must export or reconstruct the operating model. Prosimo promised to reduce cloud fragmentation while also creating the possibility of controller dependence.

Segmentation ranged from network reachability to application policy

Prosimo described segmentation from Layer 3 to Layer 7. At the network level, routing domains and segments determined which subnets or sites could communicate. At higher layers, application identity, user context and transaction characteristics could refine the rule.

The layered model could narrow the gap between network zone and application policy. A business service could be allowed while broad subnet‑to‑subnet reachability remained blocked. Conversely, a reachable network path could be denied if identity or application context did not match.

This did not make Prosimo a full next‑generation firewall. The 2024 integration with Palo Alto Networks divided tasks: Prosimo orchestrated routes, segmentation and service insertion; the VM‑Series handled deep inspection. The distinction matters because policy control and security enforcement fail differently.

A segment is effective only if all relevant paths are represented. An unknown route, native cloud exception or failed service insertion can bypass the intended control. Verifying security therefore required comparing the declared policy with the actual state at the cloud provider and observed traffic; the controller's configuration view alone was not sufficient and required independent verification.

Service insertion connected routing control with the economics of firewalls

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

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

This made routing orchestration commercially valuable to a security vendor. A software firewall cannot protect traffic that never reaches it. Resource discovery, placement and routing changes reduce the effort needed to insert purchased security capacity into a live path. That is a plausible strategic reason for Palo Alto Networks to acquire Prosimo's technology.

At the same time, the blast radius of the controller grew. A faulty policy could bypass inspection, create loops, cause asymmetric routing or take down an application. Health checks, staged changes, simulation, audit and rollback are necessary because a service‑insertion failure is simultaneously a network and a security event.

The 2024 partnership must not be retroactively treated as an acquisition

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

The partnership nonetheless built a bridge. Prosimo could demonstrate how its routing and policy system eased VM‑Series deployment across clouds. Palo Alto Networks could evaluate the technology in a real‑world integration before the company later changed hands. Public evidence does not describe the acquisition process; asserting that the partnership was formally designed as a pre‑acquisition step would be speculation.

By early 2025, the profiles of founders and employees had shifted. The company page later carried an acquisition notice. In late 2025 Bhau stated that the technology had been fully integrated into Palo Alto Networks products. Together, these records support the acquisition conclusion while leaving the legal mechanisms open.

The sequence matters for editorial accuracy and for customers. A partnership means two vendors, two support structures and a defined integration boundary. An acquisition can shift roadmaps, data, contracts and authority into one company. The transition changes more than the brand, even if the technical path initially looks similar.

Nebula made the topology graph accessible through a conversational interface

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

The valuable asset was not the language interface itself but the structured cross‑cloud context beneath it. A generic model cannot diagnose a private route or segment it cannot see. Nebula could use the asset inventory, topology, policies and observations that Prosimo already collected. This made the earlier investment in a shared graph relevant for AIOps.

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

Prosimo cited possible improvements such as 60 to 80 percent lower Mean Time to Resolution and more than 60 percent lower cloud‑networking costs. These numbers were vendor claims in a product announcement. The provided evidence contains neither an independent methodology nor a customer baseline that proves general validity. They can be cited as benefits proposed by Prosimo, not as measured market fact.

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

The same 2024 announcement portrayed Prosimo's architecture as useful for AI workloads. Distributed AI systems can require private data access, cross‑cloud and data‑centre links, compliance controls and routing that accounts for application behaviour. These requirements matched the existing asset, policy and path model.

The labelling did not change the underlay network. Prosimo still depended on cloud networks, carriers and customer infrastructure. It supplied neither GPU compute nor model‑development software. Its possible role was the connectivity and security layer for distributed data and services.

The AI positioning was strategically plausible because the value of a cross‑cloud topology rises when data and services become more distributed. It was also a marketing category introduced shortly before the end of independent operations. The records do not prove separate AI‑product revenue, named production deployments or audited workload results.

The lasting finding is that multi‑cloud telemetry can become a foundation for machine‑assisted operations. The product question today is whether Palo Alto Networks retained that context and how it exposes the function. The publicly available information as of the cut‑off date does not provide a complete answer.

The business model sold software for infrastructure Prosimo did not own

Prosimo's independent business was a software‑subscription and services model, not a carrier model. Customers deployed AXI Edges in their own environments and connected cloud accounts to the control layer. Revenue probably came from licences or subscriptions, support, professional services and channel‑partner activity; specific pricing and contract metrics were not disclosed in the provided evidence.

The model could scale without its own fibre. A software platform co‑ordinated many cloud regions and customer environments. However, no gross‑margin conclusions can be drawn from the architecture. Engineering support for provider APIs, the edge lifecycle, security integrations and enterprise deployment can be expensive, while the cloud resources consumed by the edge may be paid by the customer rather than the vendor.

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

The breadth of the offering may have increased sales complexity. Network, security, cloud and application teams could benefit, but budget ownership may have been unclear. The product needed a budget holder who would fund a shared control layer rather than funding separate operations for each cloud and each team.

Partners, customers and investors played different roles

Amazon Web Services was simultaneously an underlay provider and a go‑to‑market partner. Azure and Google Cloud were supported environments. Identity providers supplied authentication context, while firewall vendors handled inspection. Colocation and carrier services could host or connect edges. Channel partners could design and run deployments.

Flexport appeared as a named customer reference in the AWS Cloud WAN material. The reference shows enterprise interest in the architecture but does not disclose full scale, duration or commercial value of the deployment. It must not serve as a proxy for the entire customer base.

General Catalyst led the Series A and was involved in governance through its investor role. Investors associated with WRVI or Celesta appeared in company material; later Prosimo communications cited additional prominent participation, including a designation linked to BlackRock, whose precise investment vehicle remained open in the research. These records show a well‑connected funding base, not a full cap table.

Palo Alto Networks assumed the most consequential position: the 2024 security partner became the buyer by early 2025. The sequence shows how an ecosystem dependency becomes a control relationship when one entity buys the software layer that co‑ordinates the path to its product.

At least $55 million was raised; the economic outcome of the company sale remains unknown

The verified funding consists of a $25 million Series A in April 2021 and a $30 million Series B in 2022. The total stands at a minimum of $55 million. The provided evidence contains neither an audited cap table nor figures for valuation, debt‑financing structure or later funding rounds.

The acquisition price was neither published nor independently confirmed. Without a price, the outcome cannot responsibly be categorised as a strategic premium, a modest technology purchase, an acqui‑hire or a distressed sale. The continuing product integration proves technological value but does not reveal investor or founder returns.

Palo Alto Networks’ revenue and market position after the acquisition must not be attributed to Prosimo. Once the start‑up was no longer separately observable, there was no standalone revenue, profit or customer segment to analyse. A larger owner can make the technology more widely available while also making its standalone economic significance less visible.

The absence of a formal acquisition announcement is itself relevant. Customers, employees and researchers normally use such announcements to determine timing, support and strategic rationale. Here the status must be reconstructed from professional profiles, a company‑page designation and a later founder statement. That suffices to correct the company’s status, not to invent transaction details.

Competition came from platforms, clouds and internal development

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

A specialised controller could offer a topology and policy model across providers. A cloud‑native design could reduce third‑party dependency and be tightly optimised for one provider. A carrier‑backed service could supply physical transport. A SASE or security platform could combine connectivity and enforcement. Internal development could preserve control but increase staffing and integration effort.

Prosimo's differentiation lay in the combination of application and network transit, distributed edges, cloud‑native orchestration, topology, telemetry and service insertion. That same breadth made comparisons difficult. Buyers had to test the specific cloud services, routes, identity systems and security patterns they intended to use, rather than compare category labels.

The acquisition changes the competitive frame. Prosimo no longer has to succeed as a standalone vendor, but its technology must prove its value inside Palo Alto Networks. The critical question is whether integrated resource discovery and routing orchestration improve the deployment of Palo Alto Networks security products, and whether customers accept the resulting platform dependence.

Native cloud services were both foundation and substitute

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN and Google Cloud network services offered powerful native options to enterprises. Prosimo depended on these services while also competing with their direct use by customers.

The relationship created a moving boundary. When a cloud provider added global routing, segmentation, private service access or centralised policy, some third‑party functions became easier to replicate natively. At the same time, each new native service added another entity that a cross‑cloud controller could discover and co‑ordinate. Cloud‑provider advances could reduce part of Prosimo's value while increasing the need to translate between providers.

The deciding factor was organisational as well as technical. A single‑cloud enterprise with strong internal engineering might prefer native tools. A multi‑cloud enterprise with fragmented teams might prefer a shared control plane. A regulated organisation might prefer an independent control and evidence layer while also fearing privileged credentials and data concentration.

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

Failures could occur in the controller, the edge, cloud APIs, the identity system or the underlay

Prosimo's distributed architecture reduced dependence on a single traffic hub but created several interacting fault domains. The central service could fail or contain stale policies. An edge could fail or become isolated. A cloud API could reject part of a change. The identity provider could go down. The underlay network could lose capacity or take an unexpected path. An inserted firewall could exhaust resources.

Partial failures are especially difficult. One provider may accept a routing change while another rejects it. Then the controller’s intended state diverges from the actual cloud state. Traffic can become asymmetric or bypass inspection. A reliable system needs reconciliation, idempotent operations, staged changes, clearly flagged error states and rollback that accounts for each provider’s behaviour.

Public evidence describes availability and optimisation at a high level but contains no independent fault‑injection study, full incident history or generalisable service‑level results. Resilience claims should therefore remain tied to the documented architecture or to named customer experiences.

The acquisition introduces another fault domain: product continuity. Customers need to know which console, API, edge image, policy model and support organisation replace the historic Prosimo system. A technically successful code integration can still create migration risk if commercial and operational boundaries are unclear.

Cloud credentials made the controller part of the critical management plane

Asset discovery and orchestration required access to cloud accounts. A read‑only inventory could work with limited rights; changes to routes, segments and service insertion needed broader permissions. The controller thus sat in the privileged management plane, even though it did not own the workloads.

Credential compromise could expose the topology or allow wide‑ranging changes. A software bug or operator mistake could propagate policies across several clouds. The risk grew with the platform’s utility: the more accounts and services it could manage, the larger the potential blast radius.

Enterprises needed least‑privilege roles, separate credentials for discovery and change, multi‑party approval, full auditing, rotation, emergency revocation and a recovery path that did not depend solely on the same controller. Public material contains no complete independent security assessment; these points therefore remain necessary deployment controls, not verified product guarantees.

The telemetry graph was equally sensitive. It could reveal application names, network structure, policies, user relationships, route status and cost patterns. Post‑acquisition governance should clarify where the data is stored, which Palo Alto Networks products can access it and how existing customer permissions were migrated. The public record does not answer these questions.

The acquisition shifted a cloud‑neutral layer into a security platform

Prosimo's independent position allowed it to present itself as a shared layer above clouds and security services. With Palo Alto Networks as owner, the incentives changed. The acquired technology could make VM‑Series and other Palo Alto Networks products easier to deploy. That can create a better integrated experience and raise questions about support for third‑party inspection services.

Ownership does not prove that neutrality has disappeared. The records contain neither a current partner matrix nor a current product architecture. They do, however, change the question customers should ask. What must be examined is whether the routing controller remains open to multiple security vendors, whether policies and telemetry are exportable and whether optimisation favours the owner’s portfolio.

The integration statement emphasised ingress, egress and east‑west inspection. This suggests that Prosimo's topology and orchestration became part of a system for delivering security functions. It does not prove that the historic App Transit capability, user access, cost optimisation or all cloud‑networking workflows persist as separate features.

This is a common infrastructure pattern. A start‑up abstracts a difficult coordination problem; a larger platform vendor buys the abstraction because it increases use and control of its core product. The buyer gains a faster deployment path. The customer may gain integration and lose some vendor independence.

Today’s product mapping is the largest information gap

The publicly available information confirms acquisition and integration but contains no complete mapping of AXI, Network Transit, App Transit, AIR and Nebula to current Palo Alto Networks products or SKUs. Legacy support deadlines, migration procedures and a feature‑comparison for product continuity are also absent.

This gap prevents a product assessment in the present. Historical descriptions explain what Prosimo built and why it mattered. They do not say which features are available, licensed or supported today. Current deployment recommendations must rest on current Palo Alto Networks documentation, not on archived Prosimo announcements.

The missing mapping also limits strategy analysis. A full adoption of the topology graph and orchestration layer would differ from a selective use of asset discovery and firewall placement. One would produce a broad multi‑cloud control service; the other would primarily use Prosimo to accelerate security‑feature deployment. The co‑founder’s statement supports the continuation of the technology but leaves this architectural boundary open.

A future product document, a migration guide or a customer case study could remove much of the uncertainty. Until then, the precise formulation is: according to a co‑founder’s statement, Prosimo's technology was integrated into Palo Alto Networks products; scope and product packaging are unverified.

Who controls multi‑cloud routing?

No single party controls the entire path. The enterprise owns the accounts, defines business objectives and application design, and issues credentials. A cross‑cloud controller can capture the topology, translate policies, select paths and change native route state. Cloud providers control the APIs, transit services, private endpoints, the backbone and many failure domains. Carriers and colocation providers control other parts of the transport. Security services decide whether inspected traffic is allowed.

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

After the acquisition, Palo Alto Networks owns the residual Prosimo technology and determines how it is integrated, packaged and evolved. Cloud providers remain sovereign in their environments; the enterprise can revoke credentials or choose a different architecture. Exit can nevertheless be expensive if the topology, policies and operational workflows have become dependent on the controller.

The answer is therefore layered and not absolute: the enterprise authorises; the controller coordinates; the cloud and carrier underlays transport; the security platform enforces. Prosimo's story shows that ownership of the coordinating layer can change without a cloud account or physical path changing hands.

Core source list

Why Prosimo remains relevant after the acquisition

Prosimo captured a real infrastructure shift. The entity of network operations is moving from device and prefix towards application, identity, service dependency and policy graph. Cloud‑native APIs make network state programmable, distributed software edges make the enforcement point movable. A controller with visibility across multiple clouds can coordinate actions that no single cloud console can accomplish alone.

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

The acquisition by Palo Alto Networks makes the control question more visible. Network and security converge at service insertion, workload discovery and policy control. A security vendor that knows the topology and can change routes does not merely inspect traffic presented to it; it can help determine which traffic reaches inspection and where.

Prosimo should therefore be seen neither as a failed standalone brand nor as proof that a single platform solved the multi‑cloud problem. Its lasting contribution was defining the cross‑cloud graph as infrastructure. The remaining question is whether that graph, inside a larger security company, stays transparent, portable and governable enough to earn customer trust.