Zusammenfassung

  • Prosimo wurde 2019 gegründet und hat in einer Series A im Jahr 2021 und einer Series B im Jahr 2022 mindestens 55 Millionen US-Dollar eingeworben. Geprüfte Umsätze, Bewertungen und der Kaufpreis wurden nicht veröffentlicht.
  • AXI kombinierte eine zentrale Intent-, Topologie- und Analyseebene mit verteilten Edges, ermöglichte die Erkennung von Cloud-Assets, Anwendungsanbindung, Sicherheitsdiensteinfügung und Telemetriesammlung, ohne einen physischen Backbone zu besitzen.
  • Nach der Ankündigung der VM-Series-Integration im Juni 2024 wurde Prosimo etwa im Februar 2025 von Palo Alto Networks übernommen, das genaue Datum, der Preis und die Zuordnung zu aktuellen Produkten sind jedoch nicht öffentlich.
  • Die Kontrolle ist auf Unternehmen, Orchestrierungssoftware, Cloud-Anbieter und Palo Alto Networks verteilt. Die Möglichkeit, Topologie, Anmeldeinformationen, Richtlinien und Routing-Änderungsrechte zu migrieren, ist für Kunden eine wichtige Entscheidungsgrundlage.

Der Verlust der unternehmerischen Unabhängigkeit ließ die Probleme fortbestehen

Es ist nicht präzise, Prosimo im Jahr 2026 als aktiven, unabhängigen Anbieter darzustellen. Öffentliche Karriereprofile zeigen, dass die Gründer und mehrere Mitarbeiter etwa im Februar 2025 zu Palo Alto Networks gewechselt sind. Die Unternehmensseite von Prosimo zeigt den Status als übernommen an, und der ehemalige CTO Nehal Bhau gab später an, dass die Technologie des Unternehmens in Palo Alto Networks-Produkte integriert wurde. Diese Belege belegen den Kontrollübergang und den Fortbestand des technologischen Werts, offenbaren aber nicht das Vertragsdatum, das Abschlussdatum, die Rechtsform oder den Preis.

Diese Korrektur muss vorangestellt werden, da sie die Zeitform aller Produktbeschreibungen ändert. AXI, Network Transit, App Transit, Application-driven Intelligent Results und Nebula sind als Funktionen von Prosimo während seiner unabhängigen Phase dokumentiert. Solange Palo Alto Networks keine aktuelle Produkt- und Support-Zuordnungstabelle veröffentlicht, sollten sie nicht als separat erhältliche, aktuelle Produkte beschrieben werden. Die frühere Architektur mag als eingebetteter Code, geteilte Dienste, Module oder interne Engineering-Assets nach der Übernahme fortbestehen, jedoch nicht im gleichen Zustand.

Das Verschwinden der Marke bedeutet nicht, dass die zugrunde liegenden Probleme verschwunden sind. Unternehmen verteilen ihre Workloads weiterhin auf Amazon Web Services, Microsoft Azure, Google Cloud, private Rechenzentren, Colocation-Standorte, SaaS und entfernte Nutzer. Jede dieser Umgebungen hat eigene Routen, Gateways, private Endpunkte, Identitätskontrollen, Sicherheitsdienste, Limits und Abrechnungsregeln. Selbst wenn ein Unternehmen die Konten besitzt, hat es möglicherweise keinen zentralen Überblick darüber, wie eine Anfrage zwischen den Umgebungen verläuft.

Die Bedeutung von Prosimo liegt darin, dass es versuchte, dieses Gesamtbild in einer einzigen operationellen Ebene zu erfassen und zu steuern.

Die Übernahme ist daher keine Fußnote, sondern der rote Faden dieses Artikels. Prosimo baute eine cloudübergreifende Steuerungsebene auf, die Assets erkennen, den Anwendungskontext interpretieren und Verkehr zu Sicherheitsdiensten lenken konnte. Palo Alto Networks trat zunächst als Technologiepartner auf, der VM-Series-Firewalls in diesen Pfad einfügte. Später wurde es zum Eigentümer der Technologie. Die Grenze zwischen Routing-Orchestrierung und tiefgehender Inspektion verlagerte sich in eine einzige Cybersicherheitsplattform.

Multi-Cloud-Routing ist ein Wettbewerb um den Kontext

Eine Routing-Tabelle kann beantworten, ob ein Präfix über einen nächsten Hop erreichbar ist. Sie kann jedoch nicht erklären, welche Anwendung der Nutzer erreichen wollte, ob der Anfragende vertrauenswürdig ist, ob der Verkehr einen Inspektionsdienst durchlaufen muss, ob ein privater Endpunkt verfügbar ist, welche Cloud-Route teuer ist oder ob Transaktionen nach dem Eintreffen der Pakete scheitern. Der Multi-Cloud-Betrieb fasst all dies in einem einzigen Steuerungsproblem zusammen.

Das Argument von Prosimo war, dass Routing-Entscheidungen nicht allein auf Layer-3-Erreichbarkeit beruhen sollten. Die Software des Unternehmens versuchte, Cloud-Asset-Inventare, Netzwerkzustände, Anwendungsidentitäten, Nutzeridentitäten, Risiken, Leistung und Transaktionstelemetrie zu kombinieren. Dadurch konnten Richtlinien ausgedrückt werden, wie die Anbindung bestimmter Anwendungen, die Segmenttrennung, die Auswahl von Einstiegspunkten oder das Erzwingen, dass ausgewählter Verkehr eine Firewall passiert.

Der Wert lag nicht in der Erfindung neuer Glasfaserpfade, sondern in der Entscheidung, wie bestehende Pfade und Dienste kombiniert werden.

Dieser Unterschied erklärt, warum das Unternehmen den Begriff „Application Experience Infrastructure“ verwendete. Im Zentrum der Verwaltung standen nicht einzelne Netzwerkkomponenten, sondern die Anwendungsanforderungen. VPCs, VNets, Subnetze, Transit-Hubs und Private Links wurden nicht als finale Verwaltungseinheiten, sondern als Elemente eines End-to-End-Pfades betrachtet. Mit diesem Ansatz trat das Produkt gleichzeitig in mehrere Märkte ein: Cloud Networking, Anwendungsbereitstellung, Zero-Trust-Zugriff, Netzwerk-Assurance, Kostenoptimierung und Sicherheitsdiensteinfügung.

Die große Reichweite schuf sowohl Chancen als auch Unklarheiten. Ein Produkt, das mehrere Teams betrifft, kann Koordinationsprobleme lösen, für die niemand allein verantwortlich ist. Andererseits ist die Bewertung schwierig, da Netzwerk-, Sicherheits-, Cloud-, Anwendungs- und Finanzteams unterschiedliche Erfolgsdefinitionen haben. Prosimo musste zeigen, dass das cloudübergreifende Modell den Betrieb verbessern kann, ohne zu einer neuen privilegierten Schicht zu werden, deren Fehler sich auf alle Umgebungen ausbreiten.

Was war Prosimo und was ist geblieben?

Prosimo war ein 2019 gegründetes, nicht börsennotiertes Cloud-Networking-Softwareunternehmen mit Sitz in der San Francisco Bay Area. In der unabhängigen Phase fungierten Ramesh Prabagaran als Mitgründer und CEO und Nehal Bhau als Mitgründer und CTO. In öffentlichen Karriereprofilen werden auch Linus Aranha und Pradeep Aragonda mit Gründungs- oder leitenden Ingenieursrollen genannt, doch die genauen Titel sollten anhand datierter Lebensläufe bestätigt werden.

Die Kernplattform war die Application eXperience Infrastructure, kurz AXI. AXI kombinierte eine zentrale Softwareschicht für Intent, Topologie, Analyse und Orchestrierung mit verteilten AXI Edges, die in Cloud-Regionen, Colocation-Umgebungen oder angrenzender On-Premises-Infrastruktur platziert wurden. Später wurde das Produkt als Full-Stack Cloud Transit organisiert, wobei Network Transit und App Transit unterschiedliche Verbindungstypen abdeckten. AIR analysierte die Telemetrie und lieferte betriebliche Empfehlungen, und 2024 fügte Nebula eine dialogorientierte Schnittstelle hinzu.

Prosimo war kein Cloud-Carrier. Es besaß kein globales Glasfaser-Backbone, das alle Regionen verbindet. Die Pfade konnten über Cloud-Provider-Backbones, das öffentliche Internet, dedizierte Leitungen, Colocation-Verbindungen und Unternehmensnetzwerke führen. Es war auch kein Firewall-Anbieter im gleichen Sinne wie Palo Alto Networks. In der Integration von 2024 bestand die Rolle von Prosimo in Erkennung, Segmentierung und Lenkung, während die tiefe Sicherheitsinspektion von der VM-Series übernommen wurde.

Die sicherste Bezeichnung nach der Übernahme ist „technologische Abstammung“. Spätere Integrationserklärungen betonten die Beschleunigung der Multi-Cloud-Asset-Erkennung und der Bereitstellung von Software-Firewalls für Ingress-, Egress- und Ost-West-Inspektion. Dies ist ein Beleg dafür, dass wichtige Prosimo-Komponenten erhalten blieben. Es ist jedoch kein Beweis dafür, dass die früheren AXI-Produktlinien, kommerziellen Pakete und das Kundensupportmodell unverändert fortgeführt wurden.

Das Problem nach SD-WAN

Das Gründungsteam verfügte über Erfahrung in großflächigem Networking, Anwendungsbereitstellung und Cloud-Infrastruktur. Prosimo entstand auch aus dem weiten Netzwerk von Gründern und Ingenieuren, das mit Viptela verbunden war, einem Unternehmen, das maßgeblich zur Etablierung von SD-WAN als Unternehmensmarktsegment beitrug. Das nächste Problem war jedoch ein anderes. SD-WAN konnte die Anbindung von Zweigstellen an Netzwerke und Anwendungen vereinfachen, schuf aber kein einheitliches Betriebsmodell innerhalb und zwischen mehreren Public Clouds.

Multi-Cloud-Anwendungen können von Web-Endpunkten in einer Umgebung, Datenbanken oder Managed Services in einer anderen, externen Identitätsprovidern, privaten Verbindungen zu Rechenzentren und Sicherheitsinspektionen an ausgewählten Perimeterpunkten abhängen. Jede Abhängigkeit wird durch unterschiedliche native Konstrukte repräsentiert. Netzwerkteams sehen Präfixe und Transit-Hubs, Cloud-Teams sehen Konten und Ressourcenobjekte, Anwendungsverantwortliche sehen Domains und Transaktionen, und Sicherheitsteams sehen Zonen und Inspektionsrichtlinien.

Prosimo begann nicht bei der Zweigstelle, sondern bei der Anfrage. Die zu beantwortende Frage war, wie ein Nutzer oder Workload eine Anwendung unter angemessenen Sicherheits-, Leistungs-, Verfügbarkeits- und Kostenbedingungen erreichen kann. Dieser Rahmen erweiterte das Routing-Ziel von reinen Zielpräfixen hin zu Transaktionen mit Identität und Anwendungskontext. Dies erforderte die Erfassung und Pflege weitaus mehr Informationen als ein herkömmlicher Router.

Das Marktumfeld war ebenfalls günstig. AWS, Azure und Google Cloud erweiterten ihre nativen Transit- und Private-Connectivity-Dienste. Unternehmen konnten nun anspruchsvolle Netzwerke innerhalb jeder Cloud aufbauen, aber die APIs, Objekte und Richtlinienmodelle unterschieden sich je nach Anbieter. Die Chance von Prosimo lag nicht darin, diese durch ein eigenes Backbone zu ersetzen, sondern sie aufeinander abzustimmen.

Von der Gründung 2019 bis zum offiziellen Start 2021

Prosimo wurde 2019 gegründet, kündigte den offiziellen Start jedoch erst am 6. April 2021 an. Die Series A in Höhe von 25 Millionen US-Dollar zum Start wurde von General Catalyst angeführt. Der Investor betonte die Chance, eine cloudübergreifende Anwendungserfahrung zu liefern, was mit der Vision der Gründer übereinstimmte, einen Bereich jenseits der traditionellen Zweigstellenanbindung zu definieren.

Der Markt zum Startzeitpunkt war überfüllt und die Grenzen unscharf. Cloud-Anbieter machten ihre eigenen Netzwerkdienste benutzerfreundlicher. SD-WAN- und SASE-Anbieter erweiterten ihre Richtlinien in die Cloud, Anwendungsbereitsteller optimierten Anfragen und Netzwerksicherheitsunternehmen konnten diese inspizieren. Die Überzeugungskraft von Prosimo hing davon ab, diese Funktionen in einer einzigen cloudnativen Architektur zu verbinden, ohne zu behaupten, alles andere zu ersetzen.

Die Finanzierung erlaubte den Aufbau von Integrationen, Software-Edges, Analysen, Vertriebsorganisationen und Partnerschaften. Sie beweist jedoch weder Product-Branche & Märkte-Fit, Umsatzgröße noch nachhaltige Differenzierung. In den verfügbaren Unterlagen fehlen geprüfte Umsätze, jährlich wiederkehrende Einnahmen, Kundenzahlen und Bewertungen. Die Finanzierungsaufzeichnungen zeigen lediglich, dass Investoren Kapital in eine Hypothese steckten, nicht das vollständige Bild der Geschäftsentwicklung.

Im Jahr 2022 schloss Prosimo eine Series B über 30 Millionen US-Dollar ab, die als überzeichnet beschrieben wurde. Zusammengenommen belaufen sich die deutlich nachweisbaren Mittelzuflüsse auf mindestens 55 Millionen US-Dollar. Einige Datenbanken können durch Doppelzählung von Ankündigungen eine höhere Summe ausweisen; sie sollten daher nicht ohne Prüfung der ursprünglichen Transaktionen verwendet werden.

AXI platzierte die Policy oberhalb der Cloud und die Ausführung nah an den Workloads

Die AXI-Architektur teilte die Rollen zwischen einer zentralen Steuerungs- und Analyseebene und verteilten Software-Edges auf. Die zentrale Ebene hielt die Anwendungs- und Netzwerkintention, entdeckte Assets, erstellte Topologien, integrierte Identitäten, analysierte Telemetrie und orchestrierte Änderungen. Die AXI Edges wurden in der Nähe von Workloads oder Nutzern platziert, sodass Richtlinien durchgesetzt werden konnten, ohne sämtlichen Verkehr zu einem entfernten physischen Hub zurückzuleiten.

Diese Trennung ähnelt anderen softwaredefinierten Systemen, war jedoch cloudspezifisch und anwendungsbewusst. Der Controller benötigte Zugriff auf Cloud-Konten und APIs, während die Edges Anbindung an native Transitdienste, Workload-Netzwerke, private Endpunkte und externe Routen benötigten. Die Kombination aus einer übergreifenden Intention oberhalb der Cloud und lokaler Ausführung nahe dem relevanten Verkehr verlieh der Plattform ihre Autorität.

Gleichzeitig ergaben sich Implementierungsgrenzen. Jeder Edge verbrauchte Cloud-Ressourcen, erforderte ein Hochverfügbarkeitsdesign und musste aktualisiert, überwacht und geschützt werden. Die Steuerungsebene benötigte ausreichend privilegierte Anmeldeinformationen, um Assets zu erkennen und Netzwerkzustände zu ändern. Unternehmen erhielten einen gemeinsamen Workflow, fügten jedoch ein neues Verwaltungssystem hinzu, dessen Verfügbarkeit und Korrektheit die Produktionserreichbarkeit beeinflussten.

Prosimo verwendete gelegentlich den Begriff autonomes Cloud Networking. Die Evidenz belegt Automatisierung, Empfehlungen und API-gesteuerte Orchestrierung. Es war kein Netzwerk, das unabhängig von menschlichen Richtlinien, Cloud-Anbieterdiensten und den darunter liegenden Transportpfaden agierte. Betreiber legten weiterhin Intentionen fest, genehmigten Zugriffe, behandelten Ausnahmen und trugen die Verantwortung für die Ergebnisse.

Der AXI Edge war kein Universalgerät, sondern eine Platzierungsentscheidung

Der AXI Edge konnte in Cloud-VPCs, VNets, Colocation-Umgebungen oder angrenzender Infrastruktur platziert werden. Eine AWS Technical Brief zeigte eine Konfiguration, bei der eine Edge VPC über ein Transit Gateway mit Workload VPCs verbunden wurde, optional eine Firewall-Kette integrierte und den Zugriff von entfernten Nutzern oder On-Premises-Standorten ermöglichte. Der Ausführungspunkt von Prosimo befand sich nicht an einem entfernten Unternehmensperimeter, sondern innerhalb der Cloud-Topologie.

Die Platzierung bestimmte nicht nur die Latenz, sondern auch, an welcher Stelle der Verkehr in die Policy-Domäne eintritt, welches Cloud-Backbone oder welchen Internetpfad er nutzt, wo Verschlüsselung und Inspektion stattfinden und welche Telemetrie gesammelt werden kann. Eine schlechte Platzierung verursachte Umwege und Kosten; eine gute verkürzte die Pfade und hielt den Verkehr nah an den Workloads.

Die verteilte Platzierung erhöhte die Anzahl der zu verwaltenden Fehlerdomänen. Kapazität, Softwareversion, Cloud-Zonendesign, Routenkonvergenz und Zugriffsrechte konnten je nach Region variieren. Hochverfügbarkeit bedeutete nicht, einfach zwei Instanzen laufen zu lassen. Controller, Cloud-Routing-Tabellen, Sicherheitsdienste und Rückpfade mussten denselben Failover-Zustand teilen.

Der Edge war daher Teil eines größeren Betriebssystems. Sein Wert hing davon ab, dass Asset-Erkennung, Topologie, Richtlinien und Analyse mit den umgebenden Cloud-Umgebungen abgestimmt waren. Ihn als isolierte virtuelle Appliance zu betrachten, würde die Architektur verkennen, die Prosimo zu verkaufen versuchte.

Der Underlay gehörte immer jemand anderem

Prosimo orchestrierte den Transport, besaß aber keine physischen Pfade. Anwendungspfade konnten Cloud-Backbones wie die von AWS, das öffentliche Internet, Direct Connect oder ExpressRoute, Colocation-Dienste, Carrier-Leitungen und Unternehmensnetzwerke nutzen. Es konnte Routen aus den verfügbaren Optionen auswählen und koordinieren, aber nicht die Latenz, Paketverluste, Fehlerdomänen oder Abrechnungsregeln jedes Anbieters beseitigen.

Diese Grenze ist bei der Bewertung von Leistungsbehauptungen wichtig. Der Controller konnte beobachtbar bessere Pfade wählen und Einstiegspunkte näher an den Nutzer legen. Es gab jedoch keine Garantie gegen Carrier-Ausfälle, Cloud-Region-Ausfälle oder Latenz externer Abhängigkeiten. Die Anwendungserfahrung umfasst auch DNS, Serververarbeitung, Speicher, Browserverhalten und Drittanbieterdienste, die außerhalb der vollständigen Kontrolle eines Netzwerk-Controllers liegen.

Das Fehlen eines eigenen Backbones war nicht nur eine Schwäche. Es nutzte die bereits von Unternehmen erworbene Infrastruktur und profitierte von den Investitionen der Cloud-Anbieter. Es konnte Regionen erreichen, ohne Glasfaser zu verlegen, und native Systeme wie AWS Cloud WAN einbinden. Stattdessen bestand eine Abhängigkeit von API-Stabilität, Service-Limits, kommerziellen Bedingungen und anbieterspezifischer Semantik.

Der Anspruch war daher nicht physisches Eigentum, sondern betriebliche Kontrolle. Es versuchte, heterogene Underlays unter Beibehaltung ihrer nativen Vorteile wie ein einziges Verwaltungssystem agieren zu lassen. Ob diese Abstraktion die Abhängigkeit verringerte oder nur verlagerte, hing von der Portabilität von Richtlinien, Topologie und Edge-Platzierung ab.

Network Transit behandelte die Erreichbarkeit zwischen Netzwerkobjekten

Network Transit konzentrierte sich auf VPCs, VNets, Subnetze, Regionen, Standorte und Segmente. Es orchestrierte cloudnative Transit- und Routenkonfigurationen so, dass Verbindungen über einen gemeinsamen Workflow erstellt werden konnten, statt jeden Anbieter einzeln konfigurieren zu müssen. Es erfüllte die grundlegende Anforderung herkömmlicher Netzwerke: dass ein Quellpräfix oder -segment das Ziel über erlaubte Pfade erreicht.

Es war nicht die Behauptung, dass die Unterschiede zwischen den Clouds verschwinden. AWS, Azure und Google Cloud haben unterschiedliche Objekte, Limits und Routing-Verhalten. Überlappende Adressräume, asymmetrische Pfade, private Endpunkte und anbieterspezifische Servicebeschränkungen erforderten weiterhin Berücksichtigung im Design. Prosimo konnte gängige Operationen normalisieren und Beziehungen sichtbar machen, doch die inhärenten Beschränkungen der zugrunde liegenden Systeme blieben bestehen.

Network Transit übernahm auch die Segmentierung. Mittels Routing-Domänen und Richtlinien konnten Umgebungen getrennt und die Erreichbarkeit eingeschränkt werden. Der Controller musste verstehen, wo sich Segmente über mehrere Clouds befanden und wie native Konfigurationen die Grenzen implementierten. Selbst eine einmal ausgedrückte Richtlinie konnte in mehrere anbieterspezifische Änderungen übersetzt werden.

Der Vorteil lag darin, die Intention in einer einzigen Oberfläche verwalten zu können. Das Risiko lag in der Umsetzung. Wenn die gemeinsame Richtlinie von den Cloud-Einstellungen abwich, konnte das Unternehmen glauben, ein Segment sei geschützt, während der tatsächliche Anbieterzustand anders war. Abstimmung, Audit und explizite Fehlerberichte waren daher ebenso wichtig wie die anfängliche Bereitstellung.

App Transit machte Anwendungen zum Routing-Ziel

App Transit erweiterte das Modell über Subnetze hinaus. Bei der Entscheidung, wie Nutzer oder Workloads einen Dienst erreichen, konnten Anwendungsdomäne, Identität, Anfragetyp, Transaktionszustand, Risiko und Leistung einbezogen werden. Dies war der Punkt, an dem Prosimo versuchte, sich am deutlichsten von herkömmlichen Cloud-Routern abzuheben.

Diese anwendungszentrierte Sichtweise war sinnvoll, da moderne Dienste sich nicht einfach durch statische Adressen darstellen lassen. Managed-Plattformen, SaaS-Endpunkte und verteilte Komponenten können sich ändern, während anwendungsbezogene Bezeichner ihre Bedeutung behalten. Richtlinien, die sich auf einen Dienst oder Nutzer beziehen, können langlebiger sein als Regeln, die nur auf Adresse und Port basieren.

Dieses Modell erforderte eine präzise Erkennung. Der Controller musste wissen, welche Domains und Endpunkte zu einer Anwendung gehören, welche Abhängigkeiten bestehen und welchen Identitätsprovider-Ansprüchen vertraut werden kann. Veraltete Zuordnungen konnten Anfragen auf falsche Pfade leiten und fehlerhafte Sicherheitsregeln anwenden. Die Anwendungsabstraktion machte das Verständnis des Netzwerkzustands nicht überflüssig, sondern fügte eine Bedeutungsebene hinzu.

Die Kombination von Network Transit und App Transit erkannte an, dass in Unternehmen zwei Welten koexistieren. Während Legacy-Systeme, private Subnetze und IP-basierte Kontrollen fortbestehen, setzen neue Anwendungen auf Domains, Identitäten und Managed Services. Full-Stack Cloud Transit war der Produktname für den gemeinsamen Betrieb beider, ohne die eine durch die andere zu ersetzen.

Identität erweiterte Routing-Entscheidungen und Vertrauensgrenzen

Anwendungsbewusster Zugriff erforderte Identitätsintegration. Die Plattform konnte den Nutzer- oder Workload-Kontext nutzen, um zu entscheiden, ob und wie eine Verbindung hergestellt wird. Dies untermauerte Zero-Trust-Richtlinien, bei denen der Standort allein keine ausreichende Berechtigungsgrundlage darstellt.

Identität erhöhte die Präzision, schuf aber auch neue Abhängigkeiten. Routing- oder Anwendungsrichtlinien hingen nun vom Identitätsprovider, seinen Ansprüchen, dem Sitzungszustand und Gruppeninformationen ab. Selbst wenn Router und Edge einwandfrei funktionierten, konnte ein Authentifizierungsausfall oder eine Attributänderung den Netzwerkpfad unterbrechen. Die Fehlerbehebung musste die Grenze zwischen Netzwerkbetrieb und Identitätsbetrieb überschreiten.

Der Controller wurde zudem zu einem zentralen Punkt sensibler Kontextdaten. Er konnte Topologie, Anwendungsbeziehungen, Nutzerattribute, Risikosignale und Richtlinienergebnisse enthalten. Diese Daten verbesserten Diagnose und Optimierung, vergrößerten aber auch die Auswirkungen unbefugten Zugriffs. Das Prinzip der geringsten Rechte, Aufbewahrungsfristen, Auditierung und Funktionstrennung waren keine nachträglichen Verwaltungsfragen, sondern architektonische Anforderungen.

Der Ansatz von Prosimo illustriert eine branchenweite Entwicklung. Routing- und Zugriffsrichtlinien hängen zunehmend von Identität und Anwendungssemantik ab. Je mehr Kontext die Plattform sieht, desto nützlicher können ihre Entscheidungen sein. Gleichzeitig muss diese Macht strenger kontrolliert werden.

Asset-Erkennung schuf den Graphen, der alle folgenden Entscheidungen trug

Ein cloudübergreifender Controller kann nicht kontrollieren, was er nicht sieht. Prosimo entwickelte eine Cloud-Asset-Erkennung und Kartierung, die VPCs, VNets, Subnetze, Anwendungen, Verbindungen und Sicherheitsbeziehungen darstellte. Diese Ansichten unterstützten Onboarding, Design, Fehlerbehebung und Richtlinien.

Da Cloud-Assets außerhalb zentraler Netzwerkprozesse verändert werden, hatte die Erkennung strategischen Wert. Anwendungsteams konnten durch eigene Automatisierung Konten, Netzwerke, Endpunkte und Managed Services erstellen. Manuell gepflegte Diagramme wurden schnell veraltet. Ein API-gesteuertes Inventar konnte aktuellere Graphen liefern, deren Vollständigkeit jedoch von Account-Scope, Berechtigungen, Parsing-Logik und Anbieter-APIs abhing.

Der Graph war nicht nur Dokumentation. Er war die Datenstruktur, auf der Routing, Segmentierung, Diensteinfügung und Optimierung berechnet wurden. Fehlten Assets oder Abhängigkeiten, konnten alle darauf aufbauenden Schlussfolgerungen falsch sein. Daher benötigte die Topologie eine Provenienz: wann sie erfasst wurde, welche Konten sie lieferten, welche Regionen enthalten waren und ob die Anfragen fehlerfrei waren.

Dieser Graph erklärt auch den Grund für die Übernahme. Palo Alto Networks kann Sicherheitswert schöpfen, wenn es die Position von Workloads und Verkehrspfaden kennt. Ein System, das Cloud-Assets erkennt und Routen ändern kann, verkürzt den Weg vom Kauf einer Software-Firewall bis zu ihrer korrekten Platzierung. Bhaus spätere Integrationsaussage hob ausdrücklich die Beschleunigung von Asset-Erkennung und Software-Firewall-Bereitstellung hervor.

AIR wandelte Edge-Telemetrie in operative Empfehlungen um

Application-driven Intelligent Results (AIR) analysierte die von den AXI Edges gesammelte Telemetrie. Eine AWS-Beschreibung erläutert die Visualisierung von Roundtrip-Zeiten, Verarbeitungszeiten, Anwendungsantwortzeiten, Transaktionstypen, Risiko und Richtlinienergebnissen. Die Plattform konnte Nutzer-, Netzwerk- und Anwendungsbeobachtungen miteinander korrelieren, anstatt isolierte Gerätezähler zu zeigen.

Diese Korrelation adressiert häufige Betriebsprobleme. Die Ursache einer langsamen Transaktion kann im Nutzerpfad, am Edge, im Cloud-Backbone, in einem Sicherheitsdienst oder in der Anwendung selbst liegen. Eine schichtübergreifende Sicht kann die Eingrenzung schneller ermöglichen als separate Konsolen und Empfehlungen zu Pfaden, Platzierung, Risiko und Kosten unterstützen.

Die Qualität der Empfehlungen hing vom Umfang der Telemetrie und dem Interpretationsmodell ab. Ein Edge konnte nur den Verkehr beobachten, der ihn passiert. Externe Anwendungsabhängigkeiten oder interne Zustände des Cloud-Anbieters blieben möglicherweise unsichtbar. Empfehlungen konnten richtungsweisend sein, ohne die Grundursache zu beweisen.

Die Telemetrie hatte auch Governance-Wert. Historische Beobachtungen können erklären, warum sich Routen oder Richtlinien geändert haben. Gleichzeitig könnten sie sensible Nutzungsmuster und Nutzerverhalten offenlegen. Da öffentliche Unterlagen Aufbewahrungsfristen und die Daten-Governance nach der Übernahme nicht vollständig beschreiben, bleiben dies Punkte für die Kunden-Due-Diligence.

AWS lieferte die eindeutigsten Implementierungsbelege

Die AWS-bezogenen Arbeiten von Prosimo hinterließen die stärksten öffentlichen technischen Belege. Das Unternehmen integrierte sich mit den Bereitstellungsworkflows von AWS Transit Gateway, Cloud WAN, PrivateLink und Marketplace for Containers Anywhere. AWS veröffentlichte technische Beschreibungen zur Platzierung des AXI Edge, zum Onboarding von Anwendungen, zu Identität, Sicherheit und Optimierung.

Besonders bedeutsam war AWS Cloud WAN. Es bot einen cloudnativen Backbone- und Segmentierungsdienst, den Prosimo orchestrieren, aber nicht ersetzen konnte. Diese Konfiguration veranschaulicht ein kooperatives Modell: AWS besaß die nativen Netzwerke und die globale Infrastruktur, während Prosimo die cloudübergreifende Intention, den Anwendungskontext, die Edge-Software und die Analyse lieferte.

Die Marketplace-Workflows paketierten den AXI Edge über genehmigte Kanäle und vereinfachten die ersten Bereitstellungsschritte. Die nachfolgenden Fragen zu Account-Berechtigungen, Pfaddesign, Hochverfügbarkeit, Kapazität und Betrieb blieben jedoch bestehen. Day-0-Automatisierung reduzierte die Einführungsreibung, beseitigte aber nicht die langfristigen Kontrollprobleme.

In Unternehmensunterlagen untermauerte eine namentliche Fallstudie mit Flexport den Anwendungsfall für AWS Cloud WAN. Dies ist ein Beleg dafür, dass ein Unternehmenskunde die Architektur befürwortete, jedoch keine unabhängige Prüfung von Bereitstellungsumfang, Kostensenkungen oder Verfügbarkeit. Kundenaussagen sollten als Adoptionsbeispiele und nicht als universelle Leistungsnachweise behandelt werden.

Azure und Google Cloud vervollständigten den Multi-Cloud-Anspruch

Prosimo unterstützte auch Microsoft Azure- und Google Cloud-Umgebungen. Die Produktunterlagen beschrieben die Orchestrierung rund um Azure Virtual WAN, Google Cloud Networking und private Dienstkonfigurationen. Das Ziel war, die nativen Netzwerke jedes Anbieters beizubehalten, aber ein einheitliches Betriebsmodell zu bieten.

Das Vorhandensein von Unterstützung beweist keine Funktionsgleichheit zwischen den Anbietern. Cloud-APIs reifen unterschiedlich schnell, und ähnliche Produktnamen können unterschiedliche Semantik haben. Routen, Segmente, private Endpunkte und Diensteinfügungen erfordern möglicherweise anbieterspezifische Behandlung. Aus den verfügbaren Unterlagen lässt sich keine funktionsweise Äquivalenztabelle über alle Regionen und Releases rekonstruieren.

Die Multi-Cloud-Abstraktion ist daher am ehesten als Übersetzungssystem zu verstehen. Sie kann gemeinsame Intentionen und Workflows standardisieren, muss aber Details offenlegen, die Sicherheit, Kosten und Fehler beeinflussen. Wenn nur die Oberfläche vereinheitlicht wird und Implementierungsunterschiede vor dem Betreiber verborgen bleiben, wird die Plattform gefährlich.

Dasselbe gilt nach der Übernahme. Palo Alto Networks könnte mithilfe des gemeinsamen Graphen Sicherheit über mehrere Clouds hinweg platzieren, aber die nativen Objekte, die die Pfade implementieren, werden von den Cloud-Anbietern kontrolliert. Der Besitz der Orchestrierungsschicht bedeutet nicht den Besitz des Cloud-Underlays.

Das Produkt entwickelte sich von Konnektivität zu Lebenszyklusmanagement

Bis 2023 beschrieb Prosimo Workflows zum Entwerfen, Aufbauen, Beheben von Störungen und Verwalten von Multi-Cloud-Netzwerken. Das Produkt ging über das Herstellen von Tunneln und Gateways hinaus. Die Asset-Erkennung unterstützte das Design, die Orchestrierung stellte die Konnektivität her, Karten und Telemetrie halfen bei der Fehlerbehebung, und Richtlinien sowie historische Zustände ermöglichten das fortlaufende Management.

Dieser Lebenszyklus-Rahmen erweiterte den Kreis potenzieller Käufer. Netzwerkingenieure konnten Topologie- und Pfadanalysen nutzen, Cloud-Infrastrukturteams konnten Konten und Dienste einbinden, Sicherheitsteams konnten Segmentierung und Inspektion überprüfen, Migrationsteams konnten Änderungen planen und FinOps-Teams die Auswirkungen auf Pfade und Egress-Kosten untersuchen. Je mehr Organisationen dieselben Evidenzen nutzten, desto höher wurde der Plattformwert.

Gemeinsame Evidenz schafft jedoch auch Governance-Konflikte. Eine zentrale Plattform könnte aufdecken, dass die nativen Einstellungen eines Cloud-Teams von den Unternehmensrichtlinien abweichen. Organisationen müssen entscheiden, welches System als maßgeblich gilt und wer Korrekturen genehmigt. Software allein kann dieses institutionelle Problem nicht lösen.

Das Lebenszyklus-Narrativ erhöhte auch die Wechselkosten. Wenn der Controller den Asset-Graphen, Richtlinien, Telemetrie, Edge-Platzierungen und Automatisierungsintegrationen vorhält, wird ein Austausch mehr als nur das Verlagern von Leitungen. Kunden müssen ihr Betriebsmodell exportieren oder neu aufbauen. Während Prosimo die Reduzierung der Cloud-Fragmentierung anpries, schuf es gleichzeitig die Möglichkeit einer Controller-Abhängigkeit.

Die Segmentierung erstreckte sich von Netzwerk-Erreichbarkeit bis zu Anwendungsrichtlinien

Prosimo postulierte Segmentierung von Layer 3 bis 7. Auf Netzwerkebene bestimmten Routing-Domänen und Segmente, welche Subnetze und Standorte kommunizieren dürfen. Auf höheren Ebenen verfeinerten Anwendungsidentität, Nutzerkontext und Transaktionsmerkmale die Regeln.

Ein hierarchisches Modell kann die Kluft zwischen Netzwerkzonen und Anwendungsrichtlinien verringern. Es könnte ermöglichen, breite Subnetz-Erreichbarkeit zu unterbinden und dennoch bestimmte Geschäftsdienste zuzulassen. Umgekehrt könnte eine Verbindung verweigert werden, selbst wenn der Netzwerkpfad erreichbar ist, sofern die Identität oder der Anwendungskontext nicht angemessen ist.

Damit wurde Prosimo jedoch nicht zu einer vollwertigen Next-Generation Firewall. In der Palo Alto Networks-Integration von 2024 waren die Verantwortlichkeiten getrennt: Prosimo orchestrierte Routing, Segmentierung und Diensteinfügung, während die VM-Series die tiefe Inspektion übernahm. Diese Unterscheidung ist wichtig, da richtliniengesteuertes Routing und Sicherheitsdurchsetzung auf unterschiedliche Weise scheitern können.

Segmentierung wirkt nur, wenn alle relevanten Pfade repräsentiert sind. Unbekannte Routen, cloudnative Ausnahmen oder eine fehlgeschlagene Diensteinfügung können die beabsichtigten Kontrollen umgehen. Die Zusicherung erfordert daher den Abgleich von deklarierten Richtlinien, Anbieterzuständen und beobachtetem Verkehr – nicht nur das Vertrauen in die Controller-Anzeige.

Diensteinfügung verknüpfte Routing-Kontrolle mit der Firewall-Ökonomie

Beim Cloud-Sicherheitsdesign muss entschieden werden, wo die Inspektion stattfindet. Eine zentrale Firewall vereinfacht Richtlinien und reduziert die Anzahl, kann aber Umwege, Konzentration und Skalierungsdruck verursachen. Verteile Firewalls können nahe an Workloads platziert werden und reduzieren Pfadverzerrungen, erhöhen jedoch Bereitstellungs-, Lizenz-, Update- und Richtlinienaufwand.

Prosimo unterstützte mit der VM-Series-Integration beide Konfigurationen. Richtlinien konnten ausgewählten Verkehr entweder zu einem zentralen Inspektionspunkt oder zu verteilten Firewalls in den Anwendungs-VPCs leiten. Palo Alto Networks lieferte die Inspektionsfunktion, während der Controller die umgebenden Routen aktualisierte.

Diese Architektur machte Routing-Orchestrierung kommerziell wertvoll für Sicherheitsanbieter. Eine Software-Firewall kann keinen Verkehr schützen, der sie nicht erreicht. Erkennung, Platzierung und Routenaktualisierung reduzieren die betriebliche Reibung vom Kauf von Sicherheitskapazität bis zur Einfügung in den Produktionspfad. Dies ist ein plausibler strategischer Grund für Palo Alto Networks, die Technologie von Prosimo zu übernehmen.

Gleichzeitig erweitert sich der Wirkungsbereich des Controllers. Eine fehlerhafte Richtlinie kann Inspektionen umgehen, Schleifen erzeugen, asymmetrisches Routing verursachen und Anwendungen zum Stillstand bringen. Ein Fehlschlagen der Diensteinfügung ist zugleich ein Netzwerkvorfall und ein Sicherheitsereignis, weshalb Health Checks, schrittweise Änderungen, Simulationen, Audits und Rollbacks erforderlich sind.

Die Partnerschaft von 2024 sollte nicht mit dem Übernahmezeitpunkt gleichgesetzt werden

Prosimo und Palo Alto Networks kündigten am 12. Juni 2024 die VM-Series-Integration an. Die Ankündigung beschrieb eine gemeinsame technische und kommerzielle Lösung, erwähnte jedoch keine Übernahme von Prosimo durch Palo Alto Networks. Diese Ankündigung als Eigentumsnachweis zu betrachten, würde zwei getrennte Ereignisse vermischen.

Dennoch fungierte die Partnerschaft als Brücke. Prosimo konnte demonstrieren, dass sein Routen- und Richtliniensystem die VM-Series leichter in mehrere Clouds einbringen kann. Palo Alto Networks konnte die Technologie anhand einer realen Integration bewerten, bevor es später zum Unternehmensübergang kam. Öffentliche Unterlagen beschreiben den Übernahmeprozess nicht, daher wäre die Behauptung, die Partnerschaft sei als formelle Vorstufe einer Übernahme konzipiert gewesen, Spekulation.

Anfang 2025 hatten sich die Karriereprofile von Gründern und Mitarbeitern verändert. Die Unternehmensseite zeigte später den Status „übernommen“ an. Ende 2025 erklärte Bhau, die Technologie sei vollständig in Palo Alto Networks-Produkte integriert. Zusammengenommen stützen diese Aufzeichnungen die Schlussfolgerung einer Übernahme, die rechtlichen Schritte bleiben jedoch ungeklärt.

Diese Abfolge ist sowohl für die redaktionelle Genauigkeit als auch für Kunden wichtig. Bei einer Partnerschaft gibt es zwei Anbieter, zwei Supportstrukturen und klare Integrationsgrenzen. Bei einer Übernahme können Roadmap, Daten, Verträge und Verantwortlichkeiten in eine Hand übergehen. Auch wenn der technologische Pfad anfangs ähnlich erscheint, betrifft der Übergang mehr als nur die Marke.

Nebula verwandelte den Topologiegraphen in eine dialogorientierte Schnittstelle

Im Februar 2024 stellte Prosimo Nebula als Teil einer AI Suite für Multi-Cloud-Networking vor. Der Assistent war darauf ausgelegt, Fragen in natürlicher Sprache zu Zuständen zu beantworten, die im Graphen und in der Telemetrie der Plattform abgebildet waren, etwa zu überlappenden Netzwerken, Kosten, Routing-Integrität und Sicherheitsrichtlinienverstößen.

Der nützliche Aktivposten war nicht die Sprachschnittstelle selbst, sondern der darunterliegende strukturierte cloudübergreifende Kontext. Ein generisches Modell kann nicht diagnostizieren, was es nicht sieht – private Routen oder Segmente. Nebula konnte auf das Inventar, die Topologie, die Richtlinien und die Beobachtungen zugreifen, die Prosimo bereits gesammelt hatte. Die vorherige Investition in einen gemeinsamen Graphen zahlte sich nun für AIOps aus.

Der dialogorientierte Zugriff kann komplexe Daten einem breiteren Kreis von Operatoren zugänglich machen. Er kann aber auch falsches Vertrauen schaffen, wenn nicht abgedeckte Assets aus den Antworten herausfallen, Fragen falsch interpretiert werden oder Empfehlungen als genehmigte Operationen behandelt werden. Hochriskante Änderungen erforderten weiterhin deterministische Kontrollen, Berechtigungsgrenzen und menschliche Bestätigung.

Prosimo gab an, die durchschnittliche Wiederherstellungszeit um 60–80 % senken und die Cloud-Networking-Kosten um mehr als 60 % reduzieren zu können. Dies sind unternehmenseigene Behauptungen aus Produktankündigungen. In den verfügbaren Unterlagen fehlen unabhängige Methoden oder Kundenreferenzwerte, die eine allgemeine Anwendbarkeit belegen könnten. Diese Zahlen können als von Prosimo dargestellte Vorteile zitiert werden, jedoch nicht als gemessene Marktfakten gelten.

KI-Workloads waren ein neuer Anwendungsfall, kein Nachweis eines neuen Marktes

Dieselbe Ankündigung von 2024 positionierte die Architektur von Prosimo auch für KI-Workloads als nützlich. Verteilte KI-Systeme erfordern möglicherweise privaten Zugriff auf Daten, Konnektivität zwischen Clouds und Rechenzentren, Compliance-Kontrollen und Routing, das das Anwendungsverhalten widerspiegelt. Diese Anforderungen decken sich mit dem bestehenden Asset-, Richtlinien- und Pfadmodell.

Ein neuer Name ändert nichts am Underlay. Prosimo blieb abhängig von Cloud-Netzwerken, Carriern und Kundeninfrastruktur. Es lieferte auch keine GPU-Compute- oder Modellentwicklungssoftware. Die vorgesehene Rolle war eine Konnektivitäts- und Sicherheitsschicht rund um verteilte Daten und Dienste.

Die Positionierung für KI war strategisch sinnvoll, da der Wert cloudübergreifender Topologien mit zunehmender Verteilung von Daten und Diensten steigt. Gleichzeitig war es eine Marketingkategorie, die erst kurz vor dem Ende des unabhängigen Betriebs eingeführt wurde. Die Unterlagen zeigen keine separaten Umsätze mit KI-Produkten, keine namentlich genannten Produktionsimplementierungen und keine geprüften Workload-Ergebnisse.

Der bleibende Punkt ist, dass Multi-Cloud-Telemetrie ein Input für maschinell unterstützten Betrieb sein kann. Die aktuelle Produktfrage ist, ob Palo Alto Networks diesen Kontext bewahrt hat und wie es die Funktionen bereitstellt. Die öffentliche Beweislage zum Stichtag der Recherche gibt keine vollständige Antwort.

Das Geschäftsmodell verkaufte Software auf fremder Infrastruktur

Während seiner unabhängigen Phase war Prosimo ein Software-Subskriptions- und Dienstleistungsgeschäft, kein Carrier. Kunden deployten den AXI Edge in ihrer eigenen Umgebung und verbanden ihre Cloud-Konten mit der Steuerungsebene. Der Umsatz stützte sich vermutlich auf Lizenzen oder Subskriptionen, Support, professionelle Dienstleistungen und Channel-Aktivitäten; genaue Preise und Vertragsmetriken werden in den verfügbaren Unterlagen jedoch nicht offengelegt.

Es war ein Modell, das ohne eigenes Glasfaser-Backbone skalieren konnte. Eine einzige Softwareplattform konnte zahlreiche Cloud-Regionen und Kundenumgebungen orchestrieren. Aus der Architektur allein lässt sich jedoch keine Bruttomarge ableiten. Die Anpassung an Anbieter-APIs, der Edge-Lebenszyklus, Sicherheitsintegration und die Unterstützung bei der Unternehmenseinführung verursachten Kosten, und die von den Edges verbrauchten Cloud-Ressourcen gingen wahrscheinlich zulasten des Kunden, nicht des Anbieters.

Prosimo erreichte Unternehmen über Cloud-Marktplätze, Integrationspartner, Vertriebskanäle und namentlich genannte Kundenreferenzen. Dies sind jedoch keine gleichwertigen Belege. Ein Marktplatzeintrag zeigt einen Beschaffungs- und Bereitstellungspfad. Eine technische Integration belegt, dass zwei Systeme unter definierten Bedingungen kombiniert werden können. Kundenkommentare zeigen Adoptionsbeispiele. Keiner dieser Punkte beweist für sich genommen die Anzahl zahlender Kunden oder wiederkehrende Umsätze.

Die große Reichweite erhöhte möglicherweise auch die Vertriebskomplexität. Obwohl Netzwerk-, Sicherheits-, Cloud- und Anwendungsteams profitieren konnten, war oft nicht klar, wer das Budget besitzt. Das Produkt benötigte einen Käufer, der bereit war, in eine gemeinsame Steuerungsebene zu investieren, anstatt jede Cloud und jedes Team separat agieren zu lassen.

Partner, Kunden und Investoren nahmen unterschiedliche Positionen ein

Amazon Web Services war Underlay-Anbieter und zugleich Integrationspartner für die Markteinführung. Azure und Google Cloud waren unterstützte Umgebungen. Identitätsprovider lieferten den Authentifizierungskontext, Firewall-Anbieter die Inspektion. Colocation-Betreiber und Carrier konnten Edges hosten und anbinden, und Channel-Partner konnten Implementierungen entwerfen und betreiben.

In den AWS Cloud WAN-Unterlagen erschien Flexport als namentliche Fallstudie. Dieses Beispiel belegt das Interesse eines Unternehmens an der Architektur, doch Umfang, Dauer und kommerzieller Wert der Implementierung gehen aus den Unterlagen nicht hervor. Es sollte nicht als Stellvertreter für den gesamten Kundenstamm verwendet werden.

General Catalyst führte die Series A an und war als Investor an der Governance beteiligt. In Unternehmensunterlagen tauchten Investoren mit Bezug zu WRVI oder Celesta auf, und spätere Prosimo-Mitteilungen erwähnten hochkarätige Investitionsbeteiligungen, darunter Namen mit BlackRock-Verbindung, doch die genauen Investmentvehikel wurden in der Recherche nicht geklärt. Diese Aufzeichnungen deuten auf eine einflussreiche Kapitalbasis hin, stellen jedoch keine vollständige Cap Table dar.

Die wichtigste Beziehung war Palo Alto Networks. Aus einem Sicherheitspartner im Jahr 2024 wurde Anfang 2025 der Käufer. Diese Abfolge zeigt, wie eine Ökosystem-Abhängigkeit in eine Kontrollbeziehung umschlägt, wenn eine Partei die Softwareschicht erwirbt, die den Pfad zu ihren Produkten orchestriert.

Mindestens 55 Millionen US-Dollar eingeworben, Exit-Bedingungen unbekannt

Die nachweisbaren Finanzierungsrunden sind die Series A über 25 Millionen US-Dollar im April 2021 und die Series B über 30 Millionen US-Dollar im Jahr 2022. Das ergibt insgesamt mindestens 55 Millionen US-Dollar. In den Unterlagen fehlen eine geprüfte Cap Table, Bewertungen, eine Schuldenaufstellung und Angaben zu weiteren Finanzierungsrunden.

Der Kaufpreis wurde weder veröffentlicht noch unabhängig bestätigt. Ohne einen Preis lässt sich das Ergebnis nicht verlässlich als strategische Prämie, begrenzter Technologiekauf, Acquihire oder Notverkauf einstufen. Die fortgesetzte Integration der Technologie in Produkte zeigt Wert, offenbart aber nicht die Renditen für Investoren und Gründer.

Umsätze oder Marktanteile von Palo Alto Networks nach der Übernahme sollten nicht Prosimo zugeschrieben werden. Sobald ein Start-up nicht mehr separat beobachtbar ist, gibt es keine eigenständigen Umsätze, Gewinne oder Kundensegmente, die analysiert werden könnten. Ein großer Eigentümer kann die Technologie breit einsetzen, macht aber deren individuelle Wirtschaftlichkeit undurchsichtig.

Das Fehlen einer formellen Übernahmeankündigung ist ebenfalls bedeutsam. Kunden, Mitarbeiter und Analysten entnehmen solchen Ankündigungen üblicherweise Zeitplan, Support und strategische Begründung. In diesem Fall muss der Status aus Karriereprofilen, dem Unternehmensseiteneintrag und späteren Gründeraussagen rekonstruiert werden. Das reicht aus, um zu korrigieren, dass es kein unabhängiges Unternehmen mehr ist, aber nicht, um Transaktionsdetails zu konstruieren.

Die Konkurrenz waren Spezialplattformen, Clouds und interne Entwicklung

Prosimo konkurrierte mit spezialisierten Multi-Cloud-Networking-Plattformen wie Aviatrix und Alkira, mit Enterprise-Networking- und SASE-Anbietern sowie mit den nativen Diensten von AWS, Azure und Google Cloud. Es konkurrierte auch mit dem Do-it-yourself-Modell von Unternehmen, die Infrastructure-as-Code, Cloud-Provider-Transitdienste, Routentabellen und Firewalls direkt nutzten. Jede Option löste einen anderen Teil desselben Problems.

Ein spezialisierter Controller kann ein einheitliches Topologie- und Richtlinienmodell über mehrere Anbieter hinweg anbieten. Ein cloudnatives Design reduziert Drittanbieterabhängigkeiten und kann eng auf einen einzelnen Anbieter abgestimmt werden. Carrier-gestützte Dienste können den physischen Transport liefern. Eine SASE- oder Sicherheitsplattform kann Konnektivität und Sicherheitsdurchsetzung integrieren. Interne Entwicklung erhält die Kontrolle, erhöht aber den Personal- und Integrationsaufwand.

Die Differenzierung von Prosimo lag in der Kombination aus Anwendungs- und Netzwerk-Transit, verteilten Edges, cloudnativer Orchestrierung, Topologie, Telemetrie und Diensteinfügung. Dieselbe Breite erschwerte aber den Vergleich. Käufer mussten mit den tatsächlich genutzten Cloud-Diensten, Routen, Identitätssystemen und Sicherheitskonfigurationen testen, anstatt nur Kategorienamen zu vergleichen.

Die Übernahme verändert den Wettbewerbsrahmen. Prosimo muss nicht mehr als unabhängiges Unternehmen gewinnen, aber seine Technologie muss innerhalb von Palo Alto Networks Wert beweisen. Die zu vergleichende Frage ist, ob die integrierte Erkennung und Routing-Orchestrierung die Bereitstellung von Palo Alto Networks-Sicherheitsprodukten verbessert und ob Kunden diese Plattformabhängigkeit akzeptieren.

Cloudnative Dienste waren Fundament und Alternative zugleich

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN und Google Cloud Networking boten Unternehmen leistungsfähige native Optionen. Prosimo war von ihnen abhängig und konkurrierte zugleich mit der Möglichkeit, dass Kunden sie direkt betreiben.

Diese Beziehung schuf eine bewegliche Grenze. Wenn Cloud-Anbieter globales Routing, Segmentierung, privaten Dienstzugriff und zentrale Richtlinien hinzufügten, wurden einige Drittanbieterfunktionen leichter nativ replizierbar. Gleichzeitig bedeutete jeder neue native Dienst mehr Objekte, die ein cloudübergreifender Controller erkennen und orchestrieren musste. Der Cloud-Fortschritt konnte einen Teil des Werts von Prosimo schmälern, während er den Bedarf an Anbieter-übergreifender Übersetzung erhöhte.

Die Entscheidungsfaktoren waren nicht nur technischer, sondern auch organisatorischer Natur. Ein Single-Cloud-Unternehmen mit starker interner Entwicklung würde eher native Tools wählen. Ein Multi-Cloud-Unternehmen mit fragmentierten Teams könnte eine einheitliche Steuerungsoberfläche schätzen. Organisationen in regulierten Branchen könnten eine dritte Evidenzschicht bevorzugen, aber auch Bedenken hinsichtlich privilegierter Zugangsdaten und Datenzentralisierung haben.

Keine Architektur beseitigt Lock-in vollständig. Native Tools erhöhen die Abhängigkeit von den APIs und der Semantik einer Cloud. Ein cloudübergreifender Controller erhöht die Abhängigkeit von Graphen, Richtlinien und Edge-Software. Die sinnvolle Frage war, ob diese Abhängigkeit sichtbar, portabel und mit dem Betriebsmodell der Organisation vereinbar ist.

Fehler konnten im Controller, Edge, Cloud-API, Identity und Underlay auftreten

Die verteilte Architektur von Prosimo reduzierte die Abhängigkeit von einem einzigen Traffic-Hub, schuf jedoch mehrere interagierende Fehlerdomänen. Zentrale Dienste konnten ausfallen und veraltete Intentionen vorhalten. Edges konnten versagen oder isoliert werden. Cloud-APIs konnten Teile einer Änderung ablehnen. Identitätsprovider konnten ausfallen. Das Underlay konnte Kapazität verlieren oder unerwartete Pfade nehmen. Eingefügte Firewalls konnten Ressourcen erschöpfen.

Besonders schwierig sind Teilausfälle. Ein Anbieter könnte eine Routenaktualisierung akzeptieren, ein anderer sie ablehnen. Der beabsichtigte Zustand des Controllers würde dann vom tatsächlichen Cloud-Zustand abweichen. Verkehr könnte asymmetrische Pfade nehmen und Inspektionen umgehen. Ein verlässliches System erfordert Abstimmung, idempotente Operationen, schrittweise Änderungen, explizite Fehlerzustände und Rollbacks, die ein anbieterspezifisches Verhalten berücksichtigen.

Die öffentliche Beweislage beschreibt Hochverfügbarkeit und Optimierung, enthält jedoch keine unabhängigen Fehlerinjektionstests, vollständige Vorfallaufzeichnungen oder universelle Service-Level-Ergebnisse. Resilienzbehauptungen sollten daher auf die dokumentierte Architektur oder auf namentliche Kundenimplementierungen bezogen werden.

Die Übernahme führt eine weitere Fehlerdomäne ein: die Produktkontinuität. Kunden müssen wissen, welche Konsole, API, Edge-Images, Richtlinienmodell und Support-Organisation das bisherige Prosimo-System ersetzen. Selbst wenn die Code-Integration technisch gelingt, bleibt das Migrationsrisiko bestehen, solange kommerzielle und betriebliche Grenzen unklar sind.

Durch Cloud-Anmeldeinformationen wurde der Controller Teil der kritischen Managementebene

Asset-Erkennung und Orchestrierung erforderten Zugriff auf Cloud-Konten. Ein schreibgeschütztes Inventar konnte mit eingeschränkten Rechten erstellt werden, für Änderungen an Routen, Segmenten und Diensteinfügungen waren jedoch starke Berechtigungen nötig. Der Controller befand sich daher innerhalb der privilegierten Managementebene, auch wenn er die Workloads nicht besaß.

Bei einer Kompromittierung der Anmeldeinformationen könnte die Topologie offengelegt und umfassende Änderungen ermöglicht werden. Ein Softwarefehler oder Bedienerfehler könnte Richtlinien über mehrere Clouds hinweg propagieren. Je nützlicher die Plattform wird, desto größer wird das Risiko. Mit jedem weiteren verwaltbaren Konto und Dienst wächst der potenzielle Wirkungsbereich.

Unternehmen benötigten Least-Privilege-Rollen, getrennte Anmeldeinformationen für Erkennung und Änderung, Mehr-Augen-Prinzip, vollständige Auditierung, Rotation, Notfall-Sperrung und Wiederherstellungspfade, die nicht allein vom selben Controller abhängen. Da öffentliche Unterlagen keine vollständige unabhängige Sicherheitsbewertung enthalten, sind dies Kontrollmaßnahmen, die bei der Einführung implementiert werden müssen, keine Produktgarantien.

Der Telemetrie-Graph ist ebenso sensibel. Er kann Anwendungsnamen, Netzwerkstrukturen, Richtlinien, Nutzerbeziehungen, Routenintegrität und Kostenmuster offenbaren. Die Governance nach der Übernahme sollte klären, wo diese Daten gespeichert werden, welche Palo Alto Networks-Produkte darauf zugreifen können und wie frühere Kundenberechtigungen überführt wurden. Die öffentliche Beweislage zum Recherchestichtag beantwortet diese Fragen nicht.

Die Übernahme verlagerte eine cloudneutrale Schicht in eine Sicherheitsplattform

Als unabhängiges Unternehmen konnte sich Prosimo als eine gemeinsame Schicht über Clouds und Sicherheitsdienste hinweg positionieren. Nachdem Palo Alto Networks Eigentümer wurde, ändern sich die Anreize. Die erworbene Technologie kann die Bereitstellung von Palo Alto Networks-Produkten wie der VM-Series erleichtern. Während sich das Integrationserlebnis verbessern könnte, entstehen neue Fragen hinsichtlich der Unterstützung von Inspektionsdiensten Dritter.

Allein der Eigentümerwechsel beweist keinen Verlust der Neutralität. Die verfügbaren Unterlagen enthalten keine aktuelle Partnerliste oder Produktarchitektur. Die Fragen, die sich Kunden stellen müssen, ändern sich jedoch. Sie müssen prüfen, ob der Routen-Controller mehreren Sicherheitsanbietern offensteht, ob Richtlinien und Telemetrie exportiert werden können und ob die Optimierung die Produktpalette des Eigentümers bevorzugt.

Die Integrationserklärungen betonten Ingress-, Egress- und Ost-West-Inspektion. Dieser Schwerpunkt legt nahe, dass die Topologie- und Orchestrierungsfunktionen von Prosimo Teil eines Sicherheitsbereitstellungssystems wurden. Sie beweisen jedoch nicht, dass die früheren Funktionen wie App Transit, Nutzerzugriff, Kostenoptimierung und sämtliche Cloud-Networking-Workflows als separate Funktionen erhalten blieben.

Dies ist ein wiederkehrendes Muster im Infrastruktursektor. Ein Start-up abstrahiert ein schwieriges Koordinationsproblem, und ein großer Plattformanbieter kauft es, weil diese Abstraktion die Nutzung und Kontrolle seiner Kernprodukte steigern kann. Der Käufer erhält einen Deployment-Pfad. Kunden erhalten Integration, könnten aber ein Stück Unabhängigkeit vom Anbieter verlieren.

Die größte Informationslücke ist die aktuelle Produktzuordnung

Die öffentlichen Aufzeichnungen bestätigen die Übernahme und Integration, zeigen aber nicht vollständig, wie AXI, Network Transit, App Transit, AIR und Nebula aktuellen Palo Alto Networks-Produkten oder SKUs zuzuordnen sind. Ehemalige Produkt-End-of-Life-Daten, Migrationsverfahren und eine funktionsweise Fortführungstabelle werden ebenfalls nicht veröffentlicht.

Aufgrund dieser Lücke ist eine aktuelle Produktbewertung nicht möglich. Die historischen Beschreibungen können zeigen, was Prosimo aufgebaut hat und warum es bedeutsam war, aber nicht, welche Funktionen derzeit verfügbar, lizenziert und unterstützt sind. Für aktuelle Deployment-Empfehlungen sind die gegenwärtigen Palo Alto Networks-Dokumente erforderlich, nicht frühere Prosimo-Ankündigungen.

Die fehlende Zuordnung schränkt auch die strategische Analyse ein. Die vollständige Absorption von Topologie-Graph und Orchestrierungsschicht unterscheidet sich von einer selektiven Nutzung nur für Asset-Erkennung und Firewall-Platzierung. Ersteres schafft einen breiten Multi-Cloud-Steuerungsdienst, letzteres beschleunigt primär die Sicherheitsbereitstellung. Die Aussage des Mitgründers stützt die technologische Kontinuität, löst diese architektonische Grenzfrage jedoch nicht auf.

Zukünftige Produktdokumentationen, Migrationsleitfäden und Kundenreferenzen könnten viel von der Unsicherheit beseitigen. Bis dahin ist die präzise Aussage, dass die Prosimo-Technologie laut Mitgründer in Palo Alto Networks-Produkte integriert wurde, Umfang und Paketierung jedoch unbestätigt sind.

Wer kontrolliert das Multi-Cloud-Routing?

Keine einzelne Partei kontrolliert den gesamten Pfad. Unternehmen verwalten das Eigentum an Konten, die geschäftliche Intention, das Anwendungsdesign und die erteilten Zugangsdaten. Ein cloudübergreifender Controller kann die Topologie erkennen, Richtlinien übersetzen, Pfade auswählen und native Routenzustände verändern. Cloud-Anbieter kontrollieren APIs, Transitdienste, private Endpunkte, Backbones und viele Fehlerdomänen. Carrier und Colocation-Anbieter kontrollieren andere Transportabschnitte. Sicherheitsdienste entscheiden, ob inspizierter Verkehr zugelassen wird.

Prosimo zielte auf die strategisch günstigste Zwischenposition. Es besaß nicht das Underlay, versuchte aber, den darauf liegenden Graphen und die Richtlinienübersetzung zu besitzen. Wer diese Schicht kontrolliert, kann bestimmen, welche Assets sichtbar sind, wie Segmente ausgedrückt werden, wo Edges platziert werden, welche Dienste den Verkehr inspizieren und welche Telemetrie als maßgeblich gilt. Dies kommt praktischer Routing-Autorität gleich, selbst wenn jemand anderes die Glasfaser besitzt.

Nach der Übernahme besitzt Palo Alto Networks die verbliebene Prosimo-Technologie und entscheidet, wie sie integriert, paketiert und weiterentwickelt wird. Cloud-Anbieter behalten die Hoheit innerhalb ihrer Umgebungen, und Unternehmen können Zugangsdaten widerrufen und andere Architekturen wählen. Wenn jedoch Topologie, Richtlinien und betriebliche Workflows vom Controller abhängen, wird ein Wechsel teuer.

Die Antwort ist daher nicht absolut, sondern mehrschichtig. Unternehmen delegieren Autorität, der Controller orchestriert, die Cloud- und Carrier-Underlays transportieren, und die Sicherheitsplattform setzt Richtlinien durch. Die Geschichte von Prosimo zeigt, dass sich der Besitz der Orchestrierungsschicht ändern kann, selbst wenn die Eigentümer der Cloud-Konten und physischen Pfade gleich bleiben.

Hauptquellen

Warum Prosimo auch nach der Übernahme relevant bleibt

Prosimo erfasste einen realen Wandel in der Infrastruktur. Die Einheit des Netzwerkbetriebs verschiebt sich von Geräten und Präfixen hin zu Anwendungen, Identitäten, Dienstabhängigkeiten und Richtliniengraphen. Cloudnative APIs machen Netzwerkzustände programmierbar, und verteilte Software-Edges machen den Durchsetzungspunkt von Richtlinien beweglich. Ein Controller, der über mehrere Clouds blickt, kann Operationen orchestrieren, die eine einzelne Cloud-Konsole nicht abdecken kann.

Das Unternehmen legte auch die Kosten dieser Orchestrierung offen. Eine gemeinsame Schicht erfordert privilegierte Anmeldeinformationen, kontinuierliche API-Wartung, präzise Erkennung, semantische Übersetzung, Telemetrie und Betriebsdisziplin. Während sie fragmentierte Arbeit reduziert, schafft sie einen neuen zentralen Punkt. Dasselbe System, das das Routing vereinfacht, kann die Auswirkungen einer einzigen Fehlentscheidung vergrößern.

Die Übernahme durch Palo Alto Networks machte das Kontrollproblem noch deutlicher. Networking und Sicherheit konvergieren um Diensteinfügung, Workload-Erkennung und Richtlinien herum. Ein Sicherheitsanbieter, der die Topologie kennt und Routen ändern kann, inspiziert nicht nur den ihm vorgelegten Verkehr – er kann auch mitbestimmen, welcher Verkehr wo zur Inspektion gelangt.

Prosimo sollte daher weder als gescheiterte unabhängige Marke noch als Beweis gesehen werden, dass eine Plattform Multi-Cloud gelöst hat. Der langfristige Beitrag liegt darin, den cloudübergreifenden Graphen als fundamentale Größe etabliert zu haben. Die verbleibende Frage ist, ob dieser Graph, nun im Besitz eines großen Sicherheitsunternehmens, genügend Transparenz, Portabilität und Kontrollierbarkeit bewahrt, um das Vertrauen der Kunden zu rechtfertigen.