BSI IT-Grundschutz and Microsoft 365 – Why the Combination Cannot Be Compliant
BSI IT-Grundschutz and Microsoft 365 – Why the Combination Cannot Be Compliant
Germany's Federal Office for Information Security (BSI) publishes the IT-Grundschutz Compendium, the binding information-security methodology for German federal authorities and a de-facto standard for SMEs. With C5 (Cloud Computing Compliance Criteria Catalogue), the BSI added a cloud-specific catalogue.
Anyone subject to NIS2, anyone contracting with the public sector, anyone seeking cyber insurance or sitting in a NIS2 supply chain cannot avoid IT-Grundschutz.
And here it gets uncomfortable: Microsoft 365 fully meets none of the security-critical Grundschutz modules. Below, module by module.
What IT-Grundschutz actually requires
IT-Grundschutz is not a marketing seal, it is a documentation-heavy process:
- Structural analysis of the information network
- Protection-needs assessment per component
- Modelling using the modules of the compendium
- IT-Grundschutz check – are the requirements implemented?
- Risk analysis per BSI Standard 200-3 for high protection needs
- Implementation and maintenance
Each module defines basic, standard and elevated requirements. Certification requires all basic and standard requirements to be implemented and proven.
The critical modules in the Microsoft 365 context
CON.3 – Data backup concept
CON.3.A4: Creation of a backup concept Requires documented, tested backups. Microsoft 365 does not back up data in the sense of the BSI. Microsoft's shared-responsibility model explicitly places this on the customer. Without third-party backup (e.g. to EU S3 storage), CON.3 in a pure Microsoft setup is not achievable.
OPS.2.2 – Cloud usage
The decisive module for any Microsoft 365 use.
OPS.2.2.A11: Contingency plan for a cloud service Must cover provider failure and data repatriation. With a vendor-lock-in architecture like Microsoft 365 (proprietary formats, proprietary APIs, proprietary identity), realistic emergency repatriation is to be measured in months, not hours. The BSI demands robust documentation for this – which in most cases simply does not exist.
OPS.2.2.A14: Secure migration to another cloud provider / reverse migration With Microsoft 365's proprietary data formats (Teams channels, OneNote notebooks, SharePoint sites, Power Platform flows) this is practically impossible without significant data loss.
APP.5.2 – Microsoft Exchange and Outlook (BSI explicitly publishes this module!)
The BSI-authored module addresses the on-premise variant. For Exchange Online (part of M365) there is no analogous cloud module addressing the specific risks. OPS.2.2 only partially fills the gap.
In particular APP.5.2.A10 (secure configuration) and A14 (mail encryption) are only partially achievable in Exchange Online, because Microsoft holds the keys.
CON.1 – Crypto concept
CON.1.A8: Secure storage of cryptographic keys In Microsoft 365, Microsoft holds the keys for indexing, search, anti-spam, Copilot and – in the worst case – CLOUD Act requests. BYOK changes nothing fundamental, since the key sits in Microsoft-administered HSMs. A BSI auditor will, in honest assessment, mark this as "not met".
ORP.5 – Compliance management
ORP.5.A2: Observance of legal frameworks Includes GDPR, German Trade Secrets Act (GeschGehG), TKDSG, BDSG, sector-specific laws. Microsoft 365 is subject to the US CLOUD Act, which structurally violates GeschGehG §4 and GDPR Art. 48 the moment a US authority issues a request. With the upcoming Schrems III ruling in sight, ORP.5.A2 is structurally not achievable with Microsoft 365.
NET.1.1 – Network architecture
NET.1.1.A14: Protection against unauthorised external access Microsoft operates a worldwide backbone (Microsoft Global Network) whose access paths are not inspectable under IT-Grundschutz. The Midnight Blizzard incident (2024, senior leadership mailboxes compromised) showed these paths are actually exploited.
Common questions about C5 attestation and BSI conformity of Microsoft 365
Is a C5 attestation sufficient proof of BSI-compliant cloud usage?
No. A C5 attestation is a self-assessment with auditor confirmation, not a legal opinion. Microsoft holds a C5 attestation (Type 2) – sounds good, but is misleading. It examines operational security measures, not the third-country access problem.
Which C5 criteria are critical for Microsoft 365?
In particular:
- BC-01 (data location)
- BC-02 (sub-processors)
- BC-03 (legal jurisdiction)
- BC-04 (disclosure to state authorities)
are declared met by Microsoft by reference to the "EU Data Boundary". This self-assessment does not hold under legal scrutiny once the CLOUD Act is considered. Microsoft France confirmed this publicly before the French Senate in 2025.
Does a C5 attestation automatically imply GDPR or NIS2 conformity?
No. C5 attestation ≠ GDPR conformity ≠ NIS2 conformity. The BSI itself explicitly notes this in the C5 documentation.
The honest balance
| BSI module / criterion | Achievable with Microsoft 365? |
|---|---|
| CON.1 crypto concept (key sovereignty) | ❌ No |
| CON.3 backup (without third-party backup) | ❌ No |
| OPS.2.2 cloud usage (exit strategy) | ⚠️ Only with massive effort |
| APP.5.2 Exchange (mail encryption) | ⚠️ Limited |
| ORP.5 compliance (CLOUD Act vs. GDPR Art. 48) | ❌ No |
| NET.1.1 network architecture (external access) | ❌ Not verifiable |
| C5 BC-01 through BC-04 (location & disclosure) | ❌ No |
This is not "Microsoft bashing". This is the module-by-module application of the BSI compendium. Any honest auditor reaches the same conclusion.
What IT-Grundschutz-compliant open-source infrastructure delivers
For each gap, a sovereign solution exists that we implement at europioneer:
Key sovereignty (CON.1)
- Own KMS: HashiCorp Vault / OpenBao on EU hardware
- HSM: nCipher, Utimaco, Securosys – BSI-certified HSMs available
- Mail encryption: S/MIME or OpenPGP, keys entirely with the customer
- Nextcloud E2EE: client-side encryption with customer-held keys
Backup (CON.3)
- Borgbackup / Restic to a second EU cloud (Hetzner Storage Box, OVHcloud Cold)
- Versioning & 3-2-1 rule as standard
- Weekly restore tests automated and documented
Cloud usage & exit (OPS.2.2)
- Open formats: ODF (instead of OOXML), Markdown, ICS, vCard, MBOX
- Standard APIs: CalDAV, CardDAV, IMAP, WebDAV, S3, OIDC
- No vendor lock-in – every component is replaceable in days, not months
Compliance & jurisdiction (ORP.5)
- Hosting exclusively in the EU (Hetzner DE/FI, OVHcloud FR, Scaleway FR, IONOS DE) or on-premise
- Contractual structure fully under German law
- CLOUD Act risk: structurally excluded, because no US provider is involved
- Source code fully inspectable and auditable (true open source, not "open inspection")
Network architecture (NET.1.1)
- Wazuh for SIEM, Suricata for IDS, CrowdSec for IPS
- Logs sit with you, not with a US corporation
- Zero-trust with Keycloak + OPA + Cilium
A realistic BSI-aligned migration path
We migrate in the order the BSI itself suggests:
Step 1: Structural analysis and protection-needs assessment (week 1–2) {#step-1}
Capture the information network in full, determine protection needs per component, identify critical modules.
Step 2: Identity & access (ORP) – Keycloak replaces Entra ID (week 3–4) {#step-2}
Keycloak as central identity platform, MFA and federated authentication, migrate user identities without password reset.
Step 3: Email (APP.5.2) – Mailcow / Stalwart replaces Exchange Online (week 5–7) {#step-3}
Mail server in EU data centre, S/MIME or OpenPGP for mail encryption, IMAP/JMAP migration of all mailboxes, MX cutover with zero downtime.
Step 4: File & collaboration (APP.4) – Nextcloud + ONLYOFFICE replaces OneDrive, SharePoint and Office (week 8–11) {#step-4}
Nextcloud Hub for SMEs with ONLYOFFICE or Collabora, migrate files from OneDrive/SharePoint including version history, E2EE for sensitive areas.
Step 5: Communication – Element / Matrix replaces Teams (week 12–13) {#step-5}
Following the example of the EU Commission's own migration: Matrix homeserver in EU, Element as client, Element Call for video conferencing.
Step 6: Endpoint hardening (SYS.2.x) (week 14–16) {#step-6}
Linux or hardened Windows client with Wazuh agent, disk encryption, MDM profiles, application whitelisting.
Step 7: Continuous audit documentation per IT-Grundschutz methodology {#step-7}
Structural analysis, protection-needs assessment, modelling, IT-Grundschutz check and risk analysis documented module by module — as audit evidence for GDPR, NIS2 and cyber insurance.
For an SME of 20–100 employees: 8–16 weeks, fixed price, Grundschutz documentation included for audit / NIS2 evidence / cyber insurance. The Microsoft 365 vs. open-source cost comparison also shows that the migration makes economic sense — typically paying back within 12 months.
Conclusion
There is no serious reading of the IT-Grundschutz Compendium in which Microsoft 365 fully meets the security-critical modules. Whoever sells a Microsoft 365 setup as "BSI-compliant" – internally or as a service provider – has either not read the modules, or is withholding the result.
EU open-source stack alternatives are today mature, interoperable, cheaper in total cost of ownership and – most importantly – structurally BSI-compliant.
We turn the compliance risk into a documented, auditable asset.
Book a BSI-Grundschutz workshop →
Related posts:
NIS2 and GDPR with Microsoft 365 – The Compliance Paradox of European Companies
NIS2, GDPR and BSI demand strict data control. At the same time 90% of companies run on US cloud, wide open through the CLOUD Act. Why the compliance illusion collapses in 2026 – and what to do now.
Microsoft 365 Copilot Flex Routing – How the EU Data Boundary is Quietly Being Eroded in 2026
Since April 2026, Copilot AI inference leaves the EU under peak load – by default. Plus Anthropic as a sub-processor outside the EU Data Boundary. What German SMEs must check and disable now.