Platform Engineering und interne Entwicklerplattformen
Plattformarchitektur mit Referenzvorlagen für neue Dienste
Mehr dazuIndustrien / IT- und Softwarebranche
Software sicher entwickeln und Plattformen zuverlässig bereitstellen und betreiben.
Beratung. Integration. Betrieb.

Für die Menschen in Ihrer Branche.
Ihre Schwerpunkte
Wir bauen interne Entwicklerplattformen auf Kubernetes und Public Cloud, verankern Sicherheit in jeder Phase Ihres Entwicklungszyklus und verstärken Ihre Teams mit erfahrenen Fachkräften.
Plattformarchitektur mit Referenzvorlagen für neue Dienste
Mehr dazuHSM-Architektur mit Schlüsselinventar und Zeremonieprotokoll
Mehr dazuRollenprofile und Einsatzplan je Team
Mehr dazuVon der Strategie bis ins System
Sechs Handlungsfelder. Wählen Sie, wo Sie genauer hinschauen möchten.
Unser Ansatz
Eine interne Entwicklerplattform stellt Infrastruktur, Pipelines, Monitoring und Sicherheitsvorgaben als Selbstbedienung bereit, damit Produktteams ohne Tickets ausliefern. Wir bauen sie auf Kubernetes mit Backstage als Entwicklerportal, Terraform für die Infrastruktur und Argo CD für die Auslieferung per GitOps. Leitplanken als Policy as Code prüfen jede Ressource, bevor sie in Betrieb geht. Die Plattform wird wie ein Produkt geführt, mit Backlog, Nutzerfeedback und gemessener Durchlaufzeit.
Ein SaaS-Anbieter mit mehreren Produktteams legt neue Dienste über Vorlagen im Entwicklerportal an; Namespace, Pipeline und Monitoring entstehen ohne Ticket an das Plattformteam.
Unser Ansatz
Kunden, Prüfer und der Cyber Resilience Act wollen wissen, welche Komponenten in Ihrer Software stecken und ob der Build unverändert ist. Wir verankern Bedrohungsmodellierung, statische Codeanalyse, Secret Scanning und Dependency Scanning als Pflichtschritte in der Pipeline. Jedes Release erhält eine SBOM in CycloneDX oder SPDX, signierte Artefakte und einen Herkunftsnachweis nach SLSA. Neue Schwachstellen in Abhängigkeiten werden automatisch den betroffenen Versionen zugeordnet und mit Fristen nach Schweregrad behoben.
Ein Hersteller von Branchensoftware liefert zu jedem Release SBOM und signierte Images aus; Kundenanfragen zu einer neuen Schwachstelle beantwortet das Team mit einer VEX-Aussage statt mit manueller Suche.
Unser Ansatz
Wer einen Code-Signing-Schlüssel stiehlt, kann Schadsoftware unter Ihrem Namen verteilen, deshalb gehört er nicht auf Build-Server oder Entwicklerrechner. Für öffentlich vertrauenswürdige Code-Signing-Zertifikate verlangen die Baseline Requirements des CA/Browser Forum ohnehin, dass der private Schlüssel in Hardware erzeugt und gespeichert wird. Wir wählen Netzwerk-HSM von Thales, Entrust oder Utimaco herstellerneutral aus, binden Build-Pipelines über PKCS#11 an und richten einen Signaturdienst mit Freigaben ein. Jede Signatur für Windows-Binärdateien, Container-Images, Pakete oder Firmware wird protokolliert und einem Release zugeordnet.
Ein Hersteller von Desktop-Software zieht seinen Code-Signing-Schlüssel vom Build-Server in ein Netzwerk-HSM um; Release-Signaturen brauchen eine zweite Freigabe und sind jedem Build zugeordnet.
Unser Ansatz
Je nach Größe zählt NIS2 Anbieter von Cloud-Diensten, Rechenzentren und Managed Services zu den wichtigen oder besonders wichtigen Einrichtungen, und in Deutschland regelt das NIS2-Umsetzungsgesetz die Pflichten. Verlangt werden Risikomanagementmaßnahmen nach Artikel 21, gestufte Meldungen erheblicher Vorfälle, Sicherheit in der Lieferkette und eine Geschäftsleitung, die dafür verantwortlich ist. Wir betreiben Ihre Kubernetes-Plattform und Cloud-Konten mit Monitoring, Bereitschaft, Incident Response und getesteter Wiederherstellung. Meldewege, Lieferantenregister und Betriebsnachweise sind Teil des Betriebs und beantworten auch die Sicherheitsfragebögen Ihrer Kunden.
Ein Anbieter von Personalsoftware übergibt den Betrieb seiner Kubernetes-Plattform; Vorfälle laufen über einen dokumentierten Meldeprozess, und Sicherheitsfragebögen beantwortet das Team aus den Betriebsnachweisen.
Unser Ansatz
Wenn Roadmap und Regulierung gleichzeitig Kapazität binden, arbeiten Fachkräfte von OTOKO® für eine vereinbarte Zeit in Ihren Teams mit. Backend- und Frontend-Entwickler, Plattformingenieure, Testautomatisierer und Security Engineers übernehmen Aufgaben in Ihren Sprints, Repositories und Code-Reviews nach Ihrer Definition of Done. Zugriffe erhalten sie nach dem Prinzip der minimalen Rechte, und Entscheidungen werden in Architecture Decision Records und Runbooks dokumentiert, damit das Wissen nach dem Einsatz bei Ihrem Team bleibt.
Ein Softwarehaus verstärkt sein Plattformteam vor einem Kundenrollout mit DevOps- und Testingenieuren; nach dem Rollout übernimmt das eigene Team die dokumentierten Pipelines.
Unser Ansatz
Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, auch von Software, zu Sicherheit durch Design, einer SBOM und Schwachstellenbehandlung über den gesamten Supportzeitraum. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, ab dem 11. Dezember 2027 alle übrigen Pflichten. Wir stufen Ihre Produkte ein, schließen Lücken gegenüber Anhang I und richten den Meldeprozess ein. Weil Produkte und ihre Update-Signaturen oft länger im Einsatz bleiben, als RSA und elliptische Kurven gegen Quantencomputer sicher sind, erstellen wir zugleich ein Kryptografie-Inventar und einen Fahrplan zu ML-KEM und ML-DSA.
Ein Hersteller von VPN-Software stuft sein Produkt als wichtiges Produkt ein, richtet den Meldeprozess für aktiv ausgenutzte Schwachstellen ein und stellt die Update-Signatur schrittweise auf ein hybrides Verfahren um.

Typische Projektsituationen
Oft beginnt ein Projekt mit einer konkreten Herausforderung. Diese Beispiele verbinden eine typische Ausgangslage mit einem möglichen Ansatz und dem angestrebten Ergebnis.
Beispielhafte Ausgangssituationen – keine Kundenreferenzen.
01 / IT- und Softwarebranche
Code-Signing-Schlüssel als Datei auf dem Build-Server, mehrere Personen kennen das Passwort, eine Zertifikatserneuerung nach neuen Hardwarevorgaben steht an.
Netzwerk-HSM mit protokollierter Schlüsselerzeugung, Signaturdienst mit Freigabe, Anbindung der Pipelines über PKCS#11.
Schlüssel im zertifizierten HSM, jede Signatur einem Build zugeordnet, erneuertes Zertifikat nach den Baseline Requirements.
02 / IT- und Softwarebranche
Jedes Produktteam betreibt eigene Cluster und Pipelines, neue Dienste warten auf Tickets, Sicherheitsprüfungen sind uneinheitlich.
Interne Entwicklerplattform mit Backstage, GitOps über Argo CD, Leitplanken als Policy as Code und Observability in jeder Vorlage.
Neue Dienste über Vorlagen, einheitliche Prüfungen in allen Pipelines, Plattformteam arbeitet am Produkt statt an Tickets.
03 / IT- und Softwarebranche
Der Anbieter fällt unter NIS2, Großkunden verlangen einen SOC-2-Bericht und es gibt keinen dokumentierten Meldeprozess.
Betroffenheitsanalyse, ISMS nach ISO 27001 mit Zuordnung zu SOC 2, Meldeprozess mit Vorlagen, Wiederherstellungstests.
Registrierung beim BSI, Meldewege im Regelbetrieb, Evidenz für das Zertifizierungsaudit und die SOC-2-Prüfung.
Zusammenarbeit
Vom ersten Überblick bis zum laufenden Betrieb: Wir stimmen Prioritäten, Verantwortlichkeiten und die Ergebnisse der einzelnen Schritte gemeinsam ab.
So arbeiten wir
Plattform, Pipelines, Schlüssel und regulatorische Lücken
Zielplattform, Sicherheitskontrollen, Betriebs- und Teammodell
Plattform, Pipelines und Signaturdienst in Etappen
Monitoring, Audits, Wissenstransfer
Vor dem ersten Gespräch
Eine konkrete Herausforderung genügt. Diese vier Fragen helfen uns, gemeinsam die richtige Richtung zu finden.
Erstgespräch vereinbarenDie aktuelle Herausforderung und Ihr gewünschtes Ergebnis.
Ein Überblick über Standorte, Anwendungen und Schnittstellen.
Projekttermine, Wartungsfenster und bekannte Abhängigkeiten.
Die passenden Ansprechpartner aus IT, Sicherheit und Betrieb.
Sechs Handlungsfelder von der internen Entwicklerplattform bis zum PQC-Fahrplan für Ihre Produkte, umgesetzt und betrieben von OTOKO®. Signaturschlüssel liegen im HSM, jedes Release trägt SBOM und Signatur, und Nachweise für NIS2, Cyber Resilience Act, ISO 27001 und SOC 2 entstehen im laufenden Betrieb.
IT-Lösungen für IT- und Softwareunternehmen verbinden schnelle Auslieferung mit einer Sicherheit, die Kunden, Prüfer und Gesetzgeber belegt sehen wollen. OTOKO® deckt dafür sechs Handlungsfelder ab: Platform Engineering und interne Entwicklerplattformen, sichere Softwareentwicklung und Lieferkette, Code Signing und Release-Schlüssel im HSM, Managed Cloud und SaaS-Betrieb unter NIS2, Verstärkung für Engineering-Teams sowie Readiness für den Cyber Resilience Act mit PQC-Fahrplan.
Der Unterschied liegt darin, dass Sicherheitsnachweise in der Pipeline entstehen statt kurz vor dem Audit. SBOM, Signatur, Schwachstellenstatus und Betriebsprotokolle fallen bei jedem Release an und beantworten Kundenfragebögen ohne Sonderprojekt. Kryptografie und Hardware-Sicherheitsmodule sind unsere Kernkompetenz; Signaturschlüssel für Software, Container und Firmware liegen deshalb in zertifizierter Hardware statt auf Build-Servern.
Kryptografie und Hardware-Sicherheitsmodule sind unsere Kernkompetenz. Code-Signing-Schlüssel, Release-Schlüssel und die PKI hinter Ihren Produkten liegen deshalb in zertifizierter Hardware statt auf Build-Servern.
Die gesamte Lösung läuft in deutschen Rechenzentren, von der Entwicklerplattform bis zum Signaturdienst. Das hilft bei Kunden, die Datenhaltung in Deutschland vertraglich verlangen.
Wir arbeiten mit Betreibern kritischer Infrastrukturen und regulierten Branchen. Wir wissen daher, welche Nachweise Ihre Kunden aus Finanzsektor, Energie und Verwaltung in Ausschreibungen verlangen.
Ein Team begleitet Sie von der Beratung bis zum Betrieb. Plattformingenieure, Sicherheitsarchitekten und Kryptografie-Spezialisten bleiben an Bord, ohne Übergabe an Dritte.
Den meisten Softwareunternehmen fehlt nicht das technische Können, sondern der Nachweis, den Kunden, Prüfer und Gesetzgeber inzwischen verlangen.
01
Jedes Produktteam betreibt eigene Cluster, Pipelines und Monitoring, Sicherheitsprüfungen unterscheiden sich von Team zu Team und das Plattformteam arbeitet vor allem Tickets ab.
02
Abhängigkeiten sind nicht inventarisiert, Build-Artefakte tragen keine Signatur und bei einer neuen Schwachstelle sucht das Team tagelang nach den betroffenen Versionen.
03
Code-Signing-Schlüssel liegen in CI-Variablen oder auf Entwicklerrechnern, mehrere Personen kennen das Passwort und niemand kann belegen, wann welche Signatur entstanden ist.
04
NIS2, Cyber Resilience Act und Kundenaudits kommen gleichzeitig, während die Engineering-Kapazität des Jahres bereits für neue Funktionen verplant ist.
| On-Premises | Deutsche Cloud | Hyperscaler | |
|---|---|---|---|
| Datenhaltung | Ihr Rechenzentrum, Ihre Build-Server und HSM | Rechenzentren in Deutschland, betrieben nach ISO 27001 | Azure, AWS oder Google Cloud, Region wählbar |
| Betrieb | Ihr Team oder OTOKO® als Managed Service | OTOKO®, mit Auditrechten für Ihre Kundenprüfungen | Gemeinsam, Plattformdienste durch den Anbieter |
| Werkzeuge | Kubernetes, GitLab, Netzwerk-HSM für Code Signing | Gehostete Kubernetes-Plattform, HSM as a Service, Backup mit Veeam | Verwaltete Kubernetes-Dienste, Cloud-HSM, Pipeline-Dienste des Anbieters |
| Geeignet für | Signaturschlüssel, Build-Umgebungen mit strengen Kundenauflagen | SaaS für Kunden aus regulierten Branchen mit Souveränitätsanforderungen | SaaS mit internationalen Kunden, Lastspitzen, Testumgebungen |
| Compliance | Volle Kontrolle, Nachweise aus Ihrem ISMS | Auftragsverarbeitung nach DSGVO, Standort Deutschland, Belege für Kundenaudits | Auftragsverarbeitung, Standardvertragsklauseln, geteilte Verantwortung je Dienst |
Zusammenarbeit
Projekt
Klar abgegrenztes Vorhaben wie ein Signaturdienst im HSM oder eine Entwicklerplattform, mit festem Ergebnis, Meilensteinen und Abnahme.
Team-Verstärkung
Plattformingenieure, Security Engineers oder Entwickler arbeiten in Ihren Teams, mit Ihren Werkzeugen und nach Ihrer Definition of Done.
Managed Service
OTOKO® betreibt Plattform, Cloud-Konten oder Signaturdienst mit vereinbarten Leistungswerten, Berichten und den Meldewegen, die NIS2 verlangt.
Was jede Vorgabe von IT- und Softwareunternehmen verlangt und was OTOKO® dafür liefert.
| Vorgabe | Verlangt | OTOKO® liefert |
|---|---|---|
| ISO 27001 | ISMS mit Risikobeurteilung, Erklärung zur Anwendbarkeit, Maßnahmen aus Anhang A und jährlichen Überwachungsaudits | Aufbau des ISMS, Erklärung zur Anwendbarkeit, technische Maßnahmen in Plattform und Pipeline, Vorbereitung auf das Zertifizierungsaudit |
| SOC 2 | Prüfung von Kontrollen nach den Trust Services Criteria des AICPA, als Type I zu einem Stichtag oder Type II über einen Zeitraum | Kontrollrahmen mit Zuordnung zu ISO 27001, automatisierte Evidenz aus Cloud und Pipeline, Vorbereitung auf die Prüfung durch den Wirtschaftsprüfer |
| NIS2 | Risikomanagementmaßnahmen nach Artikel 21, gestufte Meldung erheblicher Vorfälle, Sicherheit in der Lieferkette und Verantwortung der Geschäftsleitung | Betroffenheitsanalyse, Maßnahmenplan, Meldeprozess mit Vorlagen, Lieferantenregister, Schulungsunterlagen für die Geschäftsleitung |
| Cyber Resilience Act | Sicherheit durch Design, SBOM, Schwachstellenbehandlung über den Supportzeitraum, Meldung aktiv ausgenutzter Schwachstellen und CE-Kennzeichnung | Produkteinstufung, Lückenanalyse, SBOM-Prozess, Meldeprozess, technische Dokumentation für die Konformitätsbewertung |
| DSGVO | Datenschutz durch Technikgestaltung, Auftragsverarbeitung, Verzeichnis der Verarbeitungstätigkeiten und Garantien bei Übermittlung in Drittländer | Datenschutzkonzept für SaaS-Produkte, Auftragsverarbeitungsvertrag, Verschlüsselung mit Schlüsseln im HSM, Betrieb in Deutschland |
Häufige Fragen
15 Antworten zu Ihrer Branche, zum Projekt und zum Betrieb danach.
Das Angebot umfasst interne Entwicklerplattformen auf Kubernetes, sichere Softwareentwicklung mit SBOM und signierten Builds, Code Signing mit Schlüsseln im HSM und den Betrieb von Cloud- und SaaS-Plattformen unter NIS2. Dazu kommen Fachkräfte, die Ihre Engineering-Teams verstärken, sowie Readiness für den Cyber Resilience Act mit einem PQC-Fahrplan. Jedes Handlungsfeld lässt sich einzeln oder als Paket beauftragen.
Ein gestohlener Signaturschlüssel erlaubt es Angreifern, Schadsoftware als Ihr offizielles Update auszuliefern. Im HSM wird der Schlüssel erzeugt und verlässt das Gerät nicht im Klartext, und jede Signatur braucht eine Berechtigung und wird protokolliert. Für öffentlich vertrauenswürdige Code-Signing-Zertifikate verlangen die Baseline Requirements des CA/Browser Forum ohnehin einen Schlüssel in Hardware.
Das hängt von Tätigkeit und Größe ab. Anbieter von Cloud-Diensten, Rechenzentren und Managed Services fallen ab mittlerer Unternehmensgröße direkt unter NIS2, reine Softwarehersteller meist nicht. Viele erhalten die Anforderungen aber über ihre Kunden, die Sicherheit in der Lieferkette nachweisen müssen. Wir arbeiten mit Betreibern kritischer Infrastrukturen und regulierten Branchen und kennen daher die Klauseln, die solche Kunden in Verträge schreiben.
Wer Software oder Geräte mit Software in der EU in Verkehr bringt, muss Sicherheit durch Design nachweisen, eine SBOM erstellen, Schwachstellen über den Supportzeitraum beheben und Sicherheitsupdates bereitstellen. Aktiv ausgenutzte Schwachstellen sind seit September 2026 zu melden, die vollständigen Pflichten mit CE-Kennzeichnung gelten ab Dezember 2027. Reine SaaS-Angebote fallen in der Regel nicht darunter, die zugehörigen Apps und Clients dagegen schon.
Nach einem Abgleich von Anforderungen und Profilen stellen wir Fachkräfte vor, die Sie gemeinsam mit uns auswählen. Sie arbeiten in Ihren Sprints, Repositories und Code-Reviews, mit Zugriffen nach dem Prinzip der minimalen Rechte. Ein Team begleitet Sie von der Beratung bis zum Betrieb, sodass Plattform, Sicherheit und Kapazität von einem Anbieter kommen und der Umfang mit dem Projekt wächst oder schrumpft.
Ja. Wir bauen das ISMS nach ISO 27001 auf, ordnen seine Kontrollen zugleich den Trust Services Criteria von SOC 2 zu und setzen die technischen Maßnahmen in Plattform und Pipeline um. Evidenz wie Zugriffsprotokolle, Änderungsnachweise und Wiederherstellungstests entsteht automatisiert. Das Zertifikat erteilt eine akkreditierte Zertifizierungsstelle, den SOC-2-Bericht erstellt ein unabhängiger Wirtschaftsprüfer.
Ja. Wir können zunächst eine konkrete Aufgabe abgrenzen. Dabei betrachten wir ihre Schnittstellen zur übrigen Infrastruktur und stimmen vor der Umsetzung ab, welche Leistungen zum Auftrag gehören.
Eine kurze Beschreibung der Herausforderung, der betroffenen Systeme und Ihres gewünschten Ergebnisses genügt für den Einstieg. Bekannte Termine und die passenden Ansprechpartner helfen zusätzlich. Zugangsdaten oder vertrauliche Systemdokumentation gehören nicht in eine erste Kontaktanfrage.
Plattformarchitekt: Entwicklerplattform, Kubernetes, GitOps. Security Engineer: Secure SDLC, SBOM, Schwachstellenmanagement. Kryptografie-Spezialist: HSM, Code Signing, PQC-Fahrplan. Site Reliability Engineer: Betrieb, Monitoring, Incident Response. Compliance-Berater: NIS2, Cyber Resilience Act, ISO 27001, SOC 2. Projektleitung: Meilensteine, Abnahmen, Berichte.
Wir betrachten Systeme, Schnittstellen, Dokumentationslage und betriebliche Rahmenbedingungen. Ein abgestimmter Umfang und Meilensteine bilden die Grundlage für die Aufwandsschätzung. Eine feste Dauer ohne diese Angaben wäre nicht belastbar.
Plattform, Pipelines, Schlüssel und regulatorische Lücken Priorisierte Maßnahmenliste, Schlüsselinventar, Lückenanalyse zu NIS2, CRA und ISO 27001
Projekt: Klar abgegrenztes Vorhaben wie ein Signaturdienst im HSM oder eine Entwicklerplattform, mit festem Ergebnis, Meilensteinen und Abnahme. Team-Verstärkung: Plattformingenieure, Security Engineers oder Entwickler arbeiten in Ihren Teams, mit Ihren Werkzeugen und nach Ihrer Definition of Done. Managed Service: OTOKO® betreibt Plattform, Cloud-Konten oder Signaturdienst mit vereinbarten Leistungswerten, Berichten und den Meldewegen, die NIS2 verlangt.
Monitoring, Audits, Wissenstransfer Monitoring, Schlüsselrotation, Audit- und Meldebegleitung, schrittweise Übergabe
Das lässt sich im ersten Konzept berücksichtigen. Dokumentierte Schnittstellen und wiederverwendbare Regeln schaffen eine Grundlage für den Ausbau. Jeder zusätzliche Standort und jedes neue System werden dennoch auf ihre besonderen Anforderungen geprüft.
Zuständigkeiten, wiederkehrende Aufgaben und Änderungsabläufe werden zusammen mit der technischen Umsetzung festgelegt. Dokumentation und Wissenstransfer helfen Ihrem Team im Alltag. Welche Tätigkeiten und laufende Unterstützung dazugehören, wird im Leistungsumfang vereinbart.
IT- und Softwarebranche
Lassen Sie uns besprechen, wie Ihre Plattform sicherer wird und Ihr Team die Kapazität gewinnt, die es braucht.
Erstgespräch vereinbaren