24-Hour Early Warning
Actively exploited vulnerabilities must be reported to ENISA Single Reporting Platform within 24 hours of detection. This is not a manually manageable process.
CRA-native IoT security platform
CRA compliance in a single SDK — the IoT security platform.
End-to-end protection from chip to cloud. Dynamic SBOM, active exploitation detection, and automated 24-hour ENISA SRP reporting — all in one low-footprint library.
$141.8B
Global IoT security market, 2030
15B+
Connected devices in the EU
24 hrs
Article 14 reporting window
integration.ts
1import { TegmenSoft } from "@tegmensoft/sdk"
2
3const client = new TegmenSoft({
4 deviceId: process.env.DEVICE_PUF_ID,
5 region: "eu-central-1"
6})
7
8// SBOM scan — SPDX 2.3 generation
9await client.sbom.scan()
10
11// Active vuln → ENISA SRP < 24h report
12await client.report.submit()
13
14// Signed firmware deploy — Ed25519
15await client.ota.deploy(patch)
🏛️ Teknopol IstanbulENISA SRP·ReportingSPDX 2.3·SBOMCycloneDX 1.7·SBOMEN 18031·StandardCE Marking·MarketEUCC·Certificate
Cyber Resilience Act
Europe has set a new legal threshold for IoT.
The CRA is the EU's first horizontal cybersecurity regulation for products with digital elements. It covers all manufacturers from design to post-sale lifecycle — and becomes operational in September 2026.
Non-Compliance Cost
€15M
or of global annual turnover %2,5
Means revocation of CE marking and complete loss of EU market access.
Dynamic Component Transparency
Manufacturers must track all open-source and commercial components (SPDX / CycloneDX) in real-time and report exploitability via VEX reports.
Cryptographic Audit Trail
Event logs and audit records must be stored cryptographically signed throughout the product lifecycle (at least 10 years).
Harmonized standards, risk classification and detailed technical requirements →
CRA GuidePlatform
Diagnose → Detect → Act → Deploy
Competitors silo this cycle. TegmenSoft completes every stage within a single SDK.
DIAGNOSEQ3 2026
Dynamic SBOM Engine
Software Bill of Materials & CVE Matching
Extracts a real-time inventory of all software components (open-source and commercial) running on the device; automatically matches them against NVD and MITRE CVE databases. Produces signed SBOM in SPDX and CycloneDX formats.
- Automatic dependency discovery (binary + manifest)
- SPDX 2.3 and CycloneDX 1.7 generation
- NVD, OSV, MITRE CVE matching
- VEX (Vulnerability Exploitability eXchange) output
DETECTQ3 2026
Telemetry & Active Exploitation Detection
Article 14 Trigger Mechanism
Detects not just theoretical vulnerabilities but active in-the-wild exploitation through device logs and alarms. The early warning layer that triggers CRA Article 14's 24-hour reporting obligation.
- Device-to-cloud log streaming over mTLS
- Behavioral anomaly and IoC correlation
- Vulnerability × telemetry matching
- Severity scoring engine
ACTQ3 2026
ENISA SRP Automated Reporting
< 24 Hour Legal Notification Automation
Automatically converts detected vulnerabilities into ENISA Single Reporting Platform (SRP) format; prepares early warning, 72-hour full notification, and 14-day final report drafts including affected member states, product lines, and mitigation steps.
- ENISA SRP schema-compliant output
- 24h / 72h / 14-day automated schedule
- Automatic affected market and device pool mapping
- Signed audit trail
DEPLOYActive
Secure OTA Distribution
Signed Firmware, Bricking Protection
Cryptographically signed (Ed25519 / RSA-PSS) secure firmware distribution with A/B partition rollback and bricking protection — deploys vulnerability patches fleet-wide within hours.
- Cryptographic signature verification (Ed25519 / RSA-PSS)
- A/B partition rollback
- Staged (canary) deployment and fleet segmentation
- Delta updates for low-bandwidth devices
Architecture
Chip-to-Cloud three-layer security
A single control plane from hardware identity to cloud reporting. Each layer is built as a cryptographic foundation that the layer above can trust.
Layer 01
Device Security
MCU / Embedded Linux
Starting at Root of Trust and hardware identity level, the fundamental cryptographic identity that all upper layers depend on.
▸
Secure Boot — Signed bootloader chain
▸
Root of Trust — Hardware-rooted identity
▸
TLS 1.3 / AES-256 — End-to-end encrypted channel
▸
SDK Agent — Telemetry, OTA, log management
Layer 02
SDK & Orchestration
Chip-to-Cloud Control Plane
The middle layer housing PKI/CA, SBOM engine, and OTA server. Integrates into CI/CD pipelines as a low-footprint library.
▸
PKI / CA — Certificate and key rotation
▸
SBOM Engine — SPDX, CycloneDX, VEX generation
▸
OTA Server — Signed firmware distribution
▸
Event Correlation — IoC and behavioral analysis
Layer 03
Data & Analytics
Multi-tenant Cloud
Multi-tenant cloud layer; each manufacturer's fleet, audit trails, and reports are isolated with RLS guarantees.
▸
SQL Server + RLS — Row-level isolation
▸
ENISA SRP Bridge — Automated notification drafts
▸
10-Year Archive — Signed audit logs
▸
Compliance Dashboard — Fleet-level compliance status
Timeline
CRA enforcement process and critical milestones
The official Cyber Resilience Act timeline and what each phase means for manufacturers.
December 10, 2024
Entry into Force
Cyber Resilience Act (Regulation (EU) 2024/2847) published in the EU Official Journal and entered into force.
January 2025
Standardization Request
European Commission submitted a formal request to CEN-CENELEC for the development of harmonized standards.
September 11, 2026
Reporting Obligation Begins
24-hour ENISA SRP notification requirement for actively exploited vulnerabilities becomes legally binding.
November 2026
Harmonized Standards
EN 18031 family and other harmonized standards are published; compliance path clarifies for manufacturers.
December 11, 2027
Full Compliance
CRA requirements and CE marking obligations become fully mandatory for all products with digital elements.
Breaking Point: 11.09.2026 from this date, reporting actively exploited vulnerabilities to ENISA SRP within 24 hours becomes a legal prerequisite. Manual processes cannot meet this threshold — automation is mandatory.
Risk Classification
Same SDK for every risk class, different audit depth
The CRA divides products into four risk classes. While audit intensity varies, SBOM, vulnerability reporting, and secure OTA are common technical requirements across all classes.
DEFAULT
Default
Example
Smart home devices, consumer IoT, smart toys
Audit
Self-assessment (Module A) sufficient
IMPORTANT
Important — Class I
Example
Authentication systems, VPNs, network management tools
Audit
Notified Body involvement may be required
IMPORTANT
Important — Class II
Example
Industrial firewalls, operating systems, microprocessors
Audit
Third-party examination (Type Examination) mandatory
CRITICAL
Critical
Example
Smart meters, HSM modules, smart cards, health hardware
Audit
Full authorized audit under EUCC
Why TegmenSoft
Technical differentiation from global competitors
We're building the regulation gateway — not a tool, but the infrastructure everyone must pass through.
Advantage
Competitor Approach
TegmenSoft Difference
01
01 · End-to-End vs. Siloed
End-to-End CRA Solution
End-to-End vs. Siloed
Competitor Approach
Most global competitors offer only SBOM scanning (Keyfactor, Snyk) or only OTA management.
TegmenSoft Difference
Unifies Diagnosis (SBOM), Detection (Telemetry), Reporting (Article 14), and Remediation (OTA) in a single SDK; completes the full remediation cycle.
02
02 · Market Accessibility
Scalable Licensing
Market Accessibility
Competitor Approach
Existing enterprise solutions require high entry costs and months of integration.
TegmenSoft Difference
Multi-tenant SaaS architecture enables per-device licensing; provides cost and speed advantages for mid-size IoT manufacturers.
03
03 · Hardware-Agnostic & Low-Footprint
Hardware-Agnostic, Low Footprint
Hardware-Agnostic & Low-Footprint
Competitor Approach
Existing solutions are typically Linux-focused; they don't run on embedded MCU class.
TegmenSoft Difference
Runs across ESP32, ARM Cortex-M, and embedded Linux with minimum CPU/RAM consumption. No need to modify existing hardware designs.
04
04 · ENISA SRP & CRA Native
Regulatory Depth
ENISA SRP & CRA Native
Competitor Approach
Generic cybersecurity tools offer regulation-compliance as a bolted-on feature.
TegmenSoft Difference
Built directly on CRA Article 14, ENISA SRP, and EN 18031 standards; compliance automation is the core product.
Team
The team meeting regulatory pressure with technical architecture
Bringing together industry experience in IoT, cryptography, scalable cloud, and regulatory strategy under one roof.
BÖ
Burak Öztürk
Co-Founder & CEO
Based at Teknopol Istanbul. EU market strategy, business development and regulatory relations. 8+ years of IoT industry experience. Deep familiarity with European manufacturer networks and market dynamics.
MG
Mehmet Gümüş
Co-Founder & CTO
Cryptographic protocol design, chip-to-cloud SDK architecture, embedded security. Developing secure software update and telemetry infrastructure for resource-constrained systems.
SB
Sevilay Bayuk
Co-Founder & CFO
Enterprise scaling, growth strategy and financial architecture.
FAQ
Most common questions from manufacturers
If you're a CISO or hardware team lead, here are the technical and operational answers you'll need for your initial assessment.
Designed for hardware and software manufacturers selling products with digital elements (IoT, embedded, network-connected) to the European market. Smart meter, appliance, industrial equipment, network device, and healthcare hardware manufacturers are our primary user profiles.
The Tegmensoft SDK works as a low-footprint library added to the build step. SBOM generation happens at build-time, while telemetry and reporting run at runtime. Directly compatible with Jenkins, GitLab CI, GitHub Actions, and Azure DevOps pipelines.
ESP32, STM32, NXP i.MX, Raspberry Pi, and all platforms running embedded Linux are supported. Minimum footprint target for MCU class: 256 KB Flash / 64 KB RAM.
Yes. Since the CRA also covers products already in the field, a signed SDK update via our tegmensoft-ota module enables retrofit integration with existing fleets.
Stored in EU regions (Frankfurt / Amsterdam) or Turkey (Istanbul) based on manufacturer preference. Multi-tenant architecture isolates each customer's data with Row-Level Security (RLS).
September 2026 — Breaking Point
Join our pilot manufacturer program and be ready on CRA day.
We provide early pilot manufacturers with preferential per-device licensing, a dedicated integration team, and compliance documentation. Let's schedule a 30-minute technical introduction.
CRA Article 14 start
11 September 2026
—GÜN
——SAAT
——DK
——SN
Early-stage pilot capacity is limited. Manufacturers exporting to Germany, Netherlands, and Scandinavian markets are prioritized.