CRA reporting from 2026
For covered actively exploited vulnerabilities and severe incidents, the reporting workflow includes an early warning within 24 hours and a full notification within 72 hours after the manufacturer becomes aware.
SECURITY · CRA OSBuilding
Cyber Resilience Act for digital products
A building product-security operating system for software manufacturers and producers: connect repositories, releases, SBOMs, vulnerabilities, evidence, and incidents so CRA work becomes a traceable operating workflow rather than a one-off document.
Article 14 applies from 11 September 2026
General CRA application: 11 December 2027
Regulatory decisions and reporting remain under human authority
CYBER RESILIENCE ACT
Two different dates that should not be conflated.
Article 14 reporting obligations already apply from 11 September 2026. General application of the Regulation begins on 11 December 2027. The product keeps these milestones separate rather than presenting all CRA obligations as future work.
General application in 2027
The broader CRA framework generally applies from 11 December 2027. The roadmap separates obligations already in force, future requirements, and readiness evidence.
Human authority
Deterministic rules, source evidence, and authorized human approval remain the decision boundary. AI may summarize or draft, but it does not independently determine obligations or submit reports.
SBOM · SOFTWARE BILL OF MATERIALS
An SBOM provides component context; the value comes from connecting it to releases, risk, and evidence.
The planned architecture generates CycloneDX SBOMs in an isolated worker, normalizes components, and correlates vulnerabilities with the affected product and release. That phase still depends on closing the production GitHub connector E2E gate.
Product, repository, and release
The foundation already models products, repositories, and releases with organization isolation, full commit identities, and preserved history so evidence can be tied to exact versions.
Governed GitHub connection
The GitHub App connector is integrated with identity, RBAC, and explicit repository selection. Its real production E2E acceptance remains open before the next phase is enabled.
SBOM and vulnerability context next
The next phase will generate and normalize CycloneDX SBOMs, correlate components and vulnerabilities, and preserve product/release context. It is not presented as production-accepted capability yet.
ROADMAP
Real product status without claiming future capabilities.
This landing separates what is already integrated from what still depends on production acceptance or later phases.
Product inventory
Product, repository, and release inventory is complete and verified on main.
GitHub App
Implementation is integrated; real private-repository production E2E acceptance is still required.
SBOM + vulnerabilities
Isolated worker, CycloneDX generation, and vulnerability correlation follow the production connector gate.
CRA Incident Center
Awareness timestamps, deadlines, evidence, actions, and a human-reviewed reporting package.
BOUNDARIES
It is not another scanner or an automatic compliance certificate.
Product Security is designed to consume repository and security-tool signals, add product context, preserve evidence, and operate CRA workflows. It does not replace SAST/DAST/SCA, exploit systems, make autonomous legal determinations, or submit regulatory notifications without explicit human authorization.
TRUST & CONTROL
Authority stays explicit as the platform grows.
Kairoseth separates identity, organization scope, product roles and product capabilities. A login route, browser state or AI response never becomes an authorization boundary by itself.
KAIROSETH PLATFORMCONTROL PLANE
- Identity
- Shared account
- Verified
- Organization
- Tenant scope
- Required
- Product
- RBAC assignment
- Explicit
- Sensitive actions
- Policy gate
- Controlled
Organization scope
Customer resources and access are resolved inside an active organization context rather than treated as global account state.
Product-scoped roles
Owner, Admin and Member authority is assigned per product. Organization membership alone does not automatically grant every product.
Server authority
Sensitive access, policy and capability decisions remain authoritative on the server instead of trusting client UI state or model output.
Controlled execution
Capabilities that can act are introduced behind explicit grants, staged gates and audit rather than implied autonomy.
Public trust evidence
Review the customer-facing policies that define privacy, security reporting, acceptable use and the current legal operating framework.
CRA OS · PRODUCT SECURITY
A continuous product-security and CRA evidence foundation.
The product is still building; its next gate is real production E2E acceptance of the GitHub connector.