Zusammenfassung

  • Prosimo wurde 2019 gegründet und nahm in den Finanzierungsrunden A von 2021 und B von 2022 mindestens 55 Millionen US-Dollar auf; geprüfte Umsatzdaten sowie Angaben zu Bewertung und Kaufpreis blieben unveröffentlicht
  • AXI verband zentrale Vorgaben, Topologie und Analyse mit verteilten Edges, die Cloud-Ressourcen erfassten, Anwendungen anbanden und Sicherheitsdienste einschleusten, ohne das physische Backbone zu besitzen
  • Auf die im Juni 2024 angekündigte VM-Series-Integration folgte Prosimos Übergang zu Palo Alto Networks etwa im Februar 2025; ein genaues Datum, der Preis und die heutige Produktzuordnung sind nicht belegt
  • Die Kontrolle verteilt sich weiterhin auf Unternehmen, Orchestrierungssoftware, Cloud-Anbieter und Palo Alto Networks; entscheidend ist deshalb, ob Topologie, Zugangsdaten, Richtlinien und Routingbefugnisse portierbar bleiben

Die Marke verschwand, das Problem blieb

Prosimo lässt sich 2026 nicht mehr als aktiver, unabhängiger Anbieter beschreiben. Öffentliche Berufsprofile zeigen, dass die Gründer und mehrere Beschäftigte etwa im Februar 2025 zu Palo Alto Networks wechselten. Prosimos Unternehmensprofil ist als übernommen gekennzeichnet, und der frühere Chief Technology Officer Nehal Bhau schrieb später, die Technologie sei in Produkte von Palo Alto Networks integriert worden. Die Belege zeigen einen Kontrollwechsel und einen fortbestehenden technischen Wert. Sie belegen weder das genaue Unterzeichnungs- oder Abschlussdatum noch die Rechtsform oder den Preis der Transaktion.

Diese Einordnung gehört an den Anfang, weil sie die Zeitform jeder Produktaussage verändert. AXI, Network Transit, App Transit, Application-driven Intelligent Results und Nebula waren dokumentierte Prosimo-Funktionen während der unabhängigen Phase. Sie sollten nicht als weiterhin separat vertriebene Produkte dargestellt werden, solange Palo Alto Networks keine aktuelle Produkt- und Supportzuordnung veröffentlicht. Eine historische Architektur kann nach einer Übernahme als eingebetteter Code, gemeinsamer Dienst, Modul oder internes Engineering-Asset fortbestehen; diese Formen sind nicht gleichbedeutend.

Das Verschwinden der Marke macht das zugrunde liegende Problem nicht überholt. Unternehmen verteilen Workloads weiterhin auf Amazon Web Services, Microsoft Azure, Google Cloud, private Rechenzentren, Colocation-Standorte, Software-as-a-Service-Plattformen und entfernte Nutzer. Jede Umgebung besitzt eigene Routen, Gateways, private Endpunkte, Identitätskontrollen, Sicherheitsdienste, Kontingente und Abrechnungsregeln. Ein Unternehmen kann die Konten besitzen und dennoch keine einheitliche Sicht darauf haben, wie eine Anfrage zwischen den Umgebungen verläuft.

Prosimos Bedeutung liegt in dem Versuch, diese Sicht in einer gemeinsamen Steuerungsschicht zusammenzuführen.

Die Übernahme bildet deshalb den erzählerischen Kern und nicht nur einen Epilog. Prosimo baute eine cloudübergreifende Steuerungsschicht, die Ressourcen erkennen, Anwendungskontext auswerten und Verkehr durch Sicherheitsdienste lenken konnte. Palo Alto Networks trat zunächst als technischer Partner auf, dessen VM-Series-Firewalls in diese Pfade eingeschleift werden konnten. Später übernahm Palo Alto Networks die Technologie. Damit verlagerte sich die Grenze zwischen Routing-Orchestrierung und tiefgreifender Sicherheitsinspektion in eine einzige Cybersecurity-Plattform.

Beim Multi-Cloud-Routing entscheidet der Kontext

Eine Routing-Tabelle kann beantworten, ob ein Präfix über einen bestimmten nächsten Hop erreichbar ist. Für sich allein erklärt sie nicht, welche Anwendung ein Nutzer aufrufen wollte, ob der Anfragende vertrauenswürdig ist, ob ein Inspektionsdienst den Verkehr sehen muss, ob ein privater Endpunkt verfügbar ist, ob ein Cloud-Pfad teurer ist als ein anderer oder ob eine Transaktion nach der Paketzustellung scheitert. Multi-Cloud-Betrieb macht diese Fragen zu einem gemeinsamen Kontrollproblem.

Prosimos These lautete, dass Routingentscheidungen auf mehr als der Erreichbarkeit auf Layer 3 beruhen sollten. Die Software versuchte, Cloud-Inventar, Netzwerkzustand, Anwendungsidentität, Nutzeridentität, Risiko, Leistung und Transaktionstelemetrie zu kombinieren. Dieser breitere Kontext erlaubte Richtlinien, die eine bestimmte Anwendung verbinden, ein Segment trennen, einen Ingress-Punkt wählen oder ausgewählten Verkehr durch eine Firewall lenken. Der Wert entstand nicht durch einen neuen Glasfaserpfad, sondern durch die Entscheidung, wie vorhandene Pfade und Dienste zusammengesetzt werden sollten.

Dieser Unterschied erklärt den Ausdruck „application experience infrastructure“. Der Begriff rückte die Anwendungsanfrage in den Mittelpunkt, nicht das einzelne Netzwerkobjekt. Eine VPC, ein VNet, ein Subnetz, ein Transit-Hub oder ein privater Link wurde zu einem Bestandteil eines Ende-zu-Ende-Pfads und nicht zum letzten Verwaltungsobjekt. Der Ansatz zog das Produkt zugleich in mehrere Märkte: Cloud-Netzwerke, Application Delivery, Zero-Trust-Zugriff, Network Assurance, Kostenoptimierung und Einschleifung von Sicherheitsdiensten.

Die Breite erzeugte Chancen und Unschärfe. Ein Produkt, das mehrere Teams berührt, kann Koordinationsprobleme lösen, für die sich kein einzelnes Team verantwortlich fühlt. Es ist jedoch schwerer zu bewerten, weil Netzwerk-, Sicherheits-, Cloud-, Anwendungs- und Finanzteams Erfolg unterschiedlich definieren. Prosimo musste zeigen, dass ein cloudübergreifendes Modell den Betrieb verbessert, ohne eine weitere privilegierte Schicht zu schaffen, deren Fehler sich auf jede Umgebung auswirken.

Was Prosimo war und was davon geblieben ist

Prosimo war ein 2019 gegründetes, privat gehaltenes Cloud-Networking-Softwareunternehmen aus der San Francisco Bay Area. Ramesh Prabagaran war Mitgründer und Chief Executive Officer, während Nehal Bhau in der unabhängigen Phase als Mitgründer und Chief Technology Officer tätig war. Öffentliche Profile nennen außerdem Linus Aranha und Pradeep Aragonda in Gründungs- oder leitenden Engineering-Funktionen; ihre genauen Titel sollten jedoch an datierte Biografien gebunden bleiben.

Die Hauptplattform hieß Application eXperience Infrastructure, meist AXI genannt. AXI nutzte eine zentrale Softwareschicht für Vorgaben, Topologie, Analyse und Orchestrierung sowie verteilte AXI Edges in Cloud-Regionen, Colocation-Umgebungen oder angrenzender On-Premises-Infrastruktur. Später strukturierte Prosimo das Angebot als Full-Stack Cloud Transit, wobei Network Transit und App Transit unterschiedliche Konnektivitätsklassen abdeckten. AIR analysierte Telemetrie und lieferte betriebliche Erkenntnisse; Nebula ergänzte 2024 eine dialogorientierte Oberfläche.

Prosimo war kein Cloud-Carrier. Das Unternehmen besaß kein globales Glasfaser-Backbone, das alle Regionen verband. Pfade konnten über Backbones der Cloud-Anbieter, das öffentliche Internet, Direktverbindungen, Colocation-Links und Unternehmensnetze führen. Prosimo war auch kein Firewall-Anbieter im gleichen Sinn wie Palo Alto Networks. Seine Rolle in der Integration von 2024 bestand in Ressourcenerkennung, Segmentierung und Verkehrssteuerung; die VM-Series übernahm die tiefgehende Sicherheitsinspektion.

Nach der Übernahme ist „technologische Kontinuität“ die präziseste Beschreibung. Die spätere Integrationsaussage betonte die Erkennung von Multi-Cloud-Ressourcen und eine schnellere Bereitstellung von Software-Firewalls für Ingress-, Egress- und Ost-West-Inspektion. Das belegt, dass wichtige Prosimo-Komponenten fortbestehen. Es belegt nicht, dass der gesamte historische AXI-Katalog, die kommerzielle Verpackung oder das Supportmodell unverändert weitergeführt wurden.

Das Problem nach SD-WAN

Das Gründerteam brachte Erfahrung mit großskaligen Netzwerken, Application Delivery und Cloud-Infrastruktur mit. Prosimo entstand auch aus dem weiteren Gründer- und Engineering-Umfeld von Viptela, jenem Unternehmen, das Software-defined WAN als Unternehmenskategorie etablieren half. Das nächste Problem lag jedoch an anderer Stelle. SD-WAN konnte vereinfachen, wie Niederlassungen Netzwerke und Anwendungen erreichten, schuf jedoch kein einheitliches Betriebsmodell innerhalb mehrerer Public Clouds und über deren Grenzen hinweg.

Eine Multi-Cloud-Anwendung kann von einem Web-Endpunkt in einer Umgebung, einer Datenbank oder einem Managed Service in einer anderen, einem externen Identitätsanbieter, einer privaten Rechenzentrumsverbindung und einer Sicherheitsinspektion an ausgewählten Grenzen abhängen. Jede Abhängigkeit kann als anderes natives Objekt erscheinen. Das Netzwerkteam sieht Präfixe und Transit-Hubs; das Cloud-Team sieht Konten und Ressourcenobjekte; der Anwendungsverantwortliche sieht Domains und Transaktionen; das Sicherheitsteam sieht Zonen und Inspektionsrichtlinien.

Prosimo setzte bei der Anfrage an, nicht bei der Niederlassung. Entscheidend war, wie ein Nutzer oder Workload eine Anwendung mit vertretbarer Sicherheit, Leistung, Verfügbarkeit und Kosten erreichen sollte. Dadurch verschob sich der Gegenstand der Routingentscheidung vom Zielpräfix allein zu einer Transaktion mit Identitäts- und Anwendungskontext. Zugleich musste die Plattform wesentlich mehr Informationen sammeln und pflegen als ein konventioneller Router.

Der Markteintritt kam zu einem günstigen Zeitpunkt. AWS, Azure und Google Cloud bauten native Transit- und Private-Connectivity-Dienste aus. Unternehmen konnten anspruchsvolle Netzwerke innerhalb eines Anbieters errichten, doch APIs, Objekte und Richtlinienmodelle blieben anbieterspezifisch. Prosimos Chance lag darin, diese Dienste zu koordinieren, statt jeden Kunden zu zwingen, sie durch ein separates proprietäres Backbone zu ersetzen.

Von der Gründung 2019 bis zum öffentlichen Start 2021

Prosimo wurde 2019 gegründet, kündigte seinen öffentlichen Start aber erst am 6. April 2021 an. General Catalyst führte dabei eine Series A über 25 Millionen US-Dollar an. Der Investor beschrieb die Gelegenheit als Bereitstellung eines konsistenten Anwendungserlebnisses über mehrere Clouds hinweg; dies entsprach dem Versuch der Gründer, eine Kategorie jenseits herkömmlicher Niederlassungskonnektivität zu definieren.

Der Marktstart führte das Unternehmen in ein dicht besetztes und noch ungeklärtes Segment. Cloud-Anbieter erleichterten den Bezug eigener Netzwerkdienste. SD-WAN- und SASE-Anbieter erweiterten Richtlinien in Cloud-Umgebungen. Application-Delivery-Anbieter konnten Anfragen optimieren, Netzwerksicherheitsunternehmen sie untersuchen. Prosimos Argument beruhte darauf, diese Funktionen in einer cloudorientierten Architektur zu verbinden, ohne zu behaupten, jedes umgebende System zu ersetzen.

Die Finanzierung schuf Spielraum für Integrationen, Software-Edges, Analytik, eine Vertriebsorganisation und Partnerbeziehungen. Sie bewies weder Product-Market-Fit noch Umsatzgröße oder dauerhafte Differenzierung. Die bereitgestellten Belege enthalten weder geprüfte Umsatzdaten noch Angaben zum Annual Recurring Revenue, zur Kundenzahl oder zur Bewertung. Der Finanzierungsverlauf zeigt Investorenvertrauen in eine These, nicht die vollständige Betriebsleistung.

2022 schloss Prosimo eine als überzeichnet beschriebene Series B über 30 Millionen US-Dollar ab. Die beiden eindeutig identifizierten Runden ergeben eine verifizierte Finanzierung von mindestens 55 Millionen US-Dollar. Manche Datenbanken können einen höheren Betrag ausweisen, wenn sie Ankündigungen oder zugehörige Datensätze doppelt zählen; solche Summen sollten ohne Auflösung der zugrunde liegenden Ereignisse nicht verwendet werden.

AXI legte Richtlinien über die Clouds und die Ausführung nahe an die Workloads

Die AXI-Architektur verteilte Aufgaben auf eine zentrale Steuerungs- und Analyseschicht sowie verteilte Software-Edges. Die zentrale Schicht verwaltete Anwendungs- und Netzwerkvorgaben, erkannte Ressourcen, führte die Topologie zusammen, integrierte Identität, analysierte Telemetrie und orchestrierte Änderungen. AXI Edges wurden nahe bei Workloads oder Nutzern platziert, damit Richtlinien umgesetzt werden konnten, ohne jeden Pfad durch einen entfernten physischen Hub zu zwingen.

Die Trennung ähnelt anderen softwaredefinierten Systemen, doch die Objekte waren Cloud-spezifisch und anwendungsbezogen. Der Controller brauchte Zugriff auf Cloud-Konten und APIs, während der Edge Konnektivität zu nativen Transitdiensten, Workload-Netzen, privaten Endpunkten oder externen Pfaden benötigte. Die Autorität der Plattform entstand aus der Kombination beider Sichten: globale Vorgaben oberhalb der Clouds und lokale Ausführung nahe am relevanten Verkehr.

Die Architektur schuf auch eine praktische Bereitstellungsgrenze. Jeder Edge verbrauchte Cloud-Ressourcen, benötigte Hochverfügbarkeitsdesign und musste aktualisiert, überwacht und geschützt werden. Die Steuerungsschicht brauchte Zugangsdaten mit ausreichenden Rechten, um Ressourcen zu erkennen und Netzwerkzustand zu verändern. Der Kunde gewann einen gemeinsamen Workflow, fügte jedoch ein Managementsystem hinzu, dessen Verfügbarkeit und Korrektheit für die Erreichbarkeit produktiver Anwendungen entscheidend waren.

Prosimo verwendete mitunter den Begriff „autonomes Cloud-Networking“. Belegt sind Automatisierung, Empfehlungen und API-gesteuerte Orchestrierung. Nicht belegt ist ein Netz, das unabhängig von menschlichen Vorgaben, den Diensten der Cloud-Anbieter oder dem zugrunde liegenden Transport arbeitet. Betreiber definierten weiterhin die Vorgaben, genehmigten Zugriffe, lösten Ausnahmen und trugen Verantwortung für das Ergebnis.

Ein AXI Edge war eine Platzierungsentscheidung, keine gewöhnliche Appliance

Ein AXI Edge konnte in einer Cloud-VPC oder einem VNet, in einer Colocation-Umgebung oder in angrenzender Infrastruktur bereitgestellt werden. Die technische AWS-Dokumentation zeigte eine Edge-VPC, die über Transit Gateway mit Workload-VPCs verbunden war, mit optionaler Firewall-Verkettung und Zugriff von entfernten Nutzern oder On-Premises-Standorten. Das Design platzierte Prosimos Ausführungspunkt in die Cloud-Topologie und nicht an einen entfernten Unternehmensperimeter.

Die Platzierung beeinflusste mehr als nur die Latenz. Sie bestimmte, wo Verkehr in die Richtliniendomäne eintrat, welches Cloud-Backbone oder welchen Internetpfad er nutzte, wo Verschlüsselung und Inspektion stattfanden und welche Telemetrie die Plattform sammeln konnte. Ein ungünstig platzierter Edge konnte Umwege oder Kosten verursachen; ein gut platzierter Edge konnte den Pfad verkürzen oder Verkehr nahe am Workload halten.

Die verteilte Platzierung vergrößerte die Zahl der zu beherrschenden Fehlerdomänen. Kapazität, Softwarestände, Cloud-Zonendesign, Routenkonvergenz und Zugriffsrechte konnten sich je Region unterscheiden. Hochverfügbarkeit bedeutete mehr als zwei Instanzen: Auch Controller, Cloud-Routingtabellen, Sicherheitsdienste und Rückwege mussten einen konsistenten Failover-Zustand abbilden.

Der Edge war deshalb Teil eines umfassenderen Betriebssystems. Sein Wert hing davon ab, dass Ressourcenerkennung, Topologie, Richtlinien und Analysen mit der umgebenden Cloud-Umgebung konsistent blieben. Wer ihn als eigenständige virtuelle Appliance betrachtet, verfehlt die Architektur, die Prosimo verkaufen wollte.

Das Underlay-Netz blieb in fremder Hand

Prosimo koordinierte den Transport, besaß aber weder das Underlay-Netz noch den physischen Pfad. Ein Anwendungspfad konnte das AWS-Backbone oder das Backbone eines anderen Cloud-Anbieters, das öffentliche Internet, Direct Connect oder ExpressRoute, Colocation, eine Carrier-Verbindung oder ein Unternehmensnetz nutzen. Die Plattform konnte zwischen verfügbaren Optionen wählen und sie orchestrieren; sie konnte Latenz, Paketverlust, Ausfallbereiche oder Preismodelle dieser Anbieter nicht beseitigen.

Diese Grenze ist für Leistungsangaben entscheidend. Ein Controller kann einen beobachtbar besseren Pfad wählen oder den Ingress näher zum Nutzer bringen. Er kann nicht garantieren, dass ein Carrier nicht ausfällt, eine Cloud-Region verfügbar bleibt oder eine externe Abhängigkeit schnell antwortet. Zur Anwendungserfahrung gehören außerdem DNS, Serververarbeitung, Storage, Browserverhalten und Drittdienste außerhalb der direkten Kontrolle des Netzwerkcontrollers.

Das fehlende proprietäre Backbone war nicht nur eine Schwäche. Prosimo konnte Infrastruktur nutzen, die Unternehmen bereits bezahlten, und von den Investitionen der Cloud-Anbieter profitieren. Prosimo konnte Regionen ohne eigenen Glasfaserausbau erreichen und native Systeme wie AWS Cloud WAN koordinieren. Der Preis dafür war Abhängigkeit von API-Stabilität, Dienstkontingenten, kommerziellen Bedingungen und anbieterspezifischer Semantik.

Der Anspruch der Plattform betraf daher operative Kontrolle, nicht physisches Eigentum. Sie sollte heterogene Underlays zu einem verwalteten System zusammenführen und deren native Vorteile erhalten. Ob die Abstraktion Lock-in verringerte oder lediglich verlagerte, hing von der Portabilität von Richtlinien, Topologie und Edge-Bereitstellung ab.

Network Transit regelte Erreichbarkeit zwischen Netzwerkobjekten

Network Transit konzentrierte sich auf VPCs, VNets, Subnetze, Regionen, Standorte und Segmente. Es koordinierte native Cloud-Transit- und Routingobjekte, damit Teams Konnektivität über einen gemeinsamen Workflow aufbauen konnten, statt jeden Anbieter separat zu konfigurieren. Das Produkt erfüllte die konventionelle Netzwerkanforderung: Ein Quellpräfix oder -segment muss ein Ziel über einen erlaubten Pfad erreichen.

Damit war nicht behauptet, Cloud-Unterschiede verschwänden. AWS, Azure und Google Cloud stellen unterschiedliche Objekte, Kontingente und Routingverhalten bereit. Überlappende Adressräume, asymmetrische Pfade, private Endpunkte und anbieterspezifische Grenzen erforderten weiterhin Engineering. Prosimo konnte gemeinsame Vorgänge normalisieren und Beziehungen zeigen; die Basissysteme behielten ihre eigenen Einschränkungen.

Network Transit übernahm auch die Segmentierung. Routingdomänen und Richtlinien konnten Umgebungen trennen oder Erreichbarkeit begrenzen. Der Controller musste verstehen, wo ein Segment über Clouds hinweg existierte und wie native Objekte die Grenze umsetzten. Eine einmal formulierte Richtlinie konnte dennoch mehrere anbieterspezifische Änderungen auslösen.

Der Vorteil war eine einheitliche Oberfläche für Richtlinienvorgaben. Das Risiko lag in der Übersetzung zwischen dem gemeinsamen Modell und den nativen Cloud-Konfigurationen. Wenn die gemeinsame Richtlinie und die Cloud-Konfiguration auseinanderliefen, konnte das Unternehmen ein Segment für geschützt halten, obwohl der Anbieterzustand etwas anderes sagte. Abgleich, Audit und klare Fehlermeldungen waren daher ebenso wichtig wie der anfängliche Bereitstellungsworkflow.

App Transit machte die Anwendung zum Gegenstand der Routingentscheidung

App Transit erweiterte das Modell über Subnetze hinaus. Es konnte Anwendungsdomäne, Identität, Anfragetyp, Transaktionszustand, Risiko und Leistung in die Entscheidung darüber einbeziehen, wie ein Nutzer oder Workload einen Dienst erreichte. Dies war Prosimos deutlichster Versuch, die Plattform von einem herkömmlichen Cloud-Router abzugrenzen.

Die Anwendungssicht war nützlich, weil moderne Dienste nicht immer sauber durch feste Adressen dargestellt werden. Managed Services, SaaS-Endpunkte und verteilte Komponenten können sich ändern, während die Anwendungsidentität aussagekräftig bleibt. Eine Richtlinie, die auf Dienst oder Nutzer verweist, kann beständiger sein als eine Regel, die nur auf Adressen und Ports basiert.

Das Modell verlangte eine präzise Zuordnung. Der Controller musste wissen, welche Domains und Endpunkte zu einer Anwendung gehörten, welche Abhängigkeiten benötigt wurden und welchen Aussagen des Identitätsanbieters vertraut werden konnte. Veraltetes Mapping konnte eine Anfrage über den falschen Pfad leiten oder die falsche Sicherheitsregel anwenden. Die Anwendungsabstraktion beseitigte die Notwendigkeit, den Netzwerkzustand zu verstehen, nicht; sie legte eine weitere semantische Schicht darüber.

Die Kombination von Network Transit und App Transit erkannte an, dass in Unternehmen beide Welten nebeneinander bestehen. Legacy-Systeme, private Subnetze und IP-basierte Kontrollen bleiben bestehen, während neuere Anwendungen auf Domains, Identität und Managed Services angewiesen sind. Full-Stack Cloud Transit war der Produktname für den gemeinsamen Betrieb dieser Modelle, nicht für die Ablösung des einen durch das andere.

Identität erweiterte die Routingentscheidung und die Vertrauensgrenze

Anwendungsbezogener Zugriff verlangte eine Integration der Identität. Die Plattform konnte Nutzer- oder Workload-Kontext verwenden, um zu entscheiden, ob und wie eine Verbindung aufgebaut werden sollte. Das stützte eine Zero-Trust-Richtlinie, in der allein der Standort keinen ausreichenden Autoritätsnachweis darstellte.

Identität erhöhte Präzision und schuf eine weitere Abhängigkeit. Die Routing- oder Anwendungsrichtlinie war nun vom Identitätsanbieter, seinen Aussagen, dem Sitzungszustand und Gruppendaten abhängig. Ein Netzwerkpfad konnte wegen nicht verfügbarer Authentifizierung oder eines geänderten Attributs scheitern, obwohl Router und Edges ordnungsgemäß funktionierten. Die Fehlersuche musste die Grenze zwischen Netzwerk- und Identity-Betrieb überschreiten.

Der Controller wurde außerdem zum Konzentrationspunkt für sensiblen Kontext. Er konnte Topologie, Anwendungsbeziehungen, Nutzerattribute, Risikosignale und Richtlinienergebnisse speichern. Dieser Datensatz verbesserte Diagnose und Optimierung, vergrößerte aber die Folgen unbefugten Zugriffs. Least Privilege, Aufbewahrung, Audit und Funktionstrennung waren deshalb Architekturanforderungen, keine administrativen Nachträge.

Prosimos Ansatz verdeutlicht eine umfassendere Veränderung der Infrastruktur. Routing- und Zugriffsrichtlinien hängen zunehmend von Identität und Anwendungssemantik ab. Je mehr Kontext eine Plattform sieht, desto nützlicher können ihre Entscheidungen werden – und desto sorgfältiger muss ihre Autorität kontrolliert werden.

Ressourcenerkennung schuf den Graphen, von dem jede spätere Entscheidung abhing

Ein cloudübergreifender Controller kann nicht verwalten, was er nicht sieht. Prosimo entwickelte Cloud-Asset-Discovery und Karten für VPCs, VNets, Subnetze, Anwendungen, Konnektivität und Sicherheitsbeziehungen. Diese Ansichten unterstützten Onboarding, Design, Fehlersuche und Richtlinien.

Die Erfassung war strategisch wichtig, weil sich Cloud-Landschaften außerhalb zentraler Netzwerk-Workflows verändern. Anwendungsteams können Konten, Netzwerke, Endpunkte und Managed Services durch eigene Automatisierung erzeugen. Manuell gepflegte Diagramme veralten. Ein API-basiertes Inventar kann einen aktuelleren Graphen erzeugen, dessen Vollständigkeit jedoch von Kontenabdeckung, Berechtigungen, Parserlogik und Anbieter-APIs abhängt.

Der Graph war nicht nur Dokumentation. Er war die Datenstruktur, aus der Routing, Segmentierung, Service Insertion und Optimierung berechnet wurden. Fehlte eine Ressource oder Abhängigkeit, konnten alle darüber liegenden Schlussfolgerungen falsch sein. Die Topologie brauchte daher Herkunftsnachweise: Zeitpunkt der Erhebung, Quellkonto, abgedeckte Regionen und fehlgeschlagene Anfragen.

Der Graph hilft auch, die Übernahme zu erklären. Palo Alto Networks kann zusätzlichen Sicherheitswert schaffen, wenn es weiß, wo Workloads und Verkehrspfade liegen. Ein System, das Cloud-Ressourcen entdeckt und Routen ändern kann, verkürzt den Weg vom Kauf einer Software-Firewall zu ihrer richtigen Platzierung. Bhau betonte später ausdrücklich die Ressourcenerkennung und die beschleunigte Bereitstellung von Software-Firewalls.

AIR leitete aus Edge-Telemetrie betriebliche Empfehlungen ab

Application-driven Intelligent Results, kurz AIR, analysierte Telemetrie der AXI Edges. Die AWS-Dokumentation beschrieb Einblicke in Round-Trip-Zeit, Verarbeitungszeit, Anwendungsantwortzeit, Transaktionstyp, Risiko und Richtlinienergebnis. Die Plattform konnte Nutzer-, Netzwerk- und Anwendungsdaten korrelieren, statt isolierte Gerätezähler zu präsentieren.

Diese Korrelation griff ein bekanntes Betriebsproblem auf. Eine langsame Transaktion kann auf dem Nutzerpfad, am Edge, im Cloud-Backbone, im Sicherheitsdienst oder in der Anwendung selbst verursacht werden. Eine schichtübergreifende Sicht kann die Suche schneller eingrenzen als getrennte Konsolen und Empfehlungen zu Pfad, Platzierung, Risiko oder Kosten unterstützen.

Die Qualität einer Empfehlung hing von der Telemetrieabdeckung und dem Interpretationsmodell ab. Ein Edge sah nur Verkehr, der ihn durchquerte. Externe Anwendungsabhängigkeiten und anbieterinterne Zustände konnten unsichtbar bleiben. Eine Empfehlung konnte die Richtung weisen, ohne die Ursache zu beweisen.

Telemetrie hatte auch einen Wert für die Governance. Historische Beobachtungen konnten erklären, warum sich eine Route oder Richtlinie geändert hatte. Sie konnten zugleich sensible Informationen über die Anwendungsnutzung und das Nutzerverhalten offenlegen. Öffentliches Material beschreibt Aufbewahrung und Daten-Governance nach der Übernahme nicht vollständig; diese Punkte bleiben Teil der Due Diligence von Kunden.

AWS lieferte die klarste dokumentierte Implementierung

Prosimos AWS-Arbeit erzeugte die stärksten öffentlichen technischen Belege. Das Unternehmen unterstützte AWS Transit Gateway, Cloud WAN, PrivateLink und den Deployment-Workflow von Marketplace for Containers Anywhere. AWS veröffentlichte eine Anleitung zu AXI-Edge-Platzierung, Anwendungs-Onboarding, Identität, Sicherheit und Optimierung.

AWS Cloud WAN war besonders bedeutsam. Es lieferte ein Cloud-natives Backbone und einen Segmentierungsdienst, den Prosimo orchestrieren statt ersetzen konnte. Diese Architektur zeigte das kooperative Modell: AWS besaß das native Netz und die globale Infrastruktur; Prosimo lieferte cloudübergreifende Vorgaben, Anwendungskontext, Edge-Software und Analyse.

Der Marketplace-Workflow vereinfachte den ersten Bereitstellungsschritt, indem AXI Edge über einen genehmigten Kanal paketiert wurde. Die spätere Arbeit an Kontoberechtigungen, Routingdesign, Hochverfügbarkeit, Kapazität und Betrieb blieb bestehen. Day-Zero-Automatisierung kann Installationsaufwand senken, ohne das langfristige Kontrollproblem zu beseitigen.

Eine namentlich genannte Flexport-Referenz stützte den AWS-Cloud-WAN-Anwendungsfall in Unternehmensmaterial. Sie belegt, dass ein Unternehmenskunde die Architektur öffentlich unterstützte, ist aber keine unabhängige Prüfung von Umfang, Einsparungen oder Verfügbarkeit. Kundenstimmen sollten daher als Adoptionsbeispiele und nicht als allgemeiner Leistungsnachweis dienen.

Azure und Google Cloud vervollständigten das Multi-Cloud-Angebot

Prosimo unterstützte auch Microsoft Azure und Google Cloud. Produktmaterial beschrieb die Orchestrierung von Azure Virtual WAN sowie Google-Cloud-Netzwerk- und Private-Service-Objekte. Ziel war ein gemeinsames Betriebsmodell, während das native Netz jedes Anbieters bestehen blieb.

Die Unterstützung dieser Plattformen beweist keine identischen Funktionen. Cloud-APIs reifen unterschiedlich schnell, und vergleichbare Produktnamen können unterschiedliche Semantik verbergen. Routen, Segmente, private Endpunkte und Service Insertion konnten eine anbieterspezifische Behandlung verlangen. Die vorliegenden Belege erlauben keine vollständige Funktionsvergleichsmatrix für alle Regionen und Releases.

Multi-Cloud-Abstraktion lässt sich daher am besten als Übersetzungssystem verstehen. Sie kann gemeinsame Vorgaben und Arbeitsabläufe standardisieren, muss jedoch die Details bewahren, die Sicherheit, Kosten und Ausfälle beeinflussen. Eine Plattform wird riskant, wenn die Oberfläche einheitlich wirkt und Implementierungsunterschiede vor Betreibern verborgen bleiben.

Dasselbe gilt nach der Übernahme. Palo Alto Networks kann den gemeinsamen Graphen für die Platzierung von Sicherheitskontrollen über mehrere Clouds hinweg nutzen, doch die Cloud-Anbieter kontrollieren weiterhin die nativen Objekte, die den Pfad umsetzen. Eigentum an der Orchestrierungsschicht schafft kein Eigentum am Cloud-Underlay.

Das Produkt entwickelte sich von Konnektivität zu einem Lebenszyklusmodell

Bis 2023 beschrieb Prosimo Workflows für Entwurf, Aufbau, Fehlersuche und Betrieb von Multi-Cloud-Netzen. Das Produkt ging über die Einrichtung einzelner Tunnel oder Gateways hinaus. Die Ressourcenerkennung stützte das Design; Orchestrierung schuf Konnektivität; Karten und Telemetrie halfen bei der Fehlersuche; Richtlinien und historische Zustände unterstützten die laufende Verwaltung.

Die Lebenszyklusperspektive erweiterte den Kreis potenzieller Käufer. Netzwerkingenieure konnten Topologie und Pfadanalyse nutzen; Cloud-Plattformteams Konten und Dienste einbinden; Sicherheitsteams Segmentierung und Inspektion prüfen; Migrationsteams Änderungen planen; FinOps-Teams Routing- und Egress-Auswirkungen untersuchen. Der Wert der Plattform stieg, wenn mehrere Gruppen auf denselben Datenbestand zugriffen.

Eine gemeinsame Datengrundlage kann Governance-Konflikte auslösen. Eine zentrale Plattform kann zeigen, dass die native Konfiguration eines Cloud-Teams von der Unternehmensrichtlinie abweicht. Die Organisation muss entscheiden, welches System maßgeblich ist und wer Abhilfe genehmigt. Software allein löst diese institutionelle Frage nicht.

Das Lebenszyklusmodell erhöhte außerdem die Wechselkosten. Wenn ein Controller Asset-Graph, Richtlinien, Telemetrie, Edge-Platzierungen und Automatisierungsintegrationen verwaltet, erfordert sein Ersatz mehr als die Umstellung einer Verbindung. Der Kunde muss das Betriebsmodell exportieren oder rekonstruieren. Prosimo versprach, Cloud-Fragmentierung zu verringern, und schuf zugleich die Möglichkeit einer Controller-Abhängigkeit.

Segmentierung reichte von Netzwerkerreichbarkeit bis zur Anwendungsrichtlinie

Prosimo beschrieb Segmentierung von Layer 3 bis 7. Auf Netzwerkebene bestimmten Routingdomänen und Segmente, welche Subnetze oder Standorte kommunizieren konnten. Auf höheren Ebenen konnten Anwendungsidentität, Nutzerkontext und Transaktionseigenschaften die Regel verfeinern.

Das Schichtenmodell konnte die Lücke zwischen Netzwerkzone und Anwendungsrichtlinie verkleinern. Ein Geschäftsdienst konnte zugelassen werden, obwohl breite Subnetz-zu-Subnetz-Erreichbarkeit blockiert blieb. Umgekehrt konnte ein erreichbarer Netzwerkpfad verweigert werden, wenn Identität oder Anwendungskontext nicht passten.

Das machte Prosimo nicht zu einer vollständigen Next-Generation Firewall. Die Integration mit Palo Alto Networks von 2024 trennte Aufgaben: Prosimo orchestrierte Routen, Segmentierung und Service Insertion; die VM-Series übernahm die tiefe Inspektion. Die Unterscheidung ist wichtig, weil Richtliniensteuerung und Sicherheitsdurchsetzung unterschiedlich versagen.

Ein Segment ist nur wirksam, wenn alle relevanten Pfade dargestellt sind. Eine unbekannte Route, native Cloud-Ausnahme oder fehlgeschlagene Service Insertion kann die vorgesehene Kontrolle umgehen. Für die Absicherung war deshalb ein Vergleich der deklarierten Richtlinie mit dem tatsächlichen Zustand beim Cloud-Anbieter und dem beobachteten Verkehr erforderlich; die Konfigurationsansicht des Controllers allein reichte nicht aus.

Service Insertion verband Routingkontrolle mit der Ökonomie von Firewalls

Bei der Gestaltung von Cloud-Sicherheit muss entschieden werden, wo die Inspektion stattfindet. Zentralisierte Firewalls können Richtlinien vereinfachen und die Zahl der Appliances reduzieren, aber Backhaul, Konzentration und Skalierungsdruck erzeugen. Verteilte Firewalls bleiben näher an Workloads und verringern manche Pfadverzerrung, vervielfachen jedoch Bereitstellung, Lizenzierung, Upgrades und Richtlinienbetrieb.

Prosimo unterstützte beide Muster in der VM-Series-Integration. Richtlinien konnten ausgewählten Verkehr durch einen zentralen Inspektionspunkt oder durch verteilte Firewalls in Anwendungs-VPCs lenken. Der Controller aktualisierte die umliegenden Routen, während Palo Alto Networks die Inspektionsfunktion stellte.

Damit wurde Routing-Orchestrierung für einen Sicherheitsanbieter kommerziell wertvoll. Eine Software-Firewall kann keinen Verkehr schützen, der sie nie erreicht. Ressourcenerkennung, Platzierung und Routingänderungen verringern den Aufwand, erworbene Sicherheitskapazität in einen laufenden Pfad einzuschleifen. Das ist ein plausibler strategischer Grund für Palo Alto Networks, Prosimos Technologie zu übernehmen.

Zugleich vergrößerte sich der Auswirkungsradius des Controllers. Eine fehlerhafte Richtlinie kann Inspektion umgehen, Schleifen erzeugen, asymmetrisches Routing verursachen oder eine Anwendung abschalten. Systemzustandsprüfungen, stufenweise Änderungen, Simulation, Audit und Rollback sind nötig, weil ein Fehler bei Service Insertion zugleich ein Netzwerk- und ein Sicherheitsereignis ist.

Die Partnerschaft von 2024 darf nicht rückwirkend als Übernahme gelten

Prosimo und Palo Alto Networks kündigten die VM-Series-Integration am 12. Juni 2024 an. Die Mitteilung beschrieb eine gemeinsame technische und kommerzielle Lösung. Sie erklärte nicht, dass Palo Alto Networks Prosimo übernommen hatte. Wer die Ankündigung als Eigentumsbeleg behandelt, verschmilzt zwei getrennte Ereignisse.

Die Partnerschaft schuf dennoch eine Brücke. Prosimo konnte zeigen, wie sein Routing- und Richtliniensystem die Bereitstellung der VM-Series über Clouds erleichterte. Palo Alto Networks konnte die Technologie in einer realen Integration vor dem späteren Übergang des Unternehmens bewerten. Öffentliche Belege beschreiben den Übernahmeprozess nicht; die Behauptung, die Partnerschaft sei formell als Vorstufe zur Übernahme angelegt gewesen, wäre Spekulation.

Anfang 2025 hatten sich die Profile von Gründern und Beschäftigten verändert. Die Unternehmensseite trug später einen Übernahmehinweis. Ende 2025 erklärte Bhau, die Technologie sei vollständig in Produkte von Palo Alto Networks integriert worden. Zusammengenommen stützen diese Unterlagen die Übernahmeschlussfolgerung und lassen die rechtlichen Mechanismen offen.

Die Reihenfolge ist für redaktionelle Genauigkeit und Kunden wichtig. Eine Partnerschaft bedeutet zwei Anbieter, zwei Supportstrukturen und eine definierte Integrationsgrenze. Eine Übernahme kann Roadmaps, Daten, Verträge und Autorität in ein Unternehmen verschieben. Der Übergang verändert mehr als die Marke, selbst wenn der technische Pfad zunächst ähnlich wirkt.

Nebula machte den Topologiegraphen über eine Dialogoberfläche zugänglich

Prosimo stellte Nebula im Februar 2024 als Teil einer AI Suite für Multi-Cloud-Netzwerke vor. Der Assistent sollte in natürlicher Sprache gestellte Fragen zu überlappenden Netzen, Kosten, Routenstatus, Verstößen gegen Sicherheitsrichtlinien und anderen Zuständen beantworten, die im Graphen und in der Telemetrie der Plattform abgebildet waren.

Das wertvolle Asset war nicht die Sprachoberfläche für sich, sondern der strukturierte cloudübergreifende Kontext darunter. Ein allgemeines Modell kann keine private Route oder kein Segment diagnostizieren, das es nicht sieht. Nebula konnte Asset-Inventar, Topologie, Richtlinien und Beobachtungen nutzen, die Prosimo bereits sammelte. Dadurch wurde die frühere Investition in einen gemeinsamen Graphen für AIOps relevant.

Der dialogbasierte Zugriff konnte komplexe Daten mehr Betreibern zugänglich machen. Er konnte zugleich falsches Vertrauen schaffen, wenn eine Antwort ein nicht unterstütztes Asset ausließ, die Frage missverstand oder eine Empfehlung als genehmigte Aktion behandelte. Hochriskante Änderungen benötigten weiterhin deterministische Kontrollen, Berechtigungsgrenzen und menschliche Prüfung.

Prosimo nannte mögliche Verbesserungen wie 60 bis 80 Prozent geringere Mean Time to Resolution und mehr als 60 Prozent niedrigere Cloud-Networking-Kosten. Diese Zahlen waren Unternehmensangaben in einer Produktankündigung. Die vorliegenden Belege enthalten weder eine unabhängige Methodik noch einen kundenseitigen Ausgangswert, der allgemeine Gültigkeit beweist. Sie können als von Prosimo vorgeschlagener Nutzen zitiert werden, nicht als gemessene Markttatsache.

KI-Workloads waren ein neuer Anwendungsfall, kein Beweis für einen neuen Markt

Dieselbe Ankündigung von 2024 stellte Prosimos Architektur als nützlich für KI-Workloads dar. Verteilte KI-Systeme können privaten Datenzugriff, Verbindungen zwischen Clouds und Rechenzentren, Compliance-Kontrollen und ein Routing benötigen, das Anwendungsverhalten berücksichtigt. Diese Anforderungen passten zum bestehenden Asset-, Richtlinien- und Pfadmodell.

Die Bezeichnung veränderte das Underlay-Netz nicht. Prosimo blieb von Cloud-Netzen, Carriern und Kundeninfrastruktur abhängig. Das Unternehmen lieferte weder GPU-Compute noch Modellentwicklungssoftware. Seine mögliche Rolle war die Konnektivitäts- und Sicherheitsschicht für verteilte Daten und Dienste.

Die KI-Positionierung war strategisch nachvollziehbar, weil der Wert einer cloudübergreifenden Topologie mit stärker verteilten Daten und Diensten steigt. Sie war zugleich eine Marketingkategorie, die kurz vor dem Ende der unabhängigen Geschäftstätigkeit eingeführt wurde. Die Unterlagen belegen weder gesonderte KI-Produktumsätze noch namentlich belegte Produktivbereitstellungen oder geprüfte Workload-Ergebnisse.

Der dauerhafte Befund lautet, dass Multi-Cloud-Telemetrie zu einer Grundlage maschinengestützter Betriebsabläufe werden kann. Die heutige Produktfrage lautet, ob Palo Alto Networks diesen Kontext erhalten hat und wie es die Funktion zugänglich macht. Die öffentlich verfügbaren Informationen zum Stichtag liefern keine vollständige Antwort.

Das Geschäftsmodell verkaufte Software für Infrastruktur, die Prosimo nicht besaß

Prosimos unabhängiges Geschäft war ein Software-Abonnement- und Dienstleistungsmodell, kein Carrier-Modell. Kunden stellten AXI Edges in ihren Umgebungen bereit und verbanden Cloud-Konten mit der Steuerungsschicht. Umsätze dürften aus Lizenzen oder Abonnements, Support, Professional Services und Vertriebspartneraktivitäten entstanden sein; konkrete Preise und Vertragskennzahlen wurden in den vorliegenden Belegen nicht veröffentlicht.

Das Modell konnte ohne eigenes Glasfasernetz skalieren. Eine Softwareplattform koordinierte viele Cloud-Regionen und Kundenumgebungen. Aus dieser Architektur lassen sich jedoch keine Aussagen über die Bruttomargen ableiten. Engineering-Support für Anbieter-APIs, den Edge-Lebenszyklus, Sicherheitsintegrationen und die Bereitstellung in Unternehmen kann teuer sein, während die vom Edge verbrauchten Cloud-Ressourcen möglicherweise der Kunde und nicht der Anbieter bezahlt.

Prosimo nutzte Cloud-Marketplaces, Integrations- und Vertriebspartner sowie namentliche Kundenreferenzen, um Unternehmenskunden zu erreichen. Diese Beziehungen sind nicht gleichwertig. Eine Marketplace-Listung belegt einen Beschaffungs- und Bereitstellungspfad. Eine technische Integration belegt, dass zwei Systeme unter definierten Bedingungen kombiniert werden können. Ein Kundenzitat liefert eine Referenz. Keines davon belegt für sich die Zahl zahlender Kunden oder wiederkehrende Umsätze.

Die Breite des Angebots könnte die Vertriebskomplexität erhöht haben. Netzwerk-, Sicherheits-, Cloud- und Anwendungsteams konnten profitieren, doch die Budgetverantwortung war möglicherweise unklar. Das Produkt brauchte einen Budgetverantwortlichen, der eine gemeinsame Steuerungsschicht finanzierte, statt für jede Cloud und jedes Team einen getrennten Betrieb zu finanzieren.

Partner, Kunden und Investoren erfüllten unterschiedliche Rollen

Amazon Web Services war zugleich Underlay-Anbieter und Go-to-Market-Partner. Azure und Google Cloud waren unterstützte Umgebungen. Identitätsanbieter lieferten Authentisierungskontext, während Firewall-Anbieter die Inspektion übernahmen. Colocation- und Carrier-Dienste konnten Edges hosten oder anbinden. Vertriebspartner konnten Bereitstellungen entwerfen und betreiben.

Flexport erschien als namentliche Kundenreferenz im AWS-Cloud-WAN-Material. Die Referenz zeigt Unternehmensinteresse an der Architektur, legt aber weder vollständigen Umfang noch Dauer oder kommerziellen Wert der Bereitstellung offen. Sie darf nicht als Stellvertreter für die gesamte Kundenbasis dienen.

General Catalyst führte die Series A an und war über seine Investorenrolle in die Governance eingebunden. Mit WRVI oder Celesta verbundene Investoren erschienen in Unternehmensmaterial; spätere Prosimo-Kommunikation nannte zusätzliche prominente Beteiligung, darunter eine mit BlackRock verbundene Bezeichnung, deren genaues Anlagevehikel in der Recherche offenblieb. Diese Unterlagen zeigen eine gut vernetzte Finanzierungsbasis, keinen vollständigen Cap Table.

Palo Alto Networks nahm die folgenreichste Position ein: Aus dem Sicherheitspartner von 2024 wurde bis Anfang 2025 der Käufer. Die Abfolge zeigt, wie eine Ökosystemabhängigkeit zur Kontrollbeziehung wird, wenn ein Teilnehmer die Softwareschicht kauft, die den Pfad zu seinem Produkt koordiniert.

Mindestens 55 Millionen US-Dollar wurden eingeworben; das wirtschaftliche Ergebnis des Unternehmensverkaufs bleibt unbekannt

Die verifizierte Finanzierung besteht aus einer Series A über 25 Millionen US-Dollar im April 2021 und einer Series B über 30 Millionen US-Dollar im Jahr 2022. Der Gesamtbetrag liegt bei mindestens 55 Millionen US-Dollar. Die bereitgestellten Belege enthalten weder einen geprüften Cap Table noch Angaben zur Bewertung, Fremdfinanzierungsstruktur oder zu späteren Finanzierungsrunden.

Der Übernahmepreis wurde weder veröffentlicht noch unabhängig bestätigt. Ohne Preis lässt sich das Ergebnis nicht verantwortungsvoll als strategische Prämie, bescheidener Technologiekauf, Acqui-Hire oder Notverkauf einordnen. Die fortdauernde Produktintegration belegt technologischen Wert, verrät aber nicht die Rendite von Investoren oder Gründern.

Umsatz und Marktstellung von Palo Alto Networks dürfen nach der Übernahme nicht Prosimo zugerechnet werden. Sobald das Start-up nicht mehr separat beobachtbar war, gab es kein eigenständiges Umsatz-, Gewinn- oder Kundensegment zu analysieren. Ein größerer Eigentümer kann die Technologie breiter verfügbar machen und zugleich ihre eigenständige wirtschaftliche Bedeutung weniger sichtbar werden lassen.

Das Fehlen einer formellen Übernahmemitteilung ist selbst relevant. Kunden, Beschäftigte und Forschende nutzen solche Mitteilungen normalerweise, um Zeitpunkt, Support und strategische Begründung zu bestimmen. Hier muss der Status aus Berufsprofilen, einer Kennzeichnung auf der Unternehmensseite und einer späteren Gründeraussage rekonstruiert werden. Das reicht zur Korrektur des Unternehmensstatus, nicht zur Erfindung von Transaktionsdetails.

Konkurrenz kam von Plattformen, Clouds und interner Entwicklung

Prosimo konkurrierte mit spezialisierten Multi-Cloud-Netzwerkplattformen wie Aviatrix und Alkira, mit Enterprise-Networking- und SASE-Anbietern sowie mit nativen Diensten von AWS, Azure und Google Cloud. Es konkurrierte auch mit einem Do-it-yourself-Modell, in dem Unternehmen Infrastructure as Code, Anbieter-Transitdienste, Routingtabellen und Firewalls direkt nutzen. Die Alternativen lösten jeweils andere Teile desselben Problems.

Ein spezialisierter Controller konnte ein Topologie- und Richtlinienmodell über Anbieter hinweg bieten. Ein Cloud-natives Design konnte die Abhängigkeit von Drittanbietern reduzieren und eng auf einen Anbieter zugeschnitten sein. Ein Carrier-gestützter Dienst konnte physischen Transport liefern. Eine SASE- oder Sicherheitsplattform konnte Konnektivität und Durchsetzung verbinden. Interne Entwicklung konnte die Kontrolle bewahren, erhöhte aber den Personal- und Integrationsaufwand.

Prosimos Differenzierung lag in der Kombination aus Anwendungs- und Netzwerktransit, verteilten Edges, Cloud-nativer Orchestrierung, Topologie, Telemetrie und Service Insertion. Dieselbe Breite erschwerte Vergleiche. Käufer mussten die konkreten Cloud-Dienste, Routen, Identitätssysteme und Sicherheitsmuster testen, die sie einsetzen wollten, statt Kategorienamen zu vergleichen.

Die Übernahme verändert den Wettbewerbsrahmen. Prosimo muss sich nicht mehr als eigenständiger Anbieter durchsetzen, doch seine Technologie muss ihren Wert innerhalb von Palo Alto Networks beweisen. Entscheidend ist, ob integrierte Ressourcenerkennung und Routing-Orchestrierung die Bereitstellung der Sicherheitsprodukte von Palo Alto Networks verbessern und ob Kunden die daraus entstehende Plattformabhängigkeit akzeptieren.

Native Cloud-Dienste waren Grundlage und Ersatz

AWS Cloud WAN, Transit Gateway, Azure Virtual WAN und Google-Cloud-Netzwerkdienste boten Unternehmen leistungsfähige native Optionen. Prosimo war auf diese Dienste angewiesen und stand zugleich in Konkurrenz zu ihrer direkten Nutzung durch Kunden.

Das Verhältnis schuf eine bewegliche Grenze. Wenn ein Cloud-Anbieter globales Routing, Segmentierung, privaten Servicezugriff oder zentrale Richtlinien ergänzte, ließen sich manche Drittanbieterfunktionen leichter nativ nachbilden. Gleichzeitig fügte jeder neue native Dienst ein weiteres Objekt hinzu, das ein cloudübergreifender Controller erkennen und koordinieren konnte. Fortschritte der Cloud-Anbieter konnten einen Teil von Prosimos Wert verringern und zugleich den Übersetzungsbedarf zwischen Anbietern erhöhen.

Der entscheidende Faktor war organisatorisch wie technisch. Ein Single-Cloud-Unternehmen mit starkem internem Engineering konnte native Werkzeuge bevorzugen. Ein Multi-Cloud-Unternehmen mit fragmentierten Teams konnte eine gemeinsame Steuerungsebene bevorzugen. Eine regulierte Organisation konnte eine unabhängige Kontroll- und Belegebene bevorzugen und zugleich privilegierte Zugangsdaten und Datenkonzentration fürchten.

Keine Architektur beseitigte Lock-in. Native Werkzeuge erhöhten die Abhängigkeit von APIs und Semantik eines Cloud-Anbieters. Ein cloudübergreifender Controller erhöhte die Abhängigkeit von seinem Graphen, seinen Richtlinien und seiner Edge-Software. Die sinnvolle Frage war, ob diese Abhängigkeit sichtbar, portabel und zum Betriebsmodell der Organisation passend war.

Fehler konnten im Controller, am Edge, in Cloud-APIs, im Identitätssystem oder im Underlay auftreten

Prosimos verteilte Architektur reduzierte die Abhängigkeit von einem Verkehrshub, erzeugte aber mehrere interagierende Fehlerdomänen. Der zentrale Dienst konnte ausfallen oder veraltete Vorgaben enthalten. Ein Edge konnte versagen oder isoliert werden. Eine Cloud-API konnte einen Teil einer Änderung ablehnen. Der Identitätsanbieter konnte ausfallen. Das Underlay-Netz konnte Kapazität verlieren oder einen unerwarteten Pfad nehmen. Eine eingeschleifte Firewall konnte Ressourcen erschöpfen.

Teilfehler sind besonders schwierig. Ein Anbieter kann eine Routingänderung übernehmen, während ein anderer sie ablehnt. Dann weicht der vom Controller beabsichtigte Zustand vom realen Cloud-Zustand ab. Verkehr kann asymmetrisch laufen oder Inspektion umgehen. Ein verlässliches System braucht Abgleich, idempotente Operationen, stufenweise Änderungen, klar ausgewiesene Fehlerzustände und einen Rollback, der das Verhalten jedes Anbieters berücksichtigt.

Öffentliche Belege beschreiben Verfügbarkeit und Optimierung auf hoher Ebene, enthalten aber keine unabhängige Fault-Injection-Studie, vollständige Incident-Historie oder allgemein gültige Service-Level-Ergebnisse. Aussagen zur Resilienz sollten deshalb an die dokumentierte Architektur oder an namentlich belegte Kundenerfahrungen gebunden bleiben.

Die Übernahme führt eine weitere Fehlerdomäne ein: Produktkontinuität. Kunden müssen wissen, welche Konsole, welche API, welches Edge-Image, welches Richtlinienmodell und welche Supportorganisation das historische Prosimo-System ersetzen. Eine technisch erfolgreiche Codeintegration kann dennoch Migrationsrisiken schaffen, wenn kommerzielle und operative Grenzen unklar sind.

Cloud-Zugangsdaten machten den Controller zu einem Teil der kritischen Managementebene

Asset Discovery und Orchestrierung erforderten Zugriff auf Cloud-Konten. Ein schreibgeschütztes Inventar konnte mit begrenzten Rechten arbeiten; Änderungen an Routen, Segmenten und Service Insertion verlangten weiterreichende Berechtigungen. Der Controller lag damit in der privilegierten Managementebene, obwohl er die Workloads nicht besaß.

Eine Kompromittierung der Zugangsdaten konnte die Topologie offenlegen oder weitreichende Änderungen erlauben. Ein Softwarefehler oder ein Bedienfehler konnte Richtlinien über mehrere Clouds verbreiten. Das Risiko wuchs mit dem Nutzen der Plattform: Je mehr Konten und Dienste sie verwalten konnte, desto größer der mögliche Auswirkungsradius.

Unternehmen benötigten Least-Privilege-Rollen, getrennte Zugangsdaten für Erkennung und Änderung, Mehrparteienfreigabe, vollständige Audits, Rotation, Notfallwiderruf und einen Wiederherstellungspfad, der nicht allein vom selben Controller abhing. Das öffentliche Material enthält keine vollständige unabhängige Sicherheitsbewertung; diese Punkte bleiben deshalb notwendige Bereitstellungskontrollen und keine verifizierten Produktgarantien.

Der Telemetriegraph war ebenso sensibel. Er konnte Anwendungsnamen, Netzwerkstruktur, Richtlinien, Nutzerbeziehungen, Routenzustand und Kostenmuster offenlegen. Die Governance nach der Übernahme sollte klären, wo die Daten gespeichert werden, welche Produkte von Palo Alto Networks auf sie zugreifen können und wie bestehende Kundenberechtigungen migriert wurden. Der öffentliche Stand beantwortet diese Fragen nicht.

Die Übernahme verschob eine cloudneutrale Schicht in eine Sicherheitsplattform

Prosimos unabhängige Position erlaubte es dem Unternehmen, sich als gemeinsame Schicht über Clouds und Sicherheitsdienste hinweg zu positionieren. Mit Palo Alto Networks als Eigentümer änderten sich die Anreize. Die übernommene Technologie konnte VM-Series und andere Produkte von Palo Alto Networks einfacher bereitstellen. Das kann ein besser integriertes Nutzungserlebnis schaffen und Fragen zum Support von Drittanbieter-Inspektionsdiensten aufwerfen.

Eigentum beweist nicht, dass Neutralität verschwunden ist. Die Unterlagen enthalten weder eine aktuelle Partnermatrix noch eine aktuelle Produktarchitektur. Sie verändern jedoch die Frage, die Kunden stellen sollten. Zu prüfen ist, ob der Routingcontroller für mehrere Sicherheitsanbieter offen bleibt, ob Richtlinien und Telemetrie exportierbar sind und ob die Optimierung das Portfolio des Eigentümers bevorzugt.

Die Integrationsaussage betonte Ingress-, Egress- und Ost-West-Inspektion. Das legt nahe, dass Prosimos Topologie und Orchestrierung Teil eines Systems zur Bereitstellung von Sicherheitsfunktionen wurden. Es beweist nicht, dass die historische App-Transit-Funktion, der Nutzerzugriff, die Kostenoptimierung oder sämtliche Cloud-Networking-Workflows als getrennte Fähigkeiten fortbestehen.

Dies ist ein häufiges Infrastrukturmuster. Ein Start-up abstrahiert ein schwieriges Koordinationsproblem; ein größerer Plattformanbieter kauft die Abstraktion, weil sie Nutzung und Kontrolle seines Kernprodukts steigert. Der Käufer gewinnt einen schnelleren Weg zur Bereitstellung. Der Kunde kann Integration gewinnen und einen Teil seiner Anbieterunabhängigkeit verlieren.

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

Die öffentlich verfügbaren Informationen bestätigen Übernahme und Integration, enthalten aber keine vollständige Zuordnung von AXI, Network Transit, App Transit, AIR und Nebula zu heutigen Produkten oder SKUs von Palo Alto Networks. Auch Legacy-Supportfristen, Migrationsverfahren und ein Funktionsvergleich zur Produktkontinuität fehlen.

Diese Lücke verhindert eine Produktbewertung in der Gegenwart. Historische Beschreibungen erklären, was Prosimo baute und warum es wichtig war. Sie sagen nicht, welche Funktionen heute verfügbar, lizenziert oder unterstützt sind. Aktuelle Bereitstellungsempfehlungen müssen auf der aktuellen Dokumentation von Palo Alto Networks beruhen und nicht auf archivierten Prosimo-Mitteilungen.

Die fehlende Zuordnung begrenzt auch die Strategieanalyse. Eine vollständige Übernahme des Topologiegraphen und der Orchestrierungsschicht wäre etwas anderes als der selektive Einsatz von Asset Discovery und Firewall-Platzierung. Das eine ergäbe einen breiten Multi-Cloud-Steuerungsdienst; das andere nutzte Prosimo vor allem, um die Bereitstellung von Sicherheitsfunktionen zu beschleunigen. Die Gründeraussage stützt die Fortführung der Technologie und lässt diese Architekturgrenze offen.

Ein künftiges Produktdokument, ein Migrationsleitfaden oder eine Kundenfallstudie könnte einen Großteil der Unsicherheit beseitigen. Bis dahin lautet die präzise Formulierung: Nach Aussage eines Mitgründers wurde Prosimos Technologie in Produkte von Palo Alto Networks integriert; Umfang und Produktverpackung sind nicht verifiziert.

Wer kontrolliert das Multi-Cloud-Routing?

Keine Partei kontrolliert den gesamten Pfad. Das Unternehmen besitzt die Konten, definiert die Geschäftsziele und das Anwendungsdesign und vergibt die Zugangsdaten. Ein cloudübergreifender Controller kann die Topologie erfassen, Richtlinien übersetzen, Pfade wählen und nativen Routenzustand ändern. Cloud-Anbieter kontrollieren APIs, Transitdienste, private Endpunkte, das Backbone und viele Fehlerdomänen. Carrier und Colocation-Anbieter kontrollieren weitere Teile des Transports. Sicherheitsdienste entscheiden, ob inspizierter Verkehr erlaubt wird.

Prosimo strebte die strategisch nützlichste Zwischenposition an. Es besaß das Underlay-Netz nicht, strebte aber die Kontrolle über den Graphen und die darüberliegende Richtlinienübersetzung an. Wer diese Schicht kontrolliert, kann entscheiden, welche Assets sichtbar sind, wie Segmente dargestellt werden, wo Edges platziert werden, welcher Dienst Verkehr inspiziert und welche Telemetrie als maßgeblich gilt. Das ist operative Kontrolle über das Routing, auch wenn die Glasfaser jemand anderem gehört.

Nach der Übernahme besitzt Palo Alto Networks die verbliebene Prosimo-Technologie und bestimmt, wie sie integriert, verpackt und weiterentwickelt wird. Cloud-Anbieter bleiben in ihren Umgebungen souverän; das Unternehmen kann Zugangsdaten widerrufen oder eine andere Architektur wählen. Der Ausstieg kann dennoch teuer sein, wenn Topologie, Richtlinien und Betriebsworkflows vom Controller abhängig geworden sind.

Die Antwort ist daher geschichtet und nicht absolut: Das Unternehmen autorisiert; der Controller koordiniert; die Cloud- und Carrier-Underlays transportieren; die Sicherheitsplattform setzt durch. Prosimos Geschichte zeigt, dass Eigentum an der koordinierenden Schicht wechseln kann, ohne dass ein Cloud-Konto oder physischer Pfad den Besitzer wechselt.

Zentrales Quellenverzeichnis

Warum Prosimo auch nach der Übernahme relevant bleibt

Prosimo erfasste einen realen Infrastrukturwandel. Der Gegenstand des Netzwerkbetriebs verschiebt sich vom Gerät und Präfix hin zu Anwendung, Identität, Dienstabhängigkeit und Richtliniengraph. Cloud-native APIs machen Netzwerkzustand programmierbar, verteilte Software-Edges machen den Durchsetzungspunkt beweglich. Ein Controller mit Sicht auf mehrere Clouds kann Aktionen koordinieren, die keine einzelne Cloud-Konsole allein umsetzen kann.

Das Unternehmen zeigte zugleich die Kosten dieser Koordination. Eine gemeinsame Schicht braucht privilegierte Zugangsdaten, laufende API-Pflege, präzise Erkennung, semantische Übersetzung, Telemetrie und Betriebsdisziplin. Sie kann fragmentierte Arbeit reduzieren und einen neuen Konzentrationspunkt schaffen. Dasselbe System, das Routing vereinfacht, kann zugleich den Auswirkungsradius einer Fehlentscheidung vergrößern.

Die Übernahme durch Palo Alto Networks macht die Kontrollfrage sichtbarer. Netzwerk und Sicherheit konvergieren bei Service Insertion, Workload Discovery und Richtliniensteuerung. Ein Sicherheitsanbieter, der die Topologie kennt und Routen ändern kann, untersucht nicht nur ihm präsentierten Verkehr; er kann mitbestimmen, welcher Verkehr die Inspektion erreicht und wo.

Prosimo sollte daher weder als gescheiterte eigenständige Marke gelten noch als Beleg dafür, dass eine einzelne Plattform das Multi-Cloud-Problem gelöst habe. Sein dauerhafter Beitrag war die Definition des cloudübergreifenden Graphen als Infrastruktur. Die verbleibende Frage ist, ob dieser Graph innerhalb eines größeren Sicherheitsunternehmens transparent, portabel und steuerbar genug bleibt, um das Vertrauen der Kunden zu verdienen.