Compliance
If you integrate OpenIAP into a product placed on the EU market, you may carry obligations under the Cyber Resilience Act. This page describes what OpenIAP publishes to support that work.
The dates that matter#
| Date | What applies |
|---|---|
| 11 September 2026 | Reporting obligations: 24-hour early warning and 72-hour notification. The final report is due 14 days after a vulnerability fix or mitigation becomes available, or one month after a severe-incident notification |
| 11 December 2027 | The main product security requirements, including the essential cybersecurity requirements and conformity assessment |
Reporting starts more than a year before the product requirements do, which is why the reporting path is the part worth having ready first.
What OpenIAP provides#
| Your need | What to use |
|---|---|
| Component inventory for a product you ship | The current-release SBOM, in CycloneDX 1.6 |
| Evidence of where a release came from | Provenance attestation on the SBOM, npm provenance for releases published through the current npm workflows, and a release tag bound to the verified full commit at check time. Legacy openiap-conformance 1.0.0 predates npm provenance |
| A channel to report a vulnerability you found | Private reporting with a documented response timeline — see Overview |
| Whether a flagged CVE actually affects you | VEX statements carried in the SBOM, where an analysis exists |
| Evidence for behaviors already bound to shipped SDKs | The conformance coverage matrix and each implementation's tests |
What OpenIAP will not issue is a compliance attestation or warranty on behalf of a downstream manufacturer. That would move legal responsibility upstream, which the CRA's guidance for open-source stewards explicitly warns against.
Behavioral conformance#
A type-level contract proves an SDK declares an API. It does not prove the API does anything. An implementation could declare restorePurchases and return immediately while passing every type check.
The openiap-conformance suite provides a versioned behavioral contract: permanent behavior ids, RFC-2119 levels, and capability gates derived from a store capability matrix rather than self-declared by the adapter. Where an SDK or native implementation is bound to that contract, a missing MUST behavior is reported as a failure, not skipped.
This produces reproducible evidence for the behaviors currently bound to a specific implementation. Coverage is partial: Expo, React Native, Android, Apple, and IAPKit each cover documented subsets; Flutter, KMP, MAUI, and Godot do not yet have adapters. The reference adapter proves the suite runs, not that a shipped SDK conforms. Even with that boundary, the first implementation runs surfaced real entitlement defects, including a pending subscription treated as active.
- Ecosystem — which SDKs implement the specification
- packages/conformance — the suite, its adapter contract, and how to run it
OpenChain self-assessment#
OpenIAP maintains an internal gap assessment against ISO/IEC 18974 (open source security assurance) and ISO/IEC 5230 (license compliance). These are Linux Foundation standards, they are the closest existing ones to what the CRA expects of a software supplier, and they are expressed as verifiable materials rather than legal language.
The assessment is published as a gap list, not a conformance claim — it records what exists, what does not, and what is out of proportion for a project of this size. Met today: the public reporting channel with a documented response path and the declared license policy. The named security-assurance policy and release controls exist, while policy-communication evidence, competency and assessment records, historical SBOM and action records, attribution generation, and formal self-affirmation remain incomplete.
A note on roles#
The CRA distinguishes manufacturers, open-source stewards, and everyone else. A steward must be a legal person that systematically supports open-source software intended for commercial activities; individual maintainers and unincorporated projects fall outside that definition.
OpenIAP does not assert a determination about its own status here. The practices are maintained either way, because the value of an accurate inventory and a working reporting path does not depend on which label applies.
Sources#
This page is a reading of public material, not legal advice. Where it and the regulation disagree, the regulation governs.
- Regulation (EU) 2024/2847 — the Cyber Resilience Act itself
- European Commission — CRA and open source
- OpenSSF CRA Stewards Playbook — the practical checklist behind the obligations above
- Open Regulatory Compliance WG — steward FAQ
- OpenChain ISO/IEC 18974 — the security-assurance standard the gap assessment uses
- OpenChain ISO/IEC 5230 — its license-compliance counterpart