The EU CRA Clock Started on 11 September. What Indian Software Exporters Must Do Now
Since 11 September, anyone selling software with digital elements into the EU must report actively exploited vulnerabilities within 24 hours. The same month, attackers compromised npm, PyPI and Terraform release pipelines. An accurate SBOM is now required to meet the deadline.
By Intellinative Research Team ·
Key takeaways
- Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours, then a final report.
- The CRA can apply wherever the manufacturer is established. Products already on the EU market are covered. Indian software exporters are in scope.
- Fines reach €15 million or 2.5% of worldwide turnover, whichever is higher. Full CRA requirements, including SBOMs, apply from 11 December 2027.
- In September 2026 attackers used stolen CI/CD and publishing tokens to push malware through npm, PyPI and, for the first time, the Terraform Registry.
- CERT-In's SBOM/QBOM/CBOM/AIBOM/HBOM guidelines v2.0 and CISA's 2026 SBOM Minimum Elements give Indian teams a practical baseline for building inventories that meet the 24-hour clock.
What started on 11 September 2026
ENISA launched the CRA Single Reporting Platform on 11 September 2026, the day manufacturers' reporting obligations under the Cyber Resilience Act took effect. A single report is automatically passed to the national CSIRTs of every EU member state where the product is available.
| Report | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | 24 hours from becoming aware | 24 hours |
| Notification | 72 hours | 72 hours |
| Final report | 14 days after a fix or mitigation is available | 1 month after the notification |
- 24 hrs CRA early warning for an actively exploited vulnerability (European Commission)
- €15M / 2.5% maximum fine, whichever is higher, for breaching Annex I or Articles 13/14 (CRA Art. 64(2))
- 11 Dec 2027 full CRA requirements apply, including machine-readable SBOMs (ENISA)
- ~1,000 CVEs fixed in Microsoft's September 2026 Patch Tuesday, including 2 exploited zero-days (Tenable)
Attackers aimed at the release pipeline, not the source code
Three campaigns reported in the second half of September show the same pattern. The code in the repository was clean. The compromise happened in the build and publishing steps, which source scanning does not inspect.
| Campaign | Reported | How it worked |
|---|---|---|
| MemTensor packages | 23 Sep 2026 | Attackers hijacked GitHub Actions release pipelines to steal publishing tokens. They then pushed a self-spreading Go credential stealer ("sckit") to npm and PyPI. It targets AWS keys, GitHub and GitLab tokens, npm and PyPI tokens, and SSH keys. |
| Malicious Terraform providers | 23 Sep 2026 | The first use of the Terraform Registry to spread malware: two malicious providers (222 and 1,449 downloads) plus 11+ npm packages. The activity overlaps with a North Korean fake-job-interview campaign. |
| PhantomRaven | 18 Sep 2026 | 100+ malicious npm packages that steal CI/CD secrets. CrowdStrike assessed the code as "likely LLM-generated". |
These attacks match what our Shift-Left Gap Report found: the dependencies developers declared, the artifact that was built, and the software that runs in production can all differ. A source-only SBOM shows what developers intended to ship. It does not show what a compromised pipeline actually published. Under the CRA, that gap affects whether you can answer "are we affected?" within 24 hours.
CERT-In's BOM guidelines already describe the inventory the CRA requires
CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, v2.0 (9 July 2025) apply to government, the public sector, essential services and software exporters. Legal commentary describes them as guidance rather than law (AZB & Partners). Even so, the elements they specify are close to what CRA reporting depends on:
| Need under the CRA | Where CERT-In v2.0 helps | Where CISA 2026 helps |
|---|---|---|
| Know if an exploited component is in a shipped product | Minimum data fields (21 per AZB's summary), SPDX or CycloneDX formats, and lifecycle SBOM types including Analyzed and Runtime | Component hash algorithm field (2026 Minimum Elements) |
| Tell customers whether they are affected | VEX statements (not affected, affected, fixed, under investigation), followed by CSAF advisories | SBOM generation context field |
| Show your inventory is trustworthy | Supplier assurances on accuracy and completeness | SBOM tool name field; licence field |
| Plan for crypto and AI components | CBOM/QBOM for cryptography and post-quantum readiness; AIBOM for models | — |
If you sell into Indian capital markets, SEBI's CSCRF already requires SBOMs for critical systems, including COTS and SaaS (see our SEBI briefing). Your Indian financial-sector customers and your EU customers are now asking for similar inventories.
Getting to a 24-hour answer
- Week 1 · Decide scope List products placed on the EU market, including older versions still supported. Confirm with counsel whether you are the manufacturer. Register a reporting owner and a deputy.
- Weeks 2–4 · Inventory what ships Generate Build and Analyzed SBOMs from final artifacts (container images, installers, firmware), not only from manifests. Store them against each release version. Check pURL conformance, since SBOMs that do not follow it cause missed vulnerability matches between tools.
- Weeks 3–6 · Harden the pipeline Rotate and scope publishing tokens and move to trusted publishing (OIDC). Pin dependencies and actions by hash. Require signed provenance for releases. Alert on new maintainers and unusual publish events.
- Weeks 4–8 · Wire up the clock Connect KEV, CERT-In and vendor feeds to SBOM matching so exploited components are flagged automatically. Pre-draft ENISA early-warning and VEX templates. Rehearse the 24h, 72h and 14-day sequence.
Pipeline controls against September-style attacks
- No long-lived registry tokens in CI. Use OIDC-based trusted publishing
- Pin GitHub Actions and GitLab CI components to commit SHAs
- Isolate release jobs from pull-request workflows
- Allow-list Terraform providers and module sources
- Store secrets in a vault with short TTLs. Rotate everything after any compromise
- Scan images at build time and monitor runtime drift in production
Intellinative builds secure CI/CD on GitLab and AWS, with runtime protection from our Sysdig partnership, so the SBOM follows the artifact from build to production. Explore Kubernetes as a Service, the OTT multi-cloud modernisation case study, or book a CRA readiness session.
Frequently asked questions
Does the EU Cyber Resilience Act apply to Indian software companies?
It can. The CRA applies to manufacturers placing products with digital elements on the EU market, regardless of where the manufacturer is established. Indian ISVs, product companies and some SaaS or device vendors selling into the EU should confirm with counsel whether they are in scope.
What must be reported under the CRA, and when?
Actively exploited vulnerabilities and severe incidents that affect product security. An early warning is due within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix (for vulnerabilities) or one month after notification (for incidents). Reports go through ENISA's Single Reporting Platform.
Are products already on the market covered by CRA reporting?
Yes. The reporting obligations that started on 11 September 2026 also cover products placed on the EU market before the CRA's main requirements apply in December 2027.
Are CERT-In's SBOM guidelines mandatory?
They are guidance, and legal commentary describes them as not mandatory. They target government, the public sector, essential services and software exporters, and specify minimum data fields in SPDX or CycloneDX. Procurement clauses and SEBI's CSCRF can make SBOMs a requirement in practice.
What changed in CISA's 2026 SBOM Minimum Elements?
The July 2026 update replaces the 2021 NTIA list. It adds four fields (component hash algorithm, component licence, SBOM tool name and generation context) and renames several existing fields. It was co-signed by international partners.
How did the September 2026 supply chain attacks get in?
Mainly through stolen maintainer, publishing or CI/CD tokens and compromised release pipelines, as in the MemTensor, PhantomRaven and malicious Terraform provider cases. Useful defences are trusted publishing, pinned dependencies and actions, short-lived secrets, and SBOMs generated from the built artifact.
Sources
- The CRA Single Reporting Platform is launched · ENISA · 11 Sep 2026
- Cyber Resilience Act: reporting obligations · European Commission · Updated 11 Sep 2026
- CRA Article 64: Penalties · CRA text · —
- The EU Cyber Resilience Act · Kirkland & Ellis · 22 Sep 2026
- Cyber Resilience Act reporting obligations take effect on 11 September 2026 · Freshfields · 31 Aug 2026
- EU CRA vulnerability and incident reporting obligations now apply · HLC · 11 Sep 2026
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM v2.0 · CERT-In · 9 Jul 2025
- CERT-In's technical guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM · AZB & Partners · 2025
- 2026 Minimum Elements for a Software Bill of Materials · CISA · Jul 2026
- CISA SBOM guidance updated · Help Net Security · 30 Jul 2026
- Compromised MemTensor packages deliver credential stealer · The Hacker News · 23 Sep 2026
- Attackers use malicious Terraform providers · The Hacker News · 23 Sep 2026
- PhantomRaven npm campaign · The Hacker News · 18 Sep 2026
- Microsoft's September 2026 Patch Tuesday · Tenable · 8 Sep 2026