®01
Platform engineering and internal developer platforms
Platform architecture with reference templates for new services
More on thisIndustries / Information
Digital services. Reliable infrastructure.
Develop software securely and build and operate reliable platforms.
Consulting. Integration. Operations.
Built around your industry.
- Software vendors
- SaaS and platform providers
- IT service providers and managed service providers
- Engineering teams with capacity gaps
Your priorities
Understand the challenge. Shape the solution.
We build internal developer platforms on Kubernetes and public cloud, anchor security in every phase of your development lifecycle, and reinforce your teams with experienced engineers.
02
Code signing and release keys on HSMs
HSM architecture with key inventory and ceremony record
More on this03
Staff augmentation for engineering teams
Role profiles and staffing plan per team
More on thisFrom strategy to implementation
Six service modules
Six fields of expertise. Explore the scope that fits your project.
01Platform engineering and internal developer platformsKubernetes · Backstage · Terraform
Our approach
An internal developer platform provides infrastructure, pipelines, monitoring and security rules as self-service, so product teams ship without filing tickets. We build it on Kubernetes with Backstage as the developer portal, Terraform for infrastructure and Argo CD for delivery through GitOps. Guardrails as policy as code check every resource before it goes live. The platform is run like a product, with a backlog, user feedback and measured lead time.
Full scope
- Assessment of toolchain, clusters and developer journeys with measurement of lead time and change failure rate
- Developer portal on Backstage with software catalog, templates for new services and documentation as code
- Kubernetes platform with Terraform for infrastructure and GitOps delivery through Argo CD
- Guardrails as policy as code with Kyverno or Open Policy Agent for resources, images and network rules
- Observability with OpenTelemetry, Prometheus and Grafana as a fixed part of every template
A SaaS provider with several product teams creates new services from templates in the developer portal; namespace, pipeline and monitoring are set up without a ticket to the platform team.
What you get
- Platform architecture with reference templates for new services
- Developer portal with software catalog and documentation
- Policy package as code with operations manual
02Secure development lifecycle and software supply chainSonarQube · Dependency-Track · CycloneDX
Our approach
Customers, auditors and the Cyber Resilience Act want to know which components are in your software and whether the build is untampered. We anchor threat modeling, static code analysis, secret scanning and dependency scanning as mandatory steps in the pipeline. Every release gets an SBOM in CycloneDX or SPDX, signed artifacts and provenance under SLSA. New vulnerabilities in dependencies are mapped automatically to the affected versions and fixed within deadlines by severity.
Full scope
- Threat modeling with STRIDE for new features and architecture changes, anchored in the definition of done
- Static code analysis, secret scanning and dependency scanning as mandatory checks in GitHub Actions or GitLab CI
- SBOM in CycloneDX or SPDX for every release, analyzed in Dependency-Track
- Signed container images and provenance under SLSA with Sigstore Cosign, verified before deployment
- Vulnerability management with CVSS and EPSS scoring, deadlines per severity and VEX statements for customers
A vendor of industry software ships an SBOM and signed images with every release; customer inquiries about a new vulnerability are answered with a VEX statement instead of a manual search.
What you get
- Secure SDLC policy with checks per pipeline stage
- SBOM, signature and provenance per release
- Vulnerability register with deadlines and VEX templates
03Code signing and release keys on HSMsThales Luna Network HSM · Entrust nShield 5c · Utimaco u.trust GP HSM Se-Series
Our approach
Anyone who steals a code signing key can ship malware under your name, so the key does not belong on build servers or developer laptops. For publicly trusted code signing certificates, the Baseline Requirements of the CA/Browser Forum already require the private key to be generated and stored in hardware. We select network HSMs from Thales, Entrust or Utimaco vendor-neutrally, connect build pipelines over PKCS#11 and set up a signing service with approvals. Every signature for Windows binaries, container images, packages or firmware is logged and tied to a release.
Full scope
- Inventory of all signing keys and certificates for Windows binaries, containers, packages, mobile apps and firmware
- HSM selection and setup with redundancy across several sites, key generation in a recorded ceremony
- Signing service with build pipelines connected over PKCS#11 and dual approval for release signatures
- Certificate lifecycle with EverTrust PKI or a public CA, renewal under the Baseline Requirements of the CA/Browser Forum
- Time stamps under RFC 3161, logging of every signature and an emergency plan for revoking compromised certificates
A desktop software vendor moves its code signing key from the build server into a network HSM; release signatures need a second approval and are tied to each build.
What you get
- HSM architecture with key inventory and ceremony record
- Signing service with pipeline integration and approval rules
- Operations manual with rotation, revocation and emergency plan
04Managed cloud and SaaS operations under NIS2Kubernetes · Microsoft Azure · AWS
Our approach
Depending on their size, NIS2 classifies providers of cloud services, data centers and managed services as important or essential entities, and in Germany the NIS2 implementation act sets out the obligations. It requires risk management measures under Article 21, staged reporting of significant incidents, supply chain security and a management body that is accountable for them. We operate your Kubernetes platform and cloud accounts with monitoring, on-call duty, incident response and tested recovery. Reporting channels, a supplier register and operations evidence are part of operations and also answer your customers' security questionnaires.
Full scope
- Scope assessment under NIS2 and the German implementation act, registration with the BSI and assignment of duties to roles
- Operation of Kubernetes clusters and cloud accounts with landing zone and hardening under CIS Benchmarks
- Monitoring with service level objectives, on-call duty and incident response with templates for early warning, notification and final report
- Backup with Veeam, recovery tests and contingency plans per service and tenant
- Supplier register for cloud and software providers with security requirements and evidence for customer audits
An HR software provider hands over the operation of its Kubernetes platform; incidents follow a documented reporting process, and the team answers security questionnaires from the operations evidence.
What you get
- NIS2 scope assessment with action plan under Article 21
- Operations manual with reporting process and escalation paths
- Reports on recovery tests and operational metrics
05Staff augmentation for engineering teamsJava · TypeScript · Go
Our approach
When roadmap and regulation tie up capacity at the same time, OTOKO® specialists join your teams for an agreed period. Backend and frontend developers, platform engineers, test automation engineers and security engineers take on tasks in your sprints, repositories and code reviews according to your definition of done. They receive access under the principle of least privilege, and decisions are documented in architecture decision records and runbooks so the knowledge stays with your team after the engagement.
Full scope
- Matching of requirements, technology stack and team structure with suitable profiles and joint selection
- Work in backend, frontend, platform, test automation and security engineering within your sprints
- Onboarding with an access concept under the principle of least privilege, confidentiality agreement and briefing on your policies
- Work in your repositories, tickets and code reviews according to your definition of done
- Knowledge transfer through architecture decision records, runbooks and pair programming with your team
A software house reinforces its platform team with DevOps and test engineers ahead of a customer rollout; after the rollout its own team takes over the documented pipelines.
What you get
- Role profiles and staffing plan per team
- Access concept and onboarding checklist
- Architecture decision records, runbooks and handover documentation
06Cyber Resilience Act readiness and PQC roadmap for productsML-KEM (FIPS 203) · ML-DSA (FIPS 204) · SLH-DSA (FIPS 205)
Our approach
The Cyber Resilience Act obliges manufacturers of products with digital elements, including software, to deliver security by design, an SBOM and vulnerability handling throughout the support period. The reporting obligations for actively exploited vulnerabilities and severe incidents have applied since September 11, 2026, and all other obligations apply from December 11, 2027. We classify your products, close gaps against Annex I and set up the reporting process. Because products and their update signatures often stay in use longer than RSA and elliptic curves remain secure against quantum computers, we also create a cryptography inventory and a roadmap to ML-KEM and ML-DSA.
Full scope
- Classification of products under the Cyber Resilience Act as default, important or critical product with the matching conformity procedure
- Gap analysis against the essential requirements of Annex I and setup of the technical documentation
- Process for vulnerability handling and reports through the ENISA reporting platform with deadlines for early warning, notification and final report
- Cryptography inventory per product as a CBOM with algorithms, key lengths, libraries and update signatures
- PQC roadmap with ML-KEM, ML-DSA and hybrid schemes under BSI TR-02102, update signatures with LMS for long-lived devices
A VPN software vendor classifies its product as an important product, sets up the reporting process for actively exploited vulnerabilities and moves its update signature step by step to a hybrid scheme.
What you get
- Product classification and gap analysis for the Cyber Resilience Act
- Reporting process with templates and owners
- Cryptography inventory and PQC roadmap per product
Typical project situations
Where change becomes tangible.
A specific challenge is often the starting point. These examples connect a typical situation with a possible approach and the intended result.
Illustrative situations, not customer references.
01 / Information
Signed releases at a software vendor
Code signing key stored as a file on the build server, several people know the password, a certificate renewal under new hardware rules is due.
Solution
Network HSM with recorded key generation, signing service with approval, pipelines connected over PKCS#11.
Key in a certified HSM, every signature tied to a build, renewed certificate under the Baseline Requirements.
02 / Information
Developer platform at a SaaS provider
Every product team runs its own clusters and pipelines, new services wait for tickets, security checks are inconsistent.
Solution
Internal developer platform with Backstage, GitOps through Argo CD, guardrails as policy as code and observability in every template.
New services from templates, consistent checks in all pipelines, platform team works on the product instead of tickets.
03 / Information
NIS2 and customer audits at a managed service provider
The provider falls under NIS2, major customers require a SOC 2 report and there is no documented reporting process.
Solution
Scope assessment, ISMS under ISO 27001 mapped to SOC 2, reporting process with templates, recovery tests.
Registration with the BSI, reporting channels in daily operations, evidence for the certification audit and the SOC 2 examination.
Working together
A clear path. With your team.
From an initial assessment to ongoing operations, we agree on priorities, responsibilities and the results of each stage.
How we work
- 01
Assessment
Platform, pipelines, keys and regulatory gaps
Prioritized measures, key inventory, gap analysis for NIS2, CRA and ISO 27001 - 02
Concept
Target platform, security controls, operating and team model
Platform architecture, secure SDLC policy, HSM concept for code signing, operating model - 03
Implementation
Platform, pipelines and signing service in stages
Platform in production, signed releases with SBOM, documentation and acceptance per stage - 04
Operations
Monitoring, audits, knowledge transfer
Monitoring, key rotation, audit and reporting support, stepwise handover
Before our first conversation
You do not need all the answers yet.
Start with a concrete challenge. These four questions help us find the right direction together.
Book a first consultation- 01
What should change?
Your current challenge and the outcome you are aiming for.
- 02
Which systems are involved?
An overview of sites, applications and interfaces.
- 03
What sets the boundaries?
Project dates, maintenance windows and known dependencies.
- 04
Who needs to be involved?
The right people from IT, security and operations.
Background & decision criteria
What are IT solutions for IT and software companies?
Six modules from the internal developer platform to a PQC roadmap for your products, delivered and operated by OTOKO®. Signing keys stay in HSMs, every release carries an SBOM and a signature, and evidence for NIS2, the Cyber Resilience Act, ISO 27001 and SOC 2 comes out of daily operations.
IT solutions for IT and software companies combine fast delivery with security that customers, auditors and lawmakers want to see proven. OTOKO® covers six modules: platform engineering and internal developer platforms, secure development and supply chain, code signing and release keys on HSMs, managed cloud and SaaS operations under NIS2, staff augmentation for engineering teams, and Cyber Resilience Act readiness with a PQC roadmap.
The difference is that security evidence is produced in the pipeline instead of shortly before the audit. SBOM, signature, vulnerability status and operations logs are created with every release and answer customer questionnaires without a separate project. Cryptography and hardware security modules are our core competence. Signing keys for software, containers and firmware therefore stay in certified hardware instead of on build servers.
Why OTOKO® for IT and software companies
- Cryptography and HSM
Cryptography and hardware security modules are our core competence. Code signing keys, release keys and the PKI behind your products therefore stay in certified hardware instead of on build servers.
- German data centers
The entire solution runs in German data centers, from the developer platform to the signing service. That helps with customers who require data storage in Germany by contract.
- Critical infrastructure and regulated industries
We work with operators of critical infrastructure and regulated industries. We therefore know which evidence your customers from finance, energy and government ask for in tenders.
- One team through to operations
One team accompanies you from consulting to operations. Platform engineers, security architects and cryptography specialists stay on without handover to third parties.
Delivery and details
Typical starting point before a project in IT and software companies
Most software companies do not lack technical skill but the evidence that customers, auditors and lawmakers now demand.
01
Platform sprawl
Every product team runs its own clusters, pipelines and monitoring, security checks differ from team to team and the platform team mostly works through tickets.
02
Supply chain without evidence
Dependencies are not inventoried, build artifacts carry no signature and a new vulnerability sends the team searching for affected versions for days.
03
Signing keys as files
Code signing keys sit in CI variables or on developer laptops, several people know the password and nobody can prove when which signature was created.
04
Regulation meets roadmap
NIS2, the Cyber Resilience Act and customer audits arrive at the same time, while this year's engineering capacity is already planned for new features.
Three operating models
| On-Premises | German cloud | Hyperscaler | |
|---|---|---|---|
| Data location | Your data center, your build servers and HSMs | Data centers in Germany, operated under ISO 27001 | Azure, AWS or Google Cloud, region selectable |
| Operation | Your team or OTOKO® as managed service | OTOKO®, with audit rights for your customer audits | Shared, platform services by the provider |
| Tools | Kubernetes, GitLab, network HSMs for code signing | Hosted Kubernetes platform, HSM as a service, backup with Veeam | Managed Kubernetes services, cloud HSM, provider pipeline services |
| Suited for | Signing keys, build environments with strict customer requirements | SaaS for customers from regulated industries with sovereignty requirements | SaaS with international customers, load peaks, test environments |
| Compliance | Full control, evidence from your ISMS | Processing agreement under GDPR, location Germany, evidence for customer audits | Processing agreement, standard contractual clauses, shared responsibility per service |
Collaboration
Project
Clearly scoped engagement such as a signing service on HSMs or a developer platform, with a defined result, milestones and acceptance.
- Assessment, concept, implementation, handover
- Fixed price or effort by milestone
- Suited for code signing, platform builds and CRA readiness
Team reinforcement
Platform engineers, security engineers or developers work in your teams, with your tools and according to your definition of done.
- Onboarding into your repositories, processes and policies
- Scalable as the project progresses
- Suited for teams with capacity gaps before releases or audits
Managed service
OTOKO® operates the platform, cloud accounts or signing service with agreed service levels, reports and the reporting channels NIS2 requires.
- Monitoring, updates, key rotation and support
- Reporting process, recovery tests and audit rights in the contract
- Suited for providers without their own operations team for platform or HSM
Standards and evidence
What each standard requires of IT and software companies and what OTOKO® delivers for it.
| Requirement | Demands | OTOKO® delivers |
|---|---|---|
| ISO 27001 | ISMS with risk assessment, statement of applicability, Annex A controls and annual surveillance audits | ISMS setup, statement of applicability, technical controls in platform and pipeline, preparation for the certification audit |
| SOC 2 | Examination of controls against the AICPA Trust Services Criteria, as Type I at a point in time or Type II over a period | Control framework mapped to ISO 27001, automated evidence from cloud and pipeline, preparation for the examination by a CPA firm |
| NIS2 | Risk management measures under Article 21, staged reporting of significant incidents, supply chain security and management accountability | Scope assessment, action plan, reporting process with templates, supplier register, training material for management |
| Cyber Resilience Act | Security by design, SBOM, vulnerability handling over the support period, reporting of actively exploited vulnerabilities and CE marking | Product classification, gap analysis, SBOM process, reporting process, technical documentation for the conformity assessment |
| GDPR | Data protection by design, processing agreements, records of processing activities and safeguards for transfers to third countries | Data protection concept for SaaS products, processing agreement, encryption with keys in HSMs, operation in Germany |
FAQ
Good questions. Clear answers.
15 answers about your industry, the project and ongoing operations.
Industry & expertise6 questions
Which IT solutions for IT and software companies does OTOKO® offer?
The portfolio covers internal developer platforms on Kubernetes, secure software development with SBOMs and signed builds, code signing with keys on HSMs and the operation of cloud and SaaS platforms under NIS2. It also includes specialists who reinforce your engineering teams and Cyber Resilience Act readiness with a PQC roadmap. Each module can be commissioned on its own or as a package.
Why should code signing keys be kept in an HSM?
A stolen signing key lets attackers ship malware as your official update. In an HSM the key is generated and does not leave the device in plain text, and every signature requires authorization and is logged. For publicly trusted code signing certificates, the Baseline Requirements of the CA/Browser Forum already require the key to be kept in hardware.
Does NIS2 apply to our software company?
That depends on activity and size. Providers of cloud services, data centers and managed services fall directly under NIS2 from medium size upward, while pure software vendors usually do not. Many still receive the requirements through customers who must prove supply chain security. We work with operators of critical infrastructure and regulated industries and therefore know the clauses such customers write into contracts.
What does the Cyber Resilience Act require from software vendors?
Anyone who places software or devices with software on the EU market must demonstrate security by design, create an SBOM, fix vulnerabilities over the support period and provide security updates. Actively exploited vulnerabilities have had to be reported since September 2026, and the full obligations including CE marking apply from December 2027. Pure SaaS offerings are generally out of scope, while the related apps and clients are in scope.
How do OTOKO® specialists work in our team?
After matching requirements and profiles, we introduce specialists whom you select together with us. They work in your sprints, repositories and code reviews, with access under the principle of least privilege. One team accompanies you from consulting to operations, so platform, security and capacity come from one provider and the scope grows or shrinks with the project.
Does OTOKO® support ISO 27001 and SOC 2?
Yes. We build the ISMS under ISO 27001, map its controls to the SOC 2 Trust Services Criteria at the same time and implement the technical measures in platform and pipeline. Evidence such as access logs, change records and recovery tests is produced automatically. The certificate is issued by an accredited certification body, and the SOC 2 report by an independent CPA firm.
Getting started & delivery5 questions
Can we start with a single area of expertise?
Yes. We can scope a specific task first. We consider its interfaces with the rest of your infrastructure and agree which work is included before implementation.
What should we prepare for the first conversation?
A brief description of the challenge, the systems involved and your desired outcome is enough to start. Known deadlines and the relevant contacts are helpful. Please do not include credentials or confidential system documentation in an initial enquiry.
Who needs to participate in the project?
Platform architect: Developer platform, Kubernetes, GitOps. Security engineer: Secure SDLC, SBOM, vulnerability management. Cryptography specialist: HSMs, code signing, PQC roadmap. Site reliability engineer: Operations, monitoring, incident response. Compliance consultant: NIS2, Cyber Resilience Act, ISO 27001, SOC 2. Project lead: Milestones, acceptance, reporting.
How do you determine the schedule and effort?
We consider the systems, interfaces, available documentation and operational constraints. An agreed scope and milestones provide the basis for estimating effort. A fixed duration without these details would not be reliable.
What does the first stage deliver?
Platform, pipelines, keys and regulatory gaps Prioritized measures, key inventory, gap analysis for NIS2, CRA and ISO 27001
Operations & development4 questions
How can we work together?
Project: Clearly scoped engagement such as a signing service on HSMs or a developer platform, with a defined result, milestones and acceptance. Team reinforcement: Platform engineers, security engineers or developers work in your teams, with your tools and according to your definition of done. Managed service: OTOKO® operates the platform, cloud accounts or signing service with agreed service levels, reports and the reporting channels NIS2 requires.
What happens at handover to operations?
Monitoring, audits, knowledge transfer Monitoring, key rotation, audit and reporting support, stepwise handover
Can we expand to further sites or systems later?
We can account for future expansion in the initial concept. Documented interfaces and reusable rules provide a foundation. Each additional site or system still needs to be assessed for its particular requirements.
How do we keep the solution maintainable?
Agree responsibilities, recurring tasks and change procedures alongside the technical implementation. Documentation and knowledge transfer help your team operate the solution. The specific activities and any ongoing support are part of the agreed scope.
Information
Let's discuss your next step.
Let us discuss how your platform becomes more secure and your team gains the capacity it needs.
Book a first consultation
