Default deny / secure by default
Why important?
Secure defaults reduce risk and audit effort (less configuration debt).
How measured?
Scale 0–5 + N/A:
- 0 = Insecure defaults / default allow (high exposure)
- 1 = Some secure defaults, but inconsistent
- 2 = Secure defaults only in parts/optional, no end-to-end standard
- 3 = Secure-by-default for core scope, clear baselines
- 4 = Secure-by-default broad + standard blueprints/landing zones
- 5 = Secure-by-default + demonstrable baselines (audit/controls) + continuous hardening
- N/A = no reliable evidence
Validation questions (RFP)
- Are new workloads deployed in a hardened/restricted state? Which defaults are documented?
Scores comparison
| Providers | Score | |
|---|---|---|
| STACKIT | 5.0 | |
| Exoscale | 4.0 | |
| Hetzner Cloud | 4.0 | |
| IONOS Cloud | 4.0 | |
| Microsoft Sovereign Cloud | 3.0 | |
| SysEleven OpenStack Cloud | 3.0 | |
| Cloud Temple Trusted Cloud | 3.0 | SecNumCloud qualification requires high security baseline. Secure-by-default implied by ANSSI requirements. Network Firewall (Stormshield) available. |
| Infomaniak Public Cloud | 2.0 | OpenStack Security Groups configurable. Default behavior not documented as 'deny'. ISO 27001 security baseline. |
| UpCloud | 3.0 | |
| noris Sovereign Cloud | 2.0 | |
| pluscloud open | 2.0 | |
| OVHcloud Public Cloud (inkl. SecNumCloud) | 1.0 | |
| Oracle EU Sovereign Cloud | 1.0 | |
| Scaleway | 1.0 | |
| AWS European Sovereign Cloud | N/A | |
| Delos Cloud | N/A | |
| T Cloud Public | N/A |