Cyber Resilience Act – What German SMEs and public bodies must demand from Microsoft and their software suppliers from 11 September 2026

In ten weeks – on 11 September 2026 – the Cyber Resilience Act (CRA) reporting obligations under Article 14 enter into force. From that date onwards, every manufacturer of products with digital elements must report actively exploited vulnerabilities and severe security incidents within 24 hours through the ENISA Single Reporting Platform (SRP). The CRA is not fully applicable until 11 December 2027, but the reporting duty is the operational anchor that must reshape procurement practice in German SMEs, schools, and public bodies right now.

We take the situation at the start of July 2026 apart without drama: what Article 14 actually requires, why Microsoft falls into scope, which four contract clauses must be on every software purchase from now on, where the interlock with NIS2 is untidy, and which sovereign fallback building blocks should be prepared before September.

What Article 14 CRA requires from 11 September 2026

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. It obliges manufacturers of products with digital elements (PDE) – practically anything using a network connection directly or indirectly – to a defined level of security across the entire product lifecycle. On 11 June 2026, Chapter IV on the notification of conformity assessment bodies already applied. On 11 September 2026, the Article 14 reporting duties follow. All other duties – CE marking, secure-by-design, technical documentation – take effect on 11 December 2027.

Specifically, Article 14 requires four notifications for an actively exploited vulnerability:

1. Early warning within 24 hours to the competent national CSIRT and ENISA via the SRP.
2. Full notification within 72 hours with details on the attack pattern, affected products, and initial countermeasures.
3. Final report within 14 days of a corrective measure becoming available.
4. For severe incidents without active exploitation: final report within one month.

Fines for breaches of the reporting duty go up to EUR 15 million or 2.5 percent of worldwide group turnover, whichever is higher.

Why Microsoft is in scope

The CRA applies to every manufacturer making PDEs available on the EU market, regardless of the manufacturer's location. Windows 11, Microsoft 365, Azure, Exchange Online, SharePoint, Teams, Copilot – all fall into scope. From 11 September 2026, Microsoft must report actively exploited vulnerabilities in these products to the competent CSIRT via the ENISA SRP within 24 hours. In Germany, that is the CERT-Bund at the BSI.

The operational consequence for customer companies is double-edged. On the upside: the BSI and ENISA learn about new attack campaigns earlier, and the national threat-intelligence picture improves. On the downside: the notification to ENISA does not mean customers receive a patch – or even an official customer communication – within 24 hours. The interval between report and patch availability is structurally not regulated by the CRA; it is defined only by the contractual relationship between manufacturer and customer. This is exactly where the procurement work begins.

If you combine the CRA reporting logic with the Flex Routing outside the EU Data Boundary documented in April 2026 and the existing CLOUD Act access situation, you see the structural problem: a US parent decides reporting timing, patch prioritisation, and customer communication. A European customer relies on communication chains it neither controls nor negotiates.

Four contract clauses that must now enter every software purchase

German procurement practice must adopt four new standard clauses from July 2026. They do not replace existing IT-security clauses, they supplement them.

• Pass-through obligation. The manufacturer informs the customer of CRA reports affecting its products within a contractually defined deadline – 48 hours after its own ENISA report is customary. Without this clause, the customer company first learns from general media that a product in use is affected.
• Patch SLA for actively exploited vulnerabilities. Maximum interval between ENISA notification and availability of a corrective measure. Realistic values are 14 days for critical vulnerabilities and 30 days for high. Shorter periods are negotiable with hyperscalers, often not with on-premises software.
• Secure-by-design warranty. The manufacturer contractually warrants that its product will meet Annex I CRA requirements by 11 December 2027 and that CE marking with conformity assessment is documented. Without this warranty, the customer takes on product-liability risk if the manufacturer misses the deadline.
• End-of-life support rule. The CRA requires security updates over the expected lifetime, at least five years. The contract must fix the exact support duration, extension options, and communication channels at EoL.

These clauses are not an academic exercise. BSI IT-Grundschutz already requires structured supplier governance today, and the DORA framework for the financial sector demands exit strategies for critical ICT third parties. The CRA now gives the same practice a third legal frame, aimed at the same core.

Special case: schools and public bodies

For school authorities, municipalities, and Land-level agencies the CRA situation is doubly tight. First, procurement rules under GWB, VgV, and UVgO increasingly demand contractual coverage of IT-security requirements. A tender without CRA-compliant clauses is challengeable from September 2026. Second, the Cloud and AI Development Act (CADA) has required sovereignty tiers since 3 June 2026. For CADA tier 3 – European ownership, no US sub-processors – Microsoft is structurally unqualified. For tiers 1 and 2, the CRA clauses are mandatory but negotiable.

For schools, the data-protection layer is added. The German Data Protection Conference continues to classify Microsoft 365 in schools as not legally compliant. Whoever additionally fails to lock the CRA clauses into the contract now amplifies the exposure of their procurement decision. A school authority signing a new Microsoft framework agreement in 2026 without CRA clauses will have to defend that choice in a 2028 audit.

Interlock with NIS2 and GDPR

The new CRA reporting logic layers on top of existing duties from NIS2 and GDPR – it replaces none. When Microsoft reports a Windows vulnerability through the SRP and an essential or important NIS2 entity sees that vulnerability actively exploited in its network, three parallel notifications become due:

1. CRA notification by Microsoft to ENISA (not by the user).
2. NIS2 notification by the deploying company to the BSI – 24-hour first, 72-hour full, 30-day final notification.
3. GDPR notification if personal data is affected, to the Land data-protection authority – 72 hours.

This is the practical shape of the Microsoft paradox in NIS2 and GDPR: the reporting burden sits with the deploying company, the information sits with the manufacturer. Whoever does not lock the pass-through duty contractually has a 24-hour reporting deadline based on publicly available attack signals – a systemic problem.

From zero to a CRA-ready supplier register in ten days

The HowTo section in the frontmatter of this post lays out a concrete ten-day path. Starting on 15 July 2026 gets the register with the ten most critical suppliers in place by the end of July and leaves buffer for renegotiation and internal runbooks until 11 September. Starting only in late August lands you in the deadline without documented clauses.

Sovereign building blocks as a fallback

The CRA does not exclude US software. It only requires that such software be CRA-compliant. For critical core functions, building sovereign fallback blocks is still recommended. Four realistic replacements:

• Nextcloud for SharePoint and OneDrive – German provider, on-premises or with a European managed hoster, CRA compliance through the European manufacturer chain easier to evidence.
• Element and Matrix for Teams – federation protocol, open standard, European providers with a direct CRA contact.
• openDesk for Microsoft 365 – bundle by ZenDiS based on open source, designed for public administration but usable for SMEs.
• Aleph Alpha or Mistral for Azure OpenAI – sovereign LLM endpoints, see also the AI Act consequences from 2 August 2026.

We help SMEs, school authorities, and public bodies combine CRA contract review, supplier renegotiation, and fallback setup. Get in touch if the supplier register should be in place by the end of July, see the European alternatives we run, and compare managed hosting prices with your current framework agreement.

Bottom line

11 September 2026 does not change software procurement law but the operational practice behind it. A framework agreement without pass-through obligation, patch SLA, secure-by-design warranty, and end-of-life support rule is a documented compliance risk from that date. Whoever confronts the ten most critical suppliers once in a structured way by the end of July uses the summer for negotiation and September for live operation. For the three to five positions where Microsoft cannot or will not deliver the clauses, the sovereign fallback should sit in the drawer as a prepared option.