Kernaussage: Aureolis verkauft keine Alternative zu bestehenden Security-Stacks. Aureolis verkauft die fehlende Schicht, die alle bestehenden Systeme besser macht. Jeder CISO hat bereits in Zero Trust, API Security und Identity investiert — SBC schützt diese Investition.
Empfohlene Strategie für einen erfolgreichen Markteintritt als frühes Startup gegen etablierte Milliarden-Unternehmen.
Phase 1 — Sofort (0–6 Monate)
Credibility aufbauen & erste Piloten gewinnen
- Unabhängiger Krypto-Audit: BSI-Zertifizierung oder NIST-Framework-Mapping beauftragen. Ohne externe Validierung gibt es keine Enterprise-Gespräche.
- Cloud-Benchmarks: Performance auf AWS/Azure mit 10k+ TPS nachweisen. Der Data-Coffee-Test auf Intel I7 reicht nicht für CISOs.
- 2–3 Lighthouse-Kunden: Kostenlose Piloten bei mittelständischen Unternehmen (100–500 MA) in regulierten Branchen (Fintech, Healthcare, GovTech). Ziel: „Case Study in 90 Tagen“.
- Referenzarchitekturen: Konkrete Integrationsbeispiele mit Kong, Envoy, Istio, AWS API Gateway — zeigt „kein Rip-and-Replace“.
- Thought Leadership: MSBG Axiom Paper auf arXiv veröffentlichen, Vortrag auf BSides/OWASP Germany, Blog-Serie „Why Auth is not enough“.
Phase 2 — Mittelfristig (6–18 Monate)
Partner-Ökosystem & Kategorie etablieren
- Technology Partnerships: Integration mit einem der großen Anbieter (Zscaler Marketplace, Palo Alto Cortex XSOAR, CyberArk Marketplace). Ein Partnership validiert mehr als jedes Whitepaper.
- OEM/Embedded-Modell: SBC als Middleware-SDK für API-Gateway-Hersteller lizenzieren. Niedrigere Einstiegsbarriere als Direktvertrieb.
- Kategorie benennen: „State-Bound Security“ als neues Marktsegment bei Analysten positionieren. Briefings bei Gartner, Forrester, KuppingerCole.
- NIS2/DORA-Compliance-Narrative: Regulatorischer Druck in EU erzwingt nachweisbare Zustandsvalidierung — Aureolis als Compliance-Enabler positionieren.
- Channel-Partner: 2–3 System-Integratoren in DACH (Bechtle, Computacenter, SHE) als Implementierungspartner gewinnen.
Phase 3 — Langfristig (18–36 Monate)
Skalierung & Standard-Etablierung
- Open Standard: State-Bound Protocol als RFC oder IETF Draft einreichen — positioniert SBC als Infrastruktur-Standard, nicht als Vendor-Produkt.
- AI-Agent-Security: Zustandsbindung für Agent-zu-Agent-Kommunikation (MCP, LangChain, AutoGPT) — der schnellst wachsende Angriffsvektor 2026+.
- Post-Quantum-Narrative: Ephemeral Keying reduziert klassische Angriffsflächen und zeigt potenziell günstige Eigenschaften für post-quantum Kommunikationsmodelle.
- Enterprise-Tier: Managed SBC Platform mit Dashboard, SIEM-Integration, Compliance-Reporting als SaaS-Angebot.
🎯 Greenfield (keine Security-Investition)
Strategie: Nicht als Standalone verkaufen. Zusammen mit einem bestehenden Stack empfehlen („Wir arbeiten perfekt mit Okta + Kong“). Zeigt Reife und Integrations-Readiness.
- Fokus auf regulatorische Compliance als Einstieg
- Demo: Replay-Angriff live zeigen — mit und ohne SBC
- Einstiegspreis aggressiv — Land-and-Expand
🛡 Zero-Trust-Kunde (Zscaler/Palo Alto vorhanden)
Strategie: Niemals als Ersatz positionieren. Immer als „die fehlende Schicht“. CISOs haben Millionen in Zero Trust investiert — sie wollen Bestätigung, keine Kritik.
- „Zero Trust prüft Identität. Wir prüfen zusätzlich den Zustand.“
- Konkretes Szenario: Gestohlenes Token + gültige Identität
- Integration mit bestehendem Stack demonstrieren
🔍 API-Security-Kunde (Salt/Noname vorhanden)
Strategie: Unterschied zwischen Erkennung und Prävention herausarbeiten. Salt erkennt Anomalien per ML — SBC verhindert architektonisch, dass anomale Requests gültig sein können.
- „Salt beobachtet den Traffic. Wir machen ungültigen Traffic unmöglich.“
- ML hat False Positives — kryptographische Validierung nicht
- Komplementarität: Salt für Discovery, SBC für Garantie
🤖 AI/Agentic-Fokus (Innovation-getrieben)
Strategie: Zustandsbindung für AI-Agent-Kommunikation ist der schärfste Differenzierungspunkt. Kein anderer Anbieter löst Agent-zu-Agent-Trust auf dieser Ebene.
- AI Agents mit gestohlenen Credentials = größtes Risiko 2026+
- State Chain = Audit Trail für jede Agent-Aktion
- CyberArk adressiert Agent-Identity, SBC adressiert Agent-Zustand
„Stellen Sie sich eine Tür vor, die keinen physischen Schlüssel hat. Sie öffnet sich nur, wenn gleichzeitig das richtige Gerät aktiv ist, die richtige Session läuft, das richtige Zeitfenster gilt und der Kontext stimmt. Sobald eine Bedingung nicht erfüllt ist, bleibt sie geschlossen. Es gibt keinen persistenten Schlüssel, den man dauerhaft stehlen und wiederverwenden könnte. Das ist State-Bound Security.“
✅ Beste Zielkunden
- Fintech / Banking mit API-heavy Architektur
- Healthcare / Pharma unter DSGVO/NIS2-Druck
- GovTech / Verteidigung mit hohen Sicherheitsanforderungen
- SaaS-Anbieter mit Multi-Tenant-API-Plattformen
- Unternehmen mit Microservice-Architekturen (50+ Services)
❌ Schlechte Zielkunden
- Monolithische Legacy-Systeme ohne API-Kommunikation
- KMUs ohne Security-Budget oder Compliance-Druck
- Unternehmen, die „Security = Firewall“ denken
- Orgs ohne Cloud/Container-Infrastruktur
- Unternehmen, die ausschließlich on-prem arbeiten
Aureolis SBC/KSBE vs. etablierte Security-Kategorien. Grün = Aureolis gewinnt | Rot = Wettbewerb gewinnt | Gelb = Gleichstand
| Capability |
SBC/KSBE |
Zero Trust |
API Security |
RASP/ADR |
Identity |
| Zustandskonsistenz | ✓✓✓ Kern | — | — | — | — |
| Ephemeral State-Bound Keying | ✓✓✓ Kern | — | — | — | — |
| Keine persistenten Keys | ✓✓✓ Kern | — | — | — | — |
| Krypto. Replay-Schutz | ✓✓✓ | Teilweise | Teilweise | — | Teilweise |
| Lateral Movement Schutz | ✓✓✓ | ✓✓ | ✓ | ✓ | ✓ |
| State Chain / Audit | ✓✓✓ | ✓ | ✓✓ | ✓✓ | ✓ |
| Identitätsprüfung | — (nicht Fokus) | ✓✓✓ Kern | ✓ | — | ✓✓✓ Kern |
| Policy Enforcement | — (nicht Fokus) | ✓✓✓ Kern | ✓✓ | ✓ | ✓✓✓ Kern |
| API Discovery | — | — | ✓✓✓ Kern | ✓ | — |
| ML Anomalie-Erkennung | — (architektonisch) | ✓✓ | ✓✓✓ Kern | ✓✓ | ✓ |
| Enterprise-Readiness | Früh | ✓✓✓ | ✓✓✓ | ✓✓ | ✓✓✓ |
| Marktpräsenz | Startup | ✓✓✓ | ✓✓✓ | ✓✓ | ✓✓✓ |
Lesehinweis für Sales: Die oberen 6 Zeilen sind eure Differenzierung — hier gewinnt SBC klar. Die unteren 6 Zeilen sind nicht euer Kampffeld. Positioniert euch immer als Ergänzung: „Wir ersetzen nichts, wir schützen eure bestehende Investition.“
Profil
Marktführer: Zscaler ($2B+ ARR, 160+ DCs), Palo Alto Prisma (SASE Leader), Cloudflare Zero Trust
Fokus: Identity-centric Access Control + Netzwerksicherheit + Cloud-native Proxy
Zielmarkt: Enterprise, Mid-Market | Pricing: Per User/Month, $80–250+
Gartner-Position: Leader in SASE, SSE, Zero Trust
Wo Aureolis gewinnt
- SBC Zustandskonsistenz — ZT prüft Identity, nicht ob der Request zum bisherigen Verlauf passt
- SBC Gestohlene Tokens — Bei ZT = voller Zugriff bis Ablauf. Bei SBC = Zustandsinkonsistenz erkannt
- KSBE Keine persistenten Keys — ZT schützt Schlüssel, KSBE eliminiert sie
- SBC Kryptographischer Audit Trail — Jeder Zustandswechsel nachvollziehbar
Wo sie gewinnen
- ZT Globale Skalierung — 160+ DCs, TLS-Inspektion, Edge Computing
- ZT Vollständige Plattform — SWG + CASB + DLP + ZTNA in einem
- ZT Enterprise-Referenzen — Fortune 500 Kunden, Gartner Leader
- ZT Breite Integration — 100+ Technologie-Partner
Talk Tracks
Wenn Zero Trust schon vorhanden
„Ihr Zero-Trust-Stack validiert Identität, Device Posture, Kontext und Policy hervorragend. Was er strukturell nicht prüft: Ist dieser Request kryptographisch konsistent mit dem bisherigen Sessionverlauf? Genau diese Zustandsdimension ergänzt State-Bound Security — als zusätzliche Schicht über Ihrer bestehenden Infrastruktur.“
Wenn Zero Trust evaluiert wird
„Zero Trust ist der richtige Ansatz. Empfehlen wir auch. Aber Zero Trust hat eine strukturelle Lücke: Ein gestohlenes Token ist ein gültiges Token — der Angreifer ist authentifiziert. SBC erkennt ihn trotzdem, weil sein Zustandsverlauf nicht stimmt.“
Landmine Questions
„Was passiert, wenn ein Angreifer ein gültiges Bearer Token hat — erkennt Ihr Zero-Trust-System den Unterschied zum legitimen User?“
Exponiert die Schwäche: ZT validiert das Token, nicht den Zustandskontext.
„Können Sie nachweisen, dass ein Request nicht nur autorisiert, sondern auch zustandskonsistent mit dem bisherigen Sessionverlauf war?“
Exponiert: ZT hat keinen kryptographischen Zustandsbeweis.
„Wie schützen Sie sich gegen Lateral Movement mit gültigen Service-Identitäten innerhalb Ihres Netzwerks?“
ZT-Mikrosegmentierung hilft, aber validiert nicht den Kommunikationsverlauf.
Profil
Marktführer: Salt Security (Agentic Platform 2026), Akamai (Noname $450M Akquisition), Traceable (Teil von Harness)
Fokus: API Discovery, Traffic-Analyse, ML-Anomalie-Erkennung, Bot Protection
Zielmarkt: Enterprise, Dev-first | Pricing: API-Volumen-basiert, $50k–500k+/Jahr
Gartner-Position: Leader/Visionary in API Security
Wo Aureolis gewinnt
- SBC Architektonische Prävention vs. ML-Erkennung — kein False-Positive-Problem
- KSBE Kryptographische Garantie — ML kann umgangen werden, State Chain nicht
- SBC Zustandsbindung auf Request-Ebene — jeder einzelne API-Call validiert
- SBC Keine Pattern-Abhängigkeit — funktioniert gegen völlig neue Angriffsmuster
Wo sie gewinnen
- API Shadow API Discovery — finden unbekannte APIs automatisch
- API Bot & DDoS Protection — Traffic-Level-Schutz
- API Developer-Experience — Testing, CI/CD-Integration
- API Dashboards & Analytics — umfassende API-Visibility
Talk Tracks
Wenn Salt/Noname vorhanden
„Salt beobachtet Ihren API-Traffic und erkennt Anomalien per ML — das ist wertvoll. Aber: ML erkennt Muster. Ein Angreifer, der ein neues Muster verwendet, fliegt unter dem Radar. SBC macht das architektonisch unmöglich: Ohne konsistenten Zustand kann kein Request gültig sein. Erkennung plus Garantie.“
Landmine Questions
„Wie hoch ist Ihre False-Positive-Rate bei der API-Anomalie-Erkennung? Und wie viele echte Angriffe verwenden völlig neue Muster, die Ihr ML-Modell noch nicht kennt?“
ML-basierte Erkennung hat inhärent False Positives und ist blind für Zero-Day-Patterns.
„Wenn ein API-Request technisch gültig, korrekt authentifiziert und autorisiert ist — aber der Zustand nicht zum bisherigen Sessionverlauf passt — erkennt Ihr System das?“
API-Security validiert Request-Inhalte, nicht Zustandskonsistenz.
Profil
Marktführer: Contrast Security (ADR + IAST/RASP), Dynatrace (AppSec), Imperva (RASP + WAF)
Fokus: In-Process-Instrumentierung, Runtime-Schutz, Vulnerability Monitoring
Zielmarkt: Enterprise DevSecOps | Pricing: Per Agent/App, $15k–200k+/Jahr
Gartner-Position: Visionary (Contrast), Leader (Imperva WAF)
Wo Aureolis gewinnt
- SBC Kommunikationsebene vs. Applikationsebene — schützt zwischen Services
- SBC Agentless — kein Code-Instrumentation in jeder App nötig
- KSBE Verschlüsselung + Validierung in einem — RASP hat keine Crypto-Schicht
- SBC Infrastrukturweit — eine Schicht für alle Services, nicht pro App
Wo sie gewinnen
- RASP Tiefe App-Visibilität — sieht Code-Level-Vulnerabilities
- RASP MITRE ATT&CK Mapping — SOC-Integration out of the box
- RASP Dual-Use Testing — gleicher Agent für Dev und Prod
- RASP Etabliert — bekannte Kategorie bei CISOs
Talk Track
Wenn Contrast/Imperva vorhanden
„RASP schützt Ihre Applikation von innen — das ist wichtig. SBC schützt die Kommunikation zwischen Ihren Applikationen. Zwei verschiedene Angriffsflächen, gleiche Infrastruktur. Zusammen haben Sie sowohl App-Level als auch Communication-Level Security.“
Landmine Question
„Ihr RASP-Agent schützt die Applikation. Aber was passiert zwischen den Services — wenn die Kommunikation selbst kompromittiert wird, bevor sie die App erreicht?“
RASP sieht nur was in der App ankommt, nicht den Kommunikationspfad dorthin.
Profil
Marktführer: Okta ($2.5B+ ARR), CyberArk (PAM Leader), Auth0 (Developer Identity)
Fokus: Workforce Identity, Adaptive MFA, Privileged Access, Zero Standing Privileges
Neueste Entwicklung: CyberArk AI Agent Security (Nov 2025) — Privilege Controls für AI Agents
Zielmarkt: Enterprise, alle Branchen | Pricing: Per User/Month, $6–35+ (Okta); $50k–500k+ PAM
Wo Aureolis gewinnt
- SBC „Wer bist du?“ vs. „Ist dein Zustand konsistent?“ — zwei verschiedene Fragen
- KSBE Eliminiert persistente Keys — PAM schützt Schlüssel, KSBE eliminiert sie
- SBC Kontinuierliche Zustandsvalidierung — nicht nur zum Authentifizierungszeitpunkt
- SBC Bearer Token nach Ausstellung = voller Zugriff bei Identity. Bei SBC = nur mit konsistentem Zustand
Wo sie gewinnen
- IAM Komplettes Identity Lifecycle Management — von Provisioning bis Deprovisioning
- IAM Adaptive MFA — kontextbasierte Step-up-Authentifizierung
- IAM Riesiges Partner-Ökosystem — 7000+ App-Integrationen (Okta)
- IAM AI Agent Security — CyberArk hat als Erster Privilege Controls für AI Agents
Talk Track
Wenn CyberArk/Okta vorhanden
„Okta und CyberArk sind das Rückgrat Ihrer Identity-Infrastruktur — richtig so. Aber nach der Authentifizierung passiert etwas Entscheidendes: Ein Bearer Token wird ausgestellt, und ab dann hat jeder, der dieses Token hat, vollen Zugriff. SBC prüft bei jedem einzelnen Request, ob der Zustand immer noch konsistent ist. Nicht nur am Tor, sondern bei jedem Schritt.“
Landmine Questions
„Was passiert zwischen dem Moment der Authentifizierung und dem Ablauf des Tokens? Wie prüfen Sie, dass der Zustand während der gesamten Session konsistent bleibt?“
Identity validiert am Eingang. Was danach passiert, wird nicht kryptographisch geprüft.
„CyberArk schützt Ihre Schlüssel im Vault. Aber was wäre, wenn es gar keine Schlüssel gäbe, die geschützt werden müssen?“
Repositioniert PAM: Schlüssel schützen vs. Schlüssel eliminieren.
Die häufigsten Einwände und wie man sie adressiert.
„Wir haben noch nie von State-Bound Security gehört. Das ist keine etablierte Kategorie.“
Antwort: „Genau. Vor 10 Jahren war Zero Trust auch keine etablierte Kategorie. Forrester hat den Begriff 2010 geprägt, und es hat Jahre gedauert, bis es Mainstream wurde. State-Bound Security adressiert eine Lücke, die erst mit Cloud-native Architekturen und AI-gestützten Angriffen kritisch wurde. Früher Zugang bedeutet Wettbewerbsvorteil.“
„Unser Zero-Trust-Stack deckt das bereits ab.“
Antwort: „Zero Trust ist exzellent für Identity und Policy. Aber lassen Sie mich eine Frage stellen: Wenn ein Angreifer ein gültiges Token hat — zum Beispiel durch Phishing oder Session Hijacking — erkennt Ihr Zero-Trust-System den Unterschied zum legitimen User?“ [Pause abwarten] „Genau das ist der blinde Fleck, den State-Bound adressiert.“
„Aureolis ist ein kleines Startup. Wie wissen wir, dass es morgen noch existiert?“
Antwort: „Berechtigte Frage. Drei Punkte: (1) Die Technologie basiert auf publizierten mathematischen Axiomen — sie ist nicht an ein Unternehmen gebunden. (2) Wir haben externe Validierung durch Partner im Fraunhofer-Umfeld. (3) Wir bieten eine Pilotphase mit messbaren KPIs — kein Risiko, nur Erkenntnis.“
„Die Integration in unsere bestehende Infrastruktur ist zu komplex.“
Antwort: „SBC ist als Middleware/Proxy-Layer konzipiert — es sitzt zwischen Ihrem API Gateway und Ihren Services. Keine Code-Änderungen in Ihren Applikationen, kein Rip-and-Replace. Vergleichbar mit dem Deployment eines neuen Sidecar-Containers in Ihrem Service Mesh. Wir haben Referenzarchitekturen für Kong, Envoy und AWS API Gateway.“
„Was ist der konkrete ROI? Wie messen wir den Nutzen?“
Antwort: „Drei messbare KPIs: (1) Reduktion der Mean Time to Detect bei Credential-Missbrauch. (2) Anzahl blockierter Replay-Versuche und Zustandsinkonsistenzen. (3) Vereinfachter Compliance-Nachweis durch kryptographischen Audit Trail — spart 40–60% Audit-Vorbereitungszeit bei SOC2/NIS2.“
„Wir warten, bis ein großer Anbieter das einbaut.“
Antwort: „Verständlich. Aber: Zscaler, Palo Alto und CyberArk optimieren ihre bestehenden Architekturen — sie werden State-Binding nicht fundamental einbauen, weil es ihr gesamtes Sicherheitsmodell verändern würde. Ephemeral State-Bound Keying erfordert einen architektonischen Neuansatz, kein Feature-Update. Wer wartet, hat in 3 Jahren einen Legacy-Stack ohne Zustandsvalidierung.“
„Haben Sie eine BSI-Zertifizierung oder FIPS-Validierung?“
Antwort: „Wir nutzen ausschließlich standardisierte Krypto-Primitives — AES, ChaCha20, HKDF. Die Innovation liegt nicht im Algorithmus, sondern in der Architektur der Schlüsselableitung. Die formale Zertifizierung ist in Vorbereitung. Aber: Die Pilotphase läuft auf Basis validierter Kryptographie — Sie müssen nicht auf die Zertifizierung warten, um den Nutzen zu evaluieren.“