Summary

  • Prosimo was founded in 2019 and raised at least $55 million across a Series A in 2021 and Series B in 2022; it did not disclose audited revenue, valuation, or acquisition price.
  • AXI combined intent, topology, centralised analytics, and distributed edges that discover cloud assets, connect applications, and insert security services, without owning the physical backbone.
  • The VM-Series integration announced in June 2024 preceded Prosimo’s move to Palo Alto Networks around February 2025; no source specifies the acquisition date, price, or current product map.
  • Control remains distributed among enterprises, orchestration software, cloud providers, and Palo Alto Networks; therefore the portability of topology, data, policies, and routing authority becomes the critical test for customers.

The company disappeared before the problem did

Prosimo cannot accurately be presented as an active independent vendor in 2026. Public professional profiles show its founders and a number of employees moving to Palo Alto Networks around February 2025. The company identity also carries an ‘acquired’ tag, and former CTO Nehal Bhau later wrote that its technology had been integrated into Palo Alto Networks products. The evidence proves a change of control and continued technical value, but it does not prove the exact signing or closing date, nor the legal form or price of the deal.

This correction must be placed at the start because it changes the tense of every product claim. AXI, Network Transit, App Transit, Application-driven Intelligent Results, and Nebula were documented capabilities of Prosimo during its independent period. They should not be presented as current products sold separately unless Palo Alto Networks publishes a contemporary product and support map. The historic architecture may survive after acquisition as integrated code, a shared service, a software module, or an internal engineering asset; these outcomes are not equivalent.

The brand's disappearance does not make the underlying problem obsolete. Enterprises still distribute workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, co-location sites, SaaS platforms, and remote users. Each environment has its own paths, gateways, endpoints, identity controls, security services, quotas, and billing rules. The enterprise may own the accounts, yet it lacks a unified view of how demand moves between them. Prosimo’s significance lay in its attempt to own that view.

Thus the acquisition forms the backbone of the story, not its conclusion. Prosimo built a cross-cloud control layer that could discover assets, interpret application context, and steer traffic through security services. Palo Alto Networks first appeared as a technology partner whose VM-Series firewalls could be inserted into those paths, then became the owner of the technology. The boundary between routing orchestration and deep inspection moved inside a single cyber security platform.

Multi-cloud routing is a fight for context

A routing table can answer whether a particular prefix is reachable via a specific next hop. But it alone does not explain which application the user wanted to reach, whether the requester is trusted, whether an inspection service should see the traffic, whether a private endpoint is available, whether one cloud path is more expensive than another, or whether the transaction fails after the packet arrives. Multi-cloud operations turn these questions into a shared control problem.

Prosimo’s thesis was that routing authority should rest on information beyond Layer 3 reachability. Its software aimed to assemble cloud inventory, network state, application identity, user identity, risk, performance, and transaction measurement. This broader context enabled policies such as connecting a specific application, isolating a segment, choosing an entry point, or steering selected traffic through a firewall. The value came not from inventing a new fibre path, but from deciding how to compose existing paths and services.

This difference explains the company’s use of the phrase ‘application experience infrastructure’. It placed the application request above the individual network component. A VPC, VNet, subnet, transit hub, or private link became a component in an end-to-end path, not the ultimate entity of management. The approach also pushed the product into several markets at once: cloud networking, application delivery, zero-trust access, network assurance, cost optimisation, and security service insertion.

The breadth created opportunity and ambiguity at the same time. A product that touches multiple teams can solve coordination failures that no single team owns. But it also becomes hard to evaluate, because network, security, cloud, application, and finance teams use different definitions of success. Prosimo had to prove that a single cross-cloud model improved operations without turning into another privileged layer whose mistakes affect every environment.

What Prosimo was and what remains of it

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

The main platform was Application eXperience Infrastructure, abbreviated as AXI. AXI used a centralised software layer for intent, topology, analytics, and orchestration, with distributed AXI Edge instances in cloud regions, co-location environments, or adjacent on-premises infrastructure. The company later organised the offering under the name Full-Stack Cloud Transit, whereby Network Transit and App Transit addressed different categories of connectivity. AIR analysed measurements and delivered operational insights, while Nebula added a conversational interface in 2024.

Prosimo was not a cloud carrier. It did not own a global fibre backbone connecting every region. The path could traverse cloud provider backbones, the public internet, direct circuits, co-location cross-connects, or enterprise networks. Nor was it a firewall vendor in the same sense as Palo Alto Networks. Its role in the 2024 integration was discovery, segmentation, and routing, while the VM-Series performed the deep security inspection.

After the acquisition, the safest description is ‘technology lineage’. The later statement about integration highlights multi-cloud asset discovery and accelerating software firewall deployment to inspect ingress, egress, and east-west traffic. This is evidence that significant Prosimo components survive, not that the complete historic AXI catalogue, its commercial packaging, or customer support model continues unchanged.

The problem that came after SD-WAN

The founding team came from experience in wide-area networking, application delivery, and cloud infrastructure. Prosimo also emerged from a broader founder and engineer ecosystem associated with Viptela, the company that helped establish software-defined WAN as an enterprise category. But the next problem was different. SD-WAN simplifies branch access to networks and applications, but it does not create a single operational model inside and 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 outside both, a private connection to a data centre, and security inspection at chosen boundaries. Each dependency can be represented by a different native entity. The network team may see prefixes and transit hubs, the cloud team sees accounts and resource entities, the application owner sees domains and transactions, and the security team sees zones and inspection policy.

Prosimo started from the demand, not the branch. The question was how a user or workload should reach an application within an acceptable level of security, performance, availability, and cost. This reframing changed the routing subject from a destination prefix alone to a transaction carrying identity and application context. It also compelled the platform to collect and maintain far more information than a traditional router needs.

The timing was favourable. AWS, Azure, and Google Cloud were expanding native transit and private connectivity services. Enterprises could build advanced networks inside each provider, but the APIs, entities, and policy models remained provider-specific. Prosimo’s opportunity was to orchestrate those services, rather than forcing every customer to replace them with a separate private backbone.

From founding in 2019 to public launch in 2021

Prosimo was founded in 2019, but did not announce its public launch until 6 April 2021. General Catalyst led a $25 million Series A round at launch. The investor described the opportunity from the angle of delivering application experience across clouds, consistent with the founders’ attempt to define a category beyond traditional branch connectivity.

The launch placed the company in a crowded and boundary-unstable market. Cloud providers were making their own networking services easier to consume. SD-WAN and SASE vendors were extending policies into cloud environments. Application delivery companies could optimise requests, while network security companies could inspect them. Prosimo’s argument rested on combining these functions in a cloud-native architecture without claiming it would replace every perimeter system.

The funding gave the company room to build integrations, software edges, analytics, commercial packaging, and partner relationships. But it did not prove product-market fit, revenue scale, or sustainable differentiation. The evidence provided does not include audited revenue, ARR, customer count, or valuation. The funding record shows investor commitment to a thesis, not a complete picture of operational performance.

In 2022, Prosimo completed a $30 million Series B round that was described as oversubscribed. Adding the two clearly identified rounds yields a documented minimum of $55 million. Some databases may show a larger figure when they duplicate announcements or related records; those aggregates should not be used without reconciling the underlying events.

AXI placed policy above the clouds and enforcement near workloads

The AXI architecture divided work between a centralised control and analytics layer and distributed software edges. The central layer maintained application and network intent, discovered assets, composed topology, associated identity, analysed measurements, and orchestrated changes. AXI Edges were deployed close to workloads or users, so that policy was enforced without forcing every path back to a distant physical hub.

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

The architecture also created a practical boundary for deployment. Each edge consumed cloud resources, needed a high-availability design, and had to be updated, monitored, and secured. The control layer required credentials with sufficient privilege to discover assets and change network state. The enterprise gained a shared workflow, but it added a new management system whose availability and correctness became critical for production access.

Prosimo sometimes used the language of ‘self-driving cloud networking’. The evidence supports automation, recommendations, and API-driven orchestration, not a network operating independently of human policy, cloud provider services, or underlying transport. Operators still defined intent, approved access, handled exceptions, and bore responsibility for the outcome.

AXI Edge was a location decision, not a generic virtual appliance

AXI Edge could be deployed in a cloud VPC or VNet, a co-location environment, or an adjacent infrastructure. An AWS technical walkthrough showed the edge VPC connected to workload networks via Transit Gateway, with the ability to chain a firewall and access from remote users or on-premises sites. The design placed the Prosimo enforcement point inside the cloud topology, not at a distant enterprise perimeter.

Location affected more than latency. It determined where traffic entered the policy domain, which cloud backbone or internet path it used, where encryption and inspection occurred, and which measurements the platform could collect. A poorly placed edge could cause hairpinning or cost, while a well-placed edge shortened the path or kept traffic close to the workload.

Distributed deployment increased the number of failure domains to manage. Capacity, software versions, cloud region design, path proximity, and access permissions could vary by region. High availability required more than running two copies; the controller, routing tables, security services, and return paths had to agree on the failover state.

The edge was therefore part of a wider operating system. Its value depended on asset discovery, topology, policy, and analytics staying consistent with the surrounding cloud environment. Treating it as an isolated virtual appliance misses the architecture that Prosimo tried to sell.

The underlay was always owned by someone else

Prosimo orchestrated transport, but it did not own the physical path. The application path could use an AWS backbone or another cloud provider’s, a public internet connection, Direct Connect or ExpressRoute, a co-location service, a carrier circuit, or an enterprise network. The platform could select and coordinate among available options, but it could not remove the latency, packet loss, failure domains, or pricing rules those entities create.

This boundary is important when evaluating performance claims. The controller might choose a better observed path or move the entry point closer to the user. But it cannot guarantee that a carrier won’t fail, that a cloud region will stay available, or that an external dependency will respond quickly. Application experience also includes DNS, server processing, storage, browser behaviour, and third-party services beyond the controller’s full control.

The absence of a private backbone was not only a weakness. It allowed Prosimo to use infrastructure that enterprises had already bought and to leverage cloud provider investment. It could reach regions without laying fibre and orchestrate native systems like AWS Cloud WAN. The trade-off was dependence on the stability of APIs, service quotas, commercial terms, and each provider’s semantics.

The platform’s claim was therefore about operational control, not physical ownership. It tried to make heterogeneous underlays work as a single managed system while keeping their native advantages. Whether that abstraction reduces lock-in or merely relocates it depends on the portability of policy, topology, and edge deployment.

Network Transit addressed reachability between network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites, and segments. It orchestrated native transit services and cloud routes so that teams built connectivity through a shared workflow instead of configuring each provider separately. It served the traditional network requirement: a source prefix or segment must reach a destination via an allowed path.

This was not a claim that cloud differences had vanished. AWS, Azure, and Google Cloud present different entities, quotas, and routing behaviour. Overlapping address spaces, asymmetric paths, private endpoints, and provider-specific service limits still required engineering. Prosimo could standardise common operations and show relationships, but the underlying systems retained their constraints.

Network Transit also carried segmentation. Routing domains and policies could separate environments or restrict access. The controller had to understand where a segment existed across clouds and how native entities enforced the boundary. A policy stated once might translate into several provider-specific changes.

The benefit was a unified intent surface. The risk was translation. If the shared policy drifted from the cloud reality, the enterprise might believe a segment was protected while the provider state said otherwise. That made reconciliation, audit, and explicit failure reporting as important as the initial provisioning flow.

App Transit made the application a routing entity

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

Application awareness was useful because modern services are not always cleanly represented by static addresses. Managed platforms, SaaS endpoints, and distributed components can change while application identity remains meaningful. A policy referencing a service or user could outlast a rule written around addresses and ports alone.

The model required accurate discovery. The controller had to know which domains and endpoints belonged to an application, which dependencies were required, and which identity provider claims were trusted. A stale mapping could send a request over the wrong path or apply an incorrect security rule. Application abstraction did not remove the need to understand network state; it placed another semantic layer on top of it.

Combining Network Transit and App Transit acknowledged two worlds inside enterprises. Legacy systems, private networks, and IP-based controls persist, while newer applications depend on domains, identity, and managed services. Full-Stack Cloud Transit was the product name for running both models together rather than forcing one to replace the other.

Identity broadened 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 established. This supported a zero-trust-style policy, where location alone was not enough evidence of authority.

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

The controller also became a concentration point for sensitive context. It could hold topology, application relationships, user attributes, risk signals, and policy outcomes. This improved diagnostics and optimisation, but it raised the stakes of unauthorised access. Least privilege, retention, audit, and separation of duties were therefore architectural requirements, not administrative afterthoughts.

Prosimo’s approach illustrates a wider infrastructure shift. Routing and access policies increasingly depend on identity and application semantics. The more context the platform sees, the more useful its decisions become, and the more its authority needs precise governance.

Asset discovery created the graph on which every subsequent decision depended

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

Discovery was strategically important because cloud environments change outside centralised network workflows. Application teams can create accounts, networks, endpoints, and managed services with their own automation. Manual diagrams become stale. An API-based inventory could provide a more current map, but its completeness depends on account coverage, permissions, parsing logic, and provider APIs.

The map was not just documentation. It was the data structure from which routing, segmentation, service insertion, and optimisation decisions were computed. If an asset or dependency was missing, every result built on top of it could be wrong. Topology therefore needed clear provenance: when it was collected, which account supplied it, which regions it covered, and whether any request had failed.

This map also helps explain the acquisition. Palo Alto Networks can create security value when it knows where workloads are and which traffic paths exist. A system that discovers assets and changes routes shortens the distance between buying a software firewall and placing it in the correct location. Bhau’s later statement specifically highlighted asset discovery and accelerating software firewall deployment.

AIR turned edge measurement into operational recommendations

Application-driven Intelligent Results, or AIR, analysed measurements gathered by AXI Edges. The AWS guide illustrated round-trip time, processing time, application response time, transaction type, risk, and policy outcomes. The platform could correlate user, network, and application observations instead of displaying separate device counters.

This correlation addressed a familiar operational problem: a slow transaction could be caused by the user path, the edge, the cloud backbone, a security service, or the application itself. Cross-layer visibility could narrow the search faster than separate dashboards, and could support recommendations about path, location, risk, and cost.

The quality of the recommendation depended on measurement coverage and the model used to interpret it. The edge only saw traffic that passed through it. External application dependencies and intra-provider states could remain invisible. A recommendation could be directionally useful without proving root cause.

Measurement also had governance value. Historical observations could help the enterprise explain why a path or policy changed. They could also reveal sensitive application usage and user behaviour. The public content does not provide a full description of retention or data governance post-acquisition, so these questions remain part of customer due diligence.

AWS provided the clearest documented implementation

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

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

The Marketplace path simplified the first deployment step by packaging AXI Edge in an approved channel. But it did not remove the follow-on work around account permissions, path design, high availability, capacity, and operations. Day-zero automation could reduce installation friction while the long-term control problem remained.

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

Azure and Google Cloud completed the multi-cloud claim

Prosimo also supported Microsoft Azure and Google Cloud environments. Its materials described orchestration around Azure Virtual WAN, Google Cloud networks, and private service entities. The goal was to deliver a single operational model while keeping each provider’s native networking in place.

The existence of support does not prove capability parity across providers. Cloud APIs mature at different speeds, and similar product names can hide different semantics. A path, segment, private endpoint, or service insertion might need provider-specific handling. The evidence provided does not reconstruct a feature parity matrix for every region and release.

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

The same applies after the acquisition. Palo Alto Networks may use the shared map for security posture across clouds, but cloud providers continue to control the native entities that execute the path. Ownership of the orchestration layer does not create ownership of the cloud underlay.

The product expanded from connectivity to lifecycle

By 2023, Prosimo described workflows to design, build, troubleshoot, and manage multi-cloud networks. The product went beyond creating a tunnel or gateway. Asset discovery supported design, orchestration built connectivity, maps and measurements supported troubleshooting, and policy plus historical state supported ongoing management.

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

A shared evidence base could create governance tension as well. A centralised platform might reveal that a cloud team’s setup differs from enterprise policy. The enterprise must decide which system is authoritative and who approves remediation. Software alone cannot resolve this organisational question.

The lifecycle story also increased switching cost. When a controller holds the asset map, policies, measurements, edge placements, and automation integrations, replacing it requires more than moving a circuit. The customer must export or rebuild the operating model. Prosimo sold reduced cloud fragmentation while simultaneously creating the possibility of controller lock-in.

Segmentation extended from network access to application policy

Prosimo offered segmentation from Layer 3 to Layer 7. At the network level, routing domains and segments defined which networks or sites could communicate. At higher layers, it checked application identity, user context, and transaction properties against the rule.

The multi-layer model could narrow the gap between a network zone and an application policy. A business service might be permitted while broad network access remained blocked. Conversely, a reachable path might be denied because the identity or application context did not pass.

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

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

Service insertion linked path control to firewall economics

Cloud security design must decide where inspection happens. Centralised firewalls can simplify policy and reduce device count, but they may create hairpinning, concentration, and capacity pressure. Distributed firewalls stay closer to workloads and reduce some path distortion, but they multiply deployment, licensing, upgrade, and policy operations.

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

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

It also widened the controller’s blast radius. A wrong policy could bypass inspection, create a loop, produce asymmetric routing, or halt an application. Health checks, staged change, simulation, audit, and rollback are necessary because a service-insertion failure is simultaneously a network and a security event.

The 2024 partnership should not be backdated to the acquisition

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

Nevertheless, the partnership created a bridge. Prosimo could demonstrate how its path and policy system made VM-Series deployment easier across clouds. Palo Alto Networks could evaluate the technology inside a real integration before the subsequent corporate transition. The public evidence does not describe the acquisition process, so claiming the partnership was designed as a formal pre-acquisition step remains conjecture.

By early 2025, founder and employee records had changed. The company page later carried the acquisition tag. In late 2025, Bhau said the technology was fully integrated into Palo Alto Networks products. Together these records support the acquisition outcome, but they leave the legal mechanism unresolved.

This sequence matters for editorial accuracy and for customers. A partnership means two vendors, support structures, and a known boundary for integration. An acquisition can transfer the roadmap, data, contracts, and authority to a single company. The transition changes more than the name even when the technical path initially looks similar.

Nebula turned the topology map into a conversational interface

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

The useful asset was not the language interface alone, but the structured cross-cloud context underneath it. A general model cannot diagnose a private path or segment it cannot see. Nebula could rely on the asset inventory, topology, policies, and observations that Prosimo was already collecting. This made the prior investment in a shared map relevant to AIOps.

Conversational access could make complex data available 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 approved action. High-risk changes still required deterministic controls, permission boundaries, and human review.

Prosimo cited potential benefits such as 60–80% mean-time-to-resolve reduction and over 60% cloud networking cost reduction. These were figures claimed by the company in a product announcement. The evidence does not provide an independent methodology or customer baselines that prove general applicability. They can be cited as benefits suggested by Prosimo, not as measured market facts.

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

The same 2024 announcement positioned Prosimo’s architecture for AI workloads. Distributed systems might need private data access, connectivity between clouds and data centres, compliance controls, and routing that reflects application behaviour. These requirements were consistent with its existing asset, policy, and path model.

The 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 tools. Its potential role was the connectivity and security layer around distributed data and services.

The AI positioning was strategically logical because cross-cloud topology value rises as data and services become more distributed. But it was also a marketing category introduced shortly before the end of the company’s independent operation. The evidence does not prove a separate AI product revenue stream, named production deployments, or audited workload results.

The lasting point is that multi-cloud measurement can become an input to machine-assisted operations. The current question is whether Palo Alto Networks has preserved that context and how it presents the capability. The public evidence at the cutoff date does not provide a complete answer.

The business model sold software on top of infrastructure it did not own

Prosimo’s independent activity was a software subscription and services business, not a carrier model. Customers deployed AXI Edges in their own environments and connected cloud accounts to the control layer. Revenue likely depended on licences or subscriptions, support, professional services, and channels, but precise pricing and contract metrics were not published in the provided evidence.

The model could scale without owning fibre. A single software platform orchestrated many regions and multiple customer environments. But one cannot infer aggregate economics from architecture alone. Supporting provider APIs, edge lifecycles, security integrations, and enterprise deployment could be costly, while the customer, not the vendor, paid for the cloud resources consumed by the edges.

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

The company’s breadth may have increased sales complexity. Network, security, cloud, and application teams could all benefit, while budget ownership remained unclear. The product needed a buyer willing to fund a shared control layer instead of letting each cloud and team operate separately.

Partners, customers, and investors occupied different positions

Amazon Web Services was simultaneously an infrastructure provider, integration partner, and go-to-market partner. Azure and Google Cloud were supported environments. Identity providers supplied authentication context, firewall vendors provided inspection, co-location companies and carriers could host or interconnect edges, and channel partners could design and operate deployments.

Flexport appeared as a named customer reference in AWS Cloud WAN material. The reference proves enterprise interest in the architecture, but it does not reveal the full scope, duration, or commercial value of the deployment. It should not be turned into a substitute for knowing the entire customer base.

General Catalyst led the Series A and participated in governance from an investor seat. Investors linked to WRVI or Celesta appeared in company materials, and later communications referenced additional high-profile names, including one associated with BlackRock whose exact investing entity was not resolved. The records support a well-connected funding base, not a full ownership table.

Palo Alto Networks occupied the most important relationship. It moved from being a security partner in 2024 to being the acquirer by early 2025. The sequence shows how an ecosystem dependency becomes a control relationship when one party buys the software layer that orchestrates the path to its product.

At least $55 million was raised; exit economics are unknown

The documented funding record consists of $25 million Series A in April 2021 and $30 million Series B in 2022. The total is at least $55 million. The evidence does not include an audited cap table, valuation, debt schedule, or later round.

The acquisition consideration was not announced and has not been independently verified. Without a price, the outcome cannot responsibly be categorised as a strategic premium, a limited technology tuck-in, an acqui-hire, or a pressured sale. Continued integration supports that the technology had value, but it does not reveal investor or founder returns.

Palo Alto Networks’ revenue or market capitalisation should not be attributed to Prosimo after the acquisition. Once the start-up stopped appearing as a separate unit, there was no longer a standalone revenue, profit, or customer segment to analyse. The larger owner may make the technology more widely deployed, while reducing the visibility of its own economics.

The absence of a formal acquisition announcement is itself notable. Customers, employees, and researchers typically use such announcements to determine timing, support, and strategic rationale. Here the case must be reconstructed from professional histories, the company page tag, and a later founder statement. That is enough to correct the company’s status, but not enough to invent deal details.

Competition came from platforms, clouds, and in-house engineering

Prosimo competed against 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 against the do-it-yourself model where an enterprise uses infrastructure-as-code, transit services, route tables, and firewalls directly. The alternatives addressed different parts of the same problem.

A specialist controller can offer a single topology and policy model across providers. A native design inside one cloud can reduce third-party dependency and fit a particular provider. A carrier-backed service can supply physical transport. A SASE or security platform can combine connectivity and enforcement. In-house engineering can preserve control at the cost of staffing and integration burden.

Prosimo’s differentiation lay in combining application and network transit, distributed edges, cloud-native orchestration, topology, measurement, and service insertion. That very breadth made comparison difficult. Buyers needed to test the cloud services, paths, identity systems, and security pattern they would actually use, rather than comparing category names.

The acquisition changes the competition frame. Prosimo no longer has to win as an independent company, but its technology must prove its value inside Palo Alto Networks. The relevant comparison becomes: does the integrated discovery and path orchestration improve the deployment of Palo Alto security products, and do customers accept the resulting platform lock-in?

Native cloud services were both foundation and alternative

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN, and Google Cloud networks gave enterprises strong native options. Prosimo depended on these services, and it competed against the possibility that customers would run them directly.

The relationship created a moving boundary. Whenever a provider added global routing, segmentation, private access, or centralised policy, it became easier to reproduce some third-party functions natively. At the same time, each new native service added another entity that a cross-cloud controller could discover and orchestrate. Cloud progress could narrow part of Prosimo’s value while expanding the need for translation between providers.

The decisive factor was as much organisational as technical. A single-cloud company with strong in-house engineering might prefer native tools. A multi-cloud enterprise with fragmented teams might value a single control plane. A regulated organisation might prefer a third-party policy layer while worrying about privileged credentials and data concentration.

No architecture eliminated lock-in. Native tools increased dependence on one provider’s APIs and semantics. A cross-cloud controller increased dependence on its map, policies, and edge software. The useful question was whether the dependency was visible, portable, and aligned with the enterprise’s operating model.

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

The distributed architecture reduced dependence on a single traffic hub, but it created interacting failure domains. The central system could halt or carry stale intent. An edge could fail or become isolated. A cloud API could reject part of a change. An identity provider could go down. The underlay could lose capacity or take an unexpected path. An inserted firewall could exhaust resources.

Partial failure is particularly difficult. One provider might accept a route update while another rejects it. The controller’s intended state then diverges from the actual cloud state. Traffic might take an asymmetric path or bypass inspection. A trusted system needs reconciliation, safely repeatable operations, staged change, explicit error states, and rollback that respects each provider’s behaviour.

Public evidence describes availability and optimisation at a high level, but it does not include an independent fault-injection study, a complete incident log, or a public service outcome. Resilience claims should therefore be tied to documented architecture or named customer evidence.

The acquisition adds another failure domain: product continuity. Customers need to know which console, API, edge image, policy model, and support destination replace the historic Prosimo system. Technically successful code integration can still carry migration risk if the commercial and operational boundaries are unclear.

Cloud credentials made the controller part of the critical management plane

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

A credential compromise could expose topology or enable broad changes. A software defect or operator error could propagate policy across multiple clouds. The risk grew with the platform’s utility: the more accounts and services it managed, the wider the potential blast radius.

Enterprises needed least-privilege roles, separate credentials for discovery and change, multi-party approval, full audit, rotation, emergency revocation, and a recovery path that did not depend on the controller alone. Public materials do not provide a complete independent security assessment, so these remain necessary deployment controls, not proven product guarantees.

The measurement map was also sensitive. It could reveal application names, network structure, policies, user relationships, path health, and cost patterns. Post-acquisition governance should clarify where this data is stored, which Palo Alto products can use it, and how legacy customer permissions were transferred. Public evidence at the cutoff does not answer these questions.

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

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

Ownership does not prove that neutrality disappeared. The evidence does not provide a current partner matrix or contemporary product architecture. But it changes what the customer must ask: does the path controller remain open to multiple security vendors, can policies and measurements be exported, and does optimisation favour the owner’s portfolio?

The integration statement focused on ingress, egress, and east-west inspection. That suggests Prosimo’s topology and orchestration entered a security deployment pipeline. But it does not prove that the historic App Transit, user access, cost optimisation, or every cloud-networking workflow continued as a distinct capability.

This is a familiar infrastructure pattern. A start-up abstracts a hard orchestration problem, and a larger platform buys that abstraction because it increases consumption and control of its core product. The buyer gains a deployment path. The customer may gain integration and lose some independence from the vendor.

The current product map is the biggest missing fact

The public record confirms the acquisition and integration, but it does not define a complete map from AXI, Network Transit, App Transit, AIR, and Nebula to current Palo Alto Networks products or SKUs. It does not publish legacy end-of-support dates, migration procedures, or a feature-by-feature continuity table.

The gap prevents a present-tense product review. Historical descriptions can explain what Prosimo built and why it mattered, but they do not tell a buyer which capabilities are available, licensed, or supported today. Contemporary deployment advice must rely on current Palo Alto Networks documentation, not archived Prosimo datasheets.

The missing map also constrains strategic analysis. Fully absorbing the map and orchestration layer is different from selectively using asset discovery and firewall placement. The former creates a broad control service; the latter uses Prosimo primarily for accelerated security deployment. The founder’s statement supports technological continuity and leaves this architectural boundary unresolved.

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

Who controls multi-cloud routing?

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

Prosimo sought the most useful middle ground. It did not own the underlay, but it tried to own the map and policy translation on top of 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 measurement is treated as authoritative. That is operational power over routing even when the fibre is owned by someone else.

After the acquisition, Palo Alto Networks owns the surviving technology and decides how to integrate, package, and evolve it. Cloud providers remain sovereign inside their environments, and the enterprise can revoke credentials or choose a different architecture. But exit may become costly if the topology, policies, and workflows have grown dependent on the controller.

The answer is layered, not absolute: the enterprise delegates, the controller orchestrates, the cloud and carrier layers transport, and the security platform enforces. Prosimo’s story matters because it shows that ownership of the orchestration layer can change without any change in cloud account ownership or physical path.

Primary

Why Prosimo still matters after the acquisition

Prosimo captured a real infrastructure shift. The unit of network operation is moving from device and prefix to application, identity, service dependency, and policy map. Cloud APIs make network state programmable, and distributed edges make the enforcement location movable. A controller that sees multiple clouds can orchestrate actions that no single cloud console completes alone.

The company also revealed the cost of that orchestration. A shared layer needs privileged credentials, ongoing API maintenance, accurate discovery, semantic translation, measurement, and operational discipline. It can reduce fragmented work while creating a new concentration point. The same system can simplify routing and widen the blast radius of a mistaken decision.

Palo Alto Networks’ acquisition makes the control question clearer. Networking and security are converging around service insertion, workload discovery, and policy. A security vendor that knows the topology and changes paths does not just inspect traffic handed to it; it can help decide which traffic reaches inspection and where.

Prosimo should therefore not be remembered as a failed independent brand, nor as proof that a single platform solved multi-cloud. Its lasting contribution was defining the cross-cloud map as infrastructure. The remaining question is whether that map, now inside a larger security company, remains transparent, portable, and governed enough for customer trust.