Summary

  • Prosimo was founded in 2019 and raised at least $55 million in its 2021 Series A and 2022 Series B rounds; it did not publish audited revenue, valuation or acquisition price.
  • AXI combined centralised intent, topology and analysis with distributed nodes that discovered cloud assets, connected applications and inserted security services without owning the physical infrastructure.
  • The integration with VM-Series announced in June 2024 preceded Prosimo's move into Palo Alto Networks around February 2025; the exact date, price and current product map have not been published.
  • Control remains split among enterprises, orchestration software, cloud providers and Palo Alto Networks; portability of topology, credentials, policies and authority over routes is the decisive test for customers.

The brand vanished, but the problem remained

By 2026, it is no longer accurate to describe Prosimo as an active, independent vendor. Public career histories show its founders and several staff moving to Palo Alto Networks around February 2025. Prosimo’s corporate identity is marked as acquired, and former CTO Nehal Bhau later wrote that the technology had been integrated into Palo Alto Networks products. The evidence establishes a change of control and continuity of technical value. It does not establish the exact signing or closing date, the legal form or the price of the deal.

This precision must appear up front because it changes the tense of every product claim. AXI, Network Transit, App Transit, Application-driven Intelligent Results and Nebula were capabilities documented during the independent stage. They must not be presented as current, separately sold products until Palo Alto Networks publishes a contemporary product and support mapping. After an acquisition, an architecture can survive as embedded code, a shared service, a module or an internal engineering asset; those outcomes are not equivalent.

Losing the brand did not remove the underlying problem. Enterprises continue distributing workloads across Amazon Web Services, Microsoft Azure, Google Cloud, private data centres, colocation facilities, SaaS platforms and remote users. Every environment has its own routes, gateways, private endpoints, identity controls, security services, quotas and billing rules. An enterprise can own all the accounts and still lack a coherent view of a request’s journey. Prosimo’s significance lies in its attempt to gather that view into a common control layer.

That is why the acquisition forms the narrative axis, not a mere epilogue. Prosimo built a cross-cutting control layer capable of discovering assets, interpreting application context and steering traffic to security services. Palo Alto Networks first appeared as a technical partner whose VM-Series firewalls could be inserted into those paths; it later became the owner of the technology. The boundary that separated orchestration-from-routing from deep inspection fell inside a single cybersecurity platform.

In multi-cloud routing, context decides

A routing table can say whether a prefix is reachable through a next hop. On its own it does not explain which application the user wanted to reach, whether the user or workload is trusted, whether an inspection service should see the traffic, whether a private endpoint exists, whether one cloud path costs more than another or whether the transaction fails after the packet arrives. Multi-cloud operations turn those questions into a shared-control problem.

Prosimo’s thesis was that routing authority should be based on more than Layer 3 connectivity. Its software aimed to combine cloud inventory, network state, application identity, user identity, risk, performance and transactional telemetry. That context made it possible to express policies such as connect a specific application, separate a segment, choose an entry point or steer selected traffic to a firewall. The value did not come from inventing a new fibre path, but from deciding how to assemble existing paths and services.

That distinction explains the phrase “application experience infrastructure”. The application request sat above the individual network entity. A VPC, VNet, subnet, transit hub or private link became a component of the end-to-end journey, not the final management entity. The proposition also placed the product in several markets at once: cloud networking, application delivery, zero trust access, operational network verification, cost optimisation and security service insertion.

That breadth created opportunity and ambiguity. A product that spans multiple teams can fix coordination failures that belong to no single owner. It can also be hard to evaluate because network, security, cloud, application and finance teams use different definitions of success. Prosimo had to show that a cross-cutting model improved operations without becoming another privileged layer whose mistakes affect every environment.

What Prosimo was and what remained of its technology

Prosimo was a privately held cloud networking software company founded in 2019 in the San Francisco Bay Area. Ramesh Prabagaran was co-founder and CEO; Nehal Bhau was co-founder and CTO during the independent period. Public histories also place Linus Aranha and Pradeep Aragonda in founding or senior engineering roles, though their exact titles must be tied to dated biographies.

Its main platform was Application eXperience Infrastructure, commonly shortened to AXI. AXI used a central software layer for intent, topology, analysis and orchestration, along with AXI Edge nodes distributed in cloud regions, colocation or nearby on-premises infrastructure. Later the offering was organised as Full-Stack Cloud Transit, with Network Transit and App Transit for different classes of connectivity. AIR analysed telemetry and produced operational insights; Nebula added a conversational interface in 2024.

Prosimo was not a cloud operator. It did not own a global fibre network connecting every region. Paths could traverse provider backbones, the public Internet, direct circuits, colocation links and enterprise networks. Nor was it a firewall vendor in the same sense as Palo Alto Networks. In the 2024 integration, Prosimo discovered, segmented and steered; VM-Series performed deep inspection.

After the acquisition, the safest description is “technology lineage”. The post-close integration statement highlights multi-cloud asset discovery and faster deployment of software firewalls for ingress, egress and east-west traffic. That is evidence that important components survived. It does not prove that the full historical AXI catalogue, its commercial packaging or its support model continued unchanged.

The problem after SD-WAN

The founding team had experience in large-scale networking, application delivery and cloud infrastructure. Prosimo also emerged from the broader ecosystem of founders and engineers associated with Viptela, a company that helped establish SD-WAN as an enterprise category. The next problem was different. SD-WAN could simplify the relationship between a branch and the network, but it did not create a single operating model inside 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 identity provider outside both, private connectivity towards a data centre and security inspection placed at specific boundaries. Every dependency can be represented by a different native entity. The network team sees prefixes and transit hubs; the cloud team sees accounts and resources; the application owner sees domains and transactions; security sees zones and inspection policies.

Prosimo started from the request, not the branch. The question was how a user or a workload should reach an application with acceptable security, performance, availability and cost. That approach expanded the routing entity from the destination prefix to a transaction with identity and application context. It also forced it to collect and maintain far more information than a conventional router.

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

From 2019 founding to 2021 public launch

Prosimo was founded in 2019 but did not announce its public launch until 6 April 2021. General Catalyst led a $25 million Series A at launch. The investor described the opportunity in terms of delivering application experience across clouds, in line with the intent to define a category broader than traditional branch connectivity.

The launch placed the company in a crowded and still unsettled market. Cloud providers made it easy to consume their network services. SD-WAN and SASE vendors extended policy towards the cloud. Application delivery vendors could optimise requests, and security companies could inspect them. Prosimo’s case depended on linking those functions in a cloud-oriented architecture without claiming to replace everything around it.

The funding allowed it to build integrations, software edge nodes, analytics, a go-to-market organisation and partner relationships. It did not prove product fit, revenue scale or lasting differentiation. The supplied evidence contains no audited revenue, ARR, customer count or valuation. The funding record shows investor backing of a thesis, not a full report of operating performance.

In 2022, Prosimo completed a $30 million Series B described as oversubscribed. Adding the two clearly identified rounds yields a verified total of at least $55 million. Some databases may show more if they duplicate announcements or related records; they should not be used without resolving the underlying events.

AXI situated policies above the clouds and execution near the workloads

The AXI architecture split work between a central control-and-analytics layer and distributed edge nodes. The central layer maintained network and application intent, discovered assets, assembled topology, integrated identity, analysed telemetry and orchestrated changes. AXI Edge nodes were deployed close to workloads or users to enforce policy without forcing all paths through a distant physical hub.

The separation resembles other software-defined systems, but the entities were cloud-specific and application-aware. The controller needed access to accounts and APIs, while the edge node needed connectivity with native transit, workload networks, private endpoints or external routes. Authority came from combining both views: global intent above the clouds and local execution close to the traffic.

The architecture also created an operating boundary. Every edge node consumed cloud resources, needed high availability and had to be updated, monitored and secured. The central layer required credentials with enough privilege to discover assets and alter network state. The enterprise gained a common flow but added a management system whose availability and correctness affected production connectivity.

Prosimo sometimes used the language of autonomous cloud networking. The evidence supports automation, recommendations and API-driven orchestration. It does not describe a network operating without human policy, cloud services or underlying transport. Operators still defined intent, approved access, resolved exceptions and remained accountable for the outcome.

AXI Edge was a location decision, not a generic device

An AXI Edge could be deployed in a VPC or VNet, in a colocation facility or on adjacent infrastructure. AWS’s technical journey showed an edge VPC connected to workload VPCs via Transit Gateway, with optional firewall chaining and access from sites or remote users. The enforcement point sat inside the cloud topology, not at a far-off corporate perimeter.

Location affected more than latency. It defined where traffic entered the policy domain, which cloud backbone or Internet path it used, where it was encrypted or inspected and which telemetry was available. A poorly placed edge node could cause suboptimal routing or cost; a well-placed one could shorten the path or keep traffic close to the workload.

Distribution increased failure domains. Capacity, versions, zone design, route convergence and permissions could vary across regions. High availability needed more than two instances: the controller, cloud route tables, security services and return paths had to agree on the failover state.

The edge node was therefore part of a wider operating system. Its value depended on discovery, topology, policy and analytics staying consistent with the environment. Treating it as a standalone virtual appliance would miss the architecture Prosimo was trying to sell.

The underlying infrastructure stayed in third-party hands

Prosimo coordinated transport but did not own the physical path. A connection could use AWS or another provider’s backbone, the public Internet, Direct Connect or ExpressRoute, a colocation service, a carrier circuit or an enterprise network. The platform could select and orchestrate available options; it could not remove the latency, packet loss, failure domains or pricing rules created by those providers.

That boundary matters when evaluating performance promises. A controller can choose a better observed path or bring ingress closer to the user. It cannot guarantee that a carrier will not fail, that a cloud region will stay available or that an external dependency will respond quickly. Application experience also includes DNS, server processing, storage, browser and external services outside the controller’s total authority.

Not owning a backbone was not only a disadvantage. It allowed the use of infrastructure enterprises had already bought and let the platform benefit from cloud providers’ investment. Prosimo could reach regions without building fibre and coordinate native systems such as AWS Cloud WAN. In return, it depended on API stability, quotas, commercial terms and each provider’s semantics.

The pitch was about operational control, not physical ownership. The platform tried to make heterogeneous infrastructure behave as a single managed system while preserving its native advantages. Whether that abstraction reduced lock-in or merely relocated it depended on the portability of policies, topology and edge nodes.

Network Transit managed connectivity between network entities

Network Transit focused on VPCs, VNets, subnets, regions, sites and segments. It coordinated native transit services and route objects so that teams could build connectivity through a common flow instead of configuring each provider separately. It answered the classic need: a source or segment must reach a destination through an allowed path.

It did not pretend that cloud differences had disappeared. AWS, Azure and Google Cloud expose different entities, quotas and behaviours. Address overlaps, asymmetric routes, private endpoints and service limits still needed engineering. Prosimo could normalise common operations and show relationships, but the underlying systems kept their constraints.

Network Transit also brought segmentation. Route domains and policies could separate environments or limit connectivity. The controller had to understand where a segment existed across clouds and how it materialised with native entities. A policy expressed once could generate several provider-specific changes.

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

App Transit made the application the routing entity

App Transit extended the model beyond subnets. It could use the application domain, identity, request type, transaction state, risk and performance to decide how a user or workload reached a service. It was the clearest attempt to differentiate from a conventional cloud router.

The application view was useful because modern services do not always have fixed addresses. Managed platforms, SaaS endpoints and distributed components can change while the service identity remains meaningful. A policy that refers to the application or the user can outlast one based only on addresses and ports.

The model demanded correct discovery. The controller had to know which domains and endpoints belonged to an application, which dependencies were required and which identity claims were reliable. An outdated map could steer a request down the wrong path or apply an incorrect policy. The application abstraction did not remove the need to know the network state; it added a semantic layer.

The combination of Network Transit and App Transit recognised that enterprises contain both worlds. Legacy systems, private subnets and IP controls persist while new applications depend on domains, identity and managed services. Full-Stack Cloud Transit was the name for operating both models together without forcing one to replace the other.

Identity expanded the route decision and the trust boundary

Application-aware access needed identity integration. The platform could use the context of a user or workload to decide whether a connection should be established and through which path. This supported a zero trust approach where location was not enough proof of authority.

Identity improved precision but added dependency. Policy now relied on the identity provider, its attributes, the session and groups. A route could fail because authentication was unavailable or an attribute changed, even though routers and edge nodes were working. Diagnosis had to cross the network-identity boundary.

The controller also became a concentration point for sensitive context. It could gather topology, application relationships, user attributes, risk signals and policy outcomes. That pool improved diagnosis and optimisation while raising the impact of unauthorised access. Least privilege, retention, audit and separation of duties were architectural requirements.

Prosimo’s approach shows a broad trend: routing and access increasingly depend on identity and application semantics. The more context a platform sees, the more useful its decisions can be and the more rigorous the governance of its authority must be.

Asset discovery created the graph on which every later decision depended

A cross-cutting controller cannot govern what it cannot see. Prosimo developed asset discovery and mapping capabilities for VPCs, VNets, subnets, applications, connectivity and security relationships. Those views supported environment onboarding, design, troubleshooting and policy enforcement.

Discovery was strategic because environments change outside central network flows. Application teams can create accounts, networks, endpoints and services with their own automation. A manual diagram becomes stale. An API-driven inventory can be more current, though its completeness depends on account coverage, permissions, parser logic and the APIs themselves.

The graph was not just documentation. It was the structure from which routes, segmentation, service insertion and optimisation were calculated. If an asset or dependency was missing, the conclusions built on that model could be wrong. Topology needed traceability: collection date, source account, covered regions and any collection failures.

The graph helps explain the acquisition. Palo Alto Networks gains value when it knows where workloads and paths are. A system that discovers assets and changes routes shortens the distance between buying a software firewall and placing it correctly. Bhau’s later statement highlighted exactly asset discovery and accelerated firewall deployment.

AIR turned telemetry from AXI Edge nodes into recommendations

Application-driven Intelligent Results, or AIR, analysed telemetry collected by AXI Edge nodes. AWS’s journey described visibility of round-trip time, processing, application response, transaction type, risk and policy outcomes. The platform could correlate user, network and application rather than displaying siloed counters.

That correlation addressed a common problem. A slow transaction can originate in the user path, the edge node, the cloud backbone, a security service or the application. A cross-cutting view can narrow the search faster than multiple consoles. It can also support recommendations for route, location, risk or cost.

Quality depended on telemetry coverage and the model used to interpret it. An edge node only observed traffic that passed through it, while external dependencies and certain internal provider conditions could remain outside its view. A recommendation could therefore be useful to guide investigation without proving root cause on its own.

Telemetry also had governance value. Historic records could explain why a policy changed, but they could also expose application usage and user behaviour. Public materials do not offer a complete explanation of retention and data governance after the acquisition, so these questions remain part of customer due diligence.

AWS offered the best-documented public implementation

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

AWS Cloud WAN was particularly important. It supplied a native backbone and segmentation that Prosimo could orchestrate without replacing it. The arrangement showed the cooperative model: AWS owned global network and infrastructure; Prosimo brought multi-cloud intent, application context, edge nodes and analytics.

Marketplace simplified initial deployment through an approved channel, but did not remove the subsequent work on permissions, route design, high availability, capacity and operations. The upfront automation reduced friction without solving the long-term control problem.

A Flexport reference supported the use case in corporate materials. It showed that an enterprise customer was willing to endorse the architecture, but it was not an independent audit of scale, savings or availability. Customer references should be treated as adoption examples, not as universal proof of performance.

Azure and Google Cloud completed the multi-cloud claim

Prosimo also supported Microsoft Azure and Google Cloud. Its materials described orchestration around Azure Virtual WAN and Google Cloud’s network and private service entities. The goal was a single model while preserving native networks.

The existence of support does not prove parity. APIs evolve at different speeds and similar names hide different semantics. A route, segment, private endpoint or insertion may require specific treatment. The evidence does not allow reconstruction of a full matrix by region and version.

Abstraction must be understood as a translation system. It can normalise intent and workflow, but it must preserve the details that affect security, cost and failure modes. A uniform interface becomes dangerous when it hides relevant implementation differences.

The same holds after the acquisition. Palo Alto Networks may use the common graph to place security, but providers still control the native entities. Owning the orchestration does not mean owning the cloud infrastructure.

The product evolved from connectivity to a lifecycle model

In 2023, Prosimo described workflows to design, build, diagnose and manage multi-cloud networks. The platform was no longer presented as a simple tunnel or gateway: discovery supported design, orchestration created connectivity, maps and telemetry helped diagnosis, and policies and history supported ongoing management.

This framing widened the number of potential buyers. The network team could use topology and analytics; the cloud team, onboard accounts and services; security, review segmentation; migration, plan changes; and FinOps, study egress costs and paths. The platform’s value rose when multiple groups worked from the same evidence.

Shared evidence can also create governance conflicts. A central platform can reveal that native configuration differs from enterprise policy, but the organisation must decide which system is authoritative and who can approve correction. Software can expose the divergence; it cannot resolve that institutional question on its own.

The lifecycle approach also raised switching costs. When a controller holds the graph, policies, telemetry, edge nodes and integrations, replacing it demands rebuilding much of the operating model. Prosimo was selling a reduction of fragmentation across clouds, but it could create a new dependency on the controller.

Segmentation went from network connectivity to application policy

Prosimo presented segmentation spanning Layer 3 to Layer 7. At the network layer, domains and segments controlled connectivity; at higher layers, application identity, user identity and transaction properties could refine the rule.

The model could shrink the distance between network zone and application policy. A service could be allowed while general subnet-to-subnet connectivity remained blocked. Conversely, a reachable route could be denied by identity or context.

Prosimo did not thereby become a full firewall. The integration split responsibilities: Prosimo orchestrated routes, segmentation and service insertion, while VM-Series performed deep inspection. The distinction matters because traffic steering and policy enforcement can fail in different ways.

A segment is only effective if all relevant paths are represented. An unknown path, a native exception or a failed insertion can bypass it. Operational verification requires comparing declared policy, provider state and observed traffic.

Service insertion linked routes and firewall economics

Cloud security design must decide where inspection happens. Centralised firewalls can simplify policies and reduce instance count, but they can also create hairpin traffic, concentration and scale pressure. Distributed firewalls stay closer to workloads but multiply deployment, licensing, updates and operations.

Prosimo supported both patterns with VM-Series. Policy could steer traffic to a central point or to firewalls distributed in application VPCs. The controller updated routes and Palo Alto provided inspection.

This made orchestration valuable to a security vendor. A firewall cannot protect traffic that never reaches it; discovery, placement and route updates reduce the friction between buying security capacity and inserting it into a production path. That is a plausible strategic reason for the acquisition.

It also widened the blast radius of mistakes. A wrong policy could bypass inspection, create loops, cause asymmetric routes or take an application offline. Pre-checks, phased rollouts, simulation, audit and rollback mechanisms were therefore necessary, because failure affected both network and security at the same time.

The 2024 partnership must not be retrospectively read as an acquisition

Prosimo and Palo Alto Networks announced the integration on 12 June 2024. The release described a joint solution and did not claim that Palo Alto Networks had acquired Prosimo. Using it as proof of ownership would confuse two distinct events.

The partnership did create a bridge. Prosimo could demonstrate that its control layer made VM-Series deployment easier, while Palo Alto Networks evaluated the technology inside a real integration before the corporate move. The sources do not describe the purchase process, so claiming the partnership was a formal pre-acquisition phase would be speculative.

In early 2025 the career histories of founders and staff changed, and the corporate page later appeared marked as acquired. By the end of that year, Bhau stated that the technology was fully integrated into Palo Alto Networks products. Together, these signals support the conclusion that an acquisition took place, while leaving its legal mechanics unresolved.

The sequence matters for customers. A partnership implies two vendors, two support organisations and a defined integration boundary; an acquisition can shift roadmaps, data, contracts and authority to one company. The change goes beyond branding, even if the technical journey initially looks similar.

Nebula made the topology graph accessible through a conversational interface

Prosimo introduced Nebula in February 2024 within an AI Suite. The assistant was supposed to answer natural-language questions about overlaps, costs, route health, security violations and other conditions represented in the graph and telemetry.

The important asset was not just the interface but the structured context. A general model does not diagnose a private path it cannot see. Nebula relied on inventory, topology, policy and observations already collected. The earlier investment in a common graph became the foundation for AIOps.

Conversational access could open complex data to more operators. It could also create false confidence if it missed assets, misunderstood the query or treated a recommendation as an authorised action. High-risk changes still needed deterministic controls, permissions and human review.

Prosimo claimed potential reductions of 60–80% in MTTR and more than 60% in cloud network cost. These were vendor numbers in a product note. No independent methodology or customer base exists to demonstrate general applicability. They can be cited as proposed benefits, not as measured facts.

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

The same note presented the architecture for AI. Distributed systems can need private data access, cloud-to-data-centre links, compliance and application-aware paths. Those requirements fitted the existing model of assets, policy and routes.

The label did not change the underlying infrastructure. Prosimo still depended on cloud networks, carriers and customer infrastructure. It also did not supply GPUs or model development tools. Its possible function was connectivity and security around distributed data and services.

The positioning was strategically logical because the value of topology rises with distribution. It was also a marketing category introduced shortly before the independent end. The evidence does not establish AI revenue, named deployments or audited results.

The lasting takeaway is that multi-cloud telemetry can feed machine-assisted operations. The live question is whether Palo Alto retained that context and how it exposes it. The sources do not offer a complete answer.

The business model sold software for infrastructure Prosimo did not own

Prosimo was a subscription-software and services play, not an operator. Customers deployed AXI Edge nodes and connected accounts to the central layer. Revenue would have depended on licences, support, professional services and channel, though pricing and metrics were not published in the evidence.

It could scale without its own fibre. One platform could coordinate many regions. However, the architecture does not allow margins to be inferred. Maintaining APIs, edge nodes, integrations and enterprise deployment can be expensive; cloud resources consumed by each edge node may be paid by the customer.

Prosimo used marketplaces, integrators, channels and customer references to reach the enterprise market. These relationships are not equivalent: a marketplace presence demonstrates a purchase and deployment channel; a technical integration demonstrates compatibility under certain conditions; and a testimonial provides a commercial reference. None of these alone reveals paying customer count or recurring revenue.

Breadth could complicate the sale. Network, security, cloud and application teams all benefited, but the budget might have no single owner. The product needed a buyer willing to fund a common control layer.

Partners, customers and investors held different positions

AWS was both infrastructure provider and integration partner, while Azure and Google Cloud were listed as supported environments. Identity providers supplied authentication context; firewalls supplied inspection capacity; and colocation and carrier services could host or connect edge nodes. Channel partners could design, deploy and manage the solutions.

Flexport appeared as a reference in AWS Cloud WAN material. It demonstrates enterprise interest but does not reveal scope, duration or value. It must not be turned into a proxy for customer count.

General Catalyst led the Series A and participated as an investor. Materials also cited WRVI or Celesta and, later, a BlackRock-linked participation whose exact vehicle was unresolved. This shows a well-connected funding base, not a complete capitalisation table.

Palo Alto Networks was the decisive relationship: from partner in 2024 to acquirer in 2025. The sequence shows how an ecosystem dependency becomes control when one entity buys the layer that coordinates the path to its product.

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

The verified record includes a $25 million Series A in April 2021 and a $30 million Series B in 2022. No audited capitalisation table or public data on valuation, debt or later rounds exists.

The acquisition price was neither disclosed nor independently verified. Without that number, it is not possible to responsibly classify the deal as a strategic-premium buy, a modest technology acquisition, an acqui-hire or a pressured sale. The integration continuity demonstrates technical value, but does not reveal the return obtained by investors or founders.

Palo Alto Networks’ financial scale must not be attributed to Prosimo. Once it stopped being observable, no standalone revenue, profit or customer segment exists. A larger owner can extend reach and make individual figures less visible.

The absence of a formal acquisition announcement is also relevant. Such documents typically clarify timing, support and strategic rationale; here, the status must be reconstructed from career histories, the corporate page tag and a later co-founder statement. That evidence is enough to correct the corporate status, but not to invent deal terms.

Competition came from platforms, clouds and in-house engineering

Prosimo competed against specialist platforms such as Aviatrix and Alkira, against enterprise networking and SASE vendors, against the native services of AWS, Azure and Google Cloud, and against do-it-yourself approaches combining infrastructure-as-code, transit services, route tables and firewalls. Each alternative solved a different piece of the same problem.

A specialist controller could offer a common topology and policy across providers. A native solution reduced external dependency inside one cloud; a carrier supplied physical transport; a security platform combined connectivity and inspection; and in-house development preserved control at the cost of more staff and integration.

Prosimo’s differentiation was the combination of network and application transit, edge nodes, native orchestration, graph, telemetry and service insertion. That breadth made comparisons difficult. Buyers had to test specific services, routes, identities and security.

The acquisition changes the competitive frame. Prosimo no longer competes as an independent company; its technology must justify its place inside Palo Alto Networks. The question becomes how much it improves security deployment and how much additional dependency customers are willing to accept.

Native services were both foundation and substitute

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN and Google Cloud provided powerful options. Prosimo depended on them and also competed with direct customer operation.

The boundary was shifting. New native features could replicate parts of Prosimo’s proposition while also adding more entities that a cross-cutting controller had to coordinate. The evolution of cloud services could reduce the value of some functions and increase the need for cross-provider translation.

The decision was organisational as well as technical. A single-cloud enterprise with strong engineering might prefer native. A fragmented multi-cloud might value a common plane. A regulated organisation might appreciate independent evidence and fear credential concentration.

No approach eliminated technology dependence. Native tools tied the customer to provider-specific APIs and semantics; the cross-cutting controller tied them to its graph, policies and edge nodes. The relevant question was whether that dependency was visible, portable and suitable for the organisation’s operating model.

Failures could originate in the controller, edge nodes, cloud APIs, the identity system or the underlying infrastructure

Distributed architecture reduced single-hub dependence but created multiple failure domains. The central service could become stale; an edge node could be isolated; an API could reject part of a change; the identity system could become unresponsive; the underlying infrastructure could degrade; or a firewall could run out of capacity.

Partial failures are especially hard to manage. One provider may accept an update while another rejects it, so the desired state diverges from the real state, and asymmetric routes or paths that bypass inspection can appear. The system needs reconciliation, idempotent operations, phased rollouts, explicit error states and per-provider rollback mechanisms.

The public evidence does not contain independent fault-injection tests, a full incident log or universal service-level outcomes. Any claim about resilience must therefore be tied to the documented architecture or to specific customer evidence.

The acquisition adds another risk: product continuity. Customers need to know which console, API, node image, policy model and support organisation replace the historic system. A technically successful integration can still produce a poor migration if the commercial and operational boundaries stay opaque.

Cloud credentials made the controller critical infrastructure

Discovery and orchestration required access to cloud accounts. The inventory could use read-only permissions, while changes to routes, segments and service insertion needed greater authority. The controller became part of the privileged management plane even if it did not own the workloads.

A compromised credential could expose topology or enable broad changes. A defect or mistake could propagate across multiple clouds. The blast radius grew with the platform’s utility.

Enterprises needed to apply least privilege, separate credentials, multiple approvals, audit, rotation, emergency revocation and a recovery path independent of the same controller. Public materials do not include a full independent security assessment, so these items must be treated as necessary controls, not verified guarantees.

The telemetry graph was equally sensitive. It could reveal applications, network structure, policies, user relationships, route state and cost patterns. Post-acquisition governance must clarify where that data is stored, which products can use it and how permissions were migrated; public sources do not resolve these questions.

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

As an independent company, Prosimo could present itself as a common layer between clouds and security services. With Palo Alto Networks as owner, the incentives changed: the technology could make it easier to deploy VM-Series and other group products, improving integration while raising questions about the treatment of third-party services.

Ownership alone does not prove that neutrality vanished, but no up-to-date compatibility matrix has been published either. The question for customers becomes whether third-party support is maintained, whether policies and telemetry can be exported and whether optimisation favours the owner’s portfolio.

The statement emphasised ingress, egress and east-west inspection. This suggests that topology and orchestration became part of a security deployment system, but it does not prove that App Transit, user access, cost optimisation or all historic flows continued as separate capabilities.

This is a common infrastructure pattern: a startup abstracts a complex coordination problem and a larger platform buys that abstraction to increase use of its core products. The customer can gain integration while also losing some independence from vendors.

The current product map is the biggest missing piece

The evidence confirms acquisition and integration but does not provide a full map linking AXI, Network Transit, App Transit, AIR and Nebula to current products or SKUs. Nor have support dates, migration procedures or a functional continuity table been published.

That absence prevents a present-tense product evaluation. The history explains what was built, but not what is sold or maintained today. Any current deployment recommendation must be based on current Palo Alto Networks documentation.

It also limits strategy. A full absorption of the graph would be different from using only asset discovery and firewall placement. The statement confirms technical continuity and leaves the boundary unresolved.

A future product document, guide or case study could clarify. Until then, the accurate formulation is that, according to a co-founder, the technology was integrated into Palo Alto Networks products, though the scope and packaging are not verified.

Who controls multi-cloud routing?

No single actor controls the entire path. The enterprise controls account ownership, business intent, application design and the credentials it grants. The controller discovers topology, translates policies and changes route state; cloud providers control their APIs, transit services, private endpoints, backbones and many failure domains; and carriers and colocation providers control other transport legs. Security services, in turn, decide whether inspected traffic is permitted or blocked.

Prosimo sought the middle position. Without owning the underlying infrastructure, it wanted to own the graph and the translation. Whoever controls that layer decides what is seen, how segments are represented, where edge nodes are placed, which service inspects and which telemetry is sent. That amounts to practical power over routing.

After the acquisition, Palo Alto Networks controls the technology and its development. Cloud providers retain authority within their own environments, and the enterprise can revoke credentials or choose another architecture; yet exit may be costly if topology, policies and operational flows depend on the controller.

The answer is therefore layered: the enterprise authorises; the controller coordinates; cloud providers and carriers transport; and the security platform enforces controls. The Prosimo story shows that the owner of the coordination layer can change without the cloud accounts or physical fibre changing hands.

Primary

Why Prosimo remains relevant after the acquisition

Prosimo identified a real infrastructure shift. The unit of operation is moving from the device and the prefix towards the application, identity, service dependencies and the policy graph. APIs make network state programmable, while edge nodes allow policy enforcement points to move. A controller with visibility across multiple clouds can coordinate actions that no single console completes on its own.

It also showed the cost of that coordination: privileged credentials, continuous API maintenance, accurate discovery, semantic translation, telemetry and operational discipline. A common layer can reduce fragmented work while also creating a new concentration point. The same system that simplifies routes can widen the impact of a bad decision.

The acquisition makes the convergence of networking and security more visible. A security company that knows the topology and can change routes is not just inspecting the traffic it receives; it is also helping decide which traffic reaches inspection and where it happens.

Prosimo should not be remembered only as a vanished brand or as proof that one platform solved multi-cloud. Its lasting contribution was to turn the cross-cutting graph into a form of infrastructure. The open question is whether that graph, now inside a larger company, will stay transparent, portable and governable.