Kritische Infrastrukturen in der Schweiz: Kennzahlen zur Cybersicherheit, Vergleiche und Prioritäten für Abhilfemassnahmen für Kantone, Gemeinden, den Finanzsektor und Krankenhäuser.
Diese Analyse fasst die Ergebnisse der Cybersicherheits-Scans zusammen, die an kritischen Infrastrukturen in der Schweiz durchgeführt wurden. Dabei wurden drei Bereiche untersucht: security.txt (Kontaktstelle zur Meldung von Sicherheitslücken), Sicherheits-Header und E-Mail-Sicherheit (SPF, DMARC, DNSSEC).
dcod.ch
Cybersicherheit • KI • Tech
Observatorium für die Cybersicherheit der kritischen Infrastrukturen der Schweiz
Kontrolle
Stand 9 Oktober 2026 Quelle : Banques, maisons de titres, assurances, gestionnaires de fonds, gestionnaires de fortune, infrastructures des marchés financiers et organismes de surveillance autorisés par la FINMA.
Erfasste Einheiten
173
173 gemessen · 0 nicht erreichbar
Art kritischer Infrastruktur
Finanzen
Aufsichtsorganisation, Bank, DLT-Handelssystem, Finanzmarktinfrastruktur, Vermögensverwalter, Versicherungsunternehmen, Verwalter von Kollektivvermögen, Wertpapierhaus
Zusammensetzung des Bereichs
Art der erfassten Einrichtungen, unabhängig von ihrem Ergebnis.
- Vermögensverwalter 77
- Bank 58
- Versicherungsunternehmen 15
- Verwalter von Kollektivvermögen 8
- Aufsichtsorganisation 6
- Wertpapierhaus 4
- Übrige 5
Ergebnisse
Konformitätsgrad
Über alle gemessenen Einheiten, einschliesslich jener, die nichts veröffentlichen.
- Stark 22
- Teilweise 32
- Zu verstärken 119
| Ergebnis | Einheiten | % |
|---|---|---|
| Stark | 22 | 13 % |
| Teilweise | 32 | 18 % |
| Zu verstärken | 119 | 69 % |
Vergleich der Bereiche
Alle kritischen Infrastrukturen im Vergleich, gesamtschweizerisch.
Kantone
Gemeinden
Finanzen
Spitäler
Energie
Verkehr
- Stark
- Teilweise
- Zu verstärken
Vergleich der Institutstypen
Anteil konformer Einrichtungen, pro Institutstyp – vom besten zum schwächsten.
Versicherungsunternehmen
Bank
Verwalter von Kollektivvermögen
Aufsichtsorganisation
Vermögensverwalter
Wertpapierhaus
Übrige
- Stark
- Teilweise
- Zu verstärken
Zu behebende Probleme
Aufgetretene Fehlertypen, nach Schweregrad geordnet und nicht nach Häufigkeit. Der Anteil nennt die betroffenen gemessenen Einheiten.
| Schweregrad | Kontrolle | Betroffen | Empfohlene Korrektur |
|---|---|---|---|
| Kritisch | security.txt-Datei veröffentlicht STXT-PRESENT | Unter /.well-known/security.txt der Website eine Textdatei mit mindestens einer Zeile « Contact: » und einer Zeile « Expires: » veröffentlichen. Eine allgemeine Adresse wählen, die von mehreren Personen gelesen wird (zum Beispiel sicherheit@…), nie das Postfach einer einzelnen Person. | |
| Kritisch | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC | Einen TXT-Eintrag unter _dmarc.<Domain> veröffentlichen : mit « v=DMARC1; p=none; rua=mailto:dmarc@beispiel.ch » beginnen, die Berichte einige Wochen auswerten, dann auf « p=quarantine » und schliesslich auf « p=reject » verschärfen. | |
| Kritisch | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF | In der DNS-Zone der Domain (beim Hoster oder Registrar, der sie verwaltet) einen einzigen TXT-Eintrag veröffentlichen, der mit « v=spf1 » beginnt, alle legitimen Versanddienste auflistet und mit « -all » endet. Bis geprüft ist, dass alle legitimen Versender aufgeführt sind, kann « ~all » als Zwischenschritt dienen. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS | Ein gültiges Zertifikat für den Namen der Website installieren (Let's Encrypt ist kostenlos und erneuert sich automatisch), es mit seinen Zwischenzertifikaten ausliefern und prüfen, dass die automatische Erneuerung funktioniert. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS Zertifikat für anderen Namen | Ein Zertifikat ausstellen, das die Domain und ihre www-Variante abdeckt (Feld « Subject Alternative Name »), oder den Hoster bitten, es für diese Domain zu aktivieren. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS TLS-Aushandlung unmöglich | TLS 1.2 und TLS 1.3 mit aktuellen Verschlüsselungen aktivieren (SSLv3, TLS 1.0 und 1.1 deaktivieren) ; der Konfigurationsgenerator von Mozilla (ssl-config.mozilla.org) liefert eine fertige Konfiguration. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS Zertifikat abgelaufen | Das Zertifikat erneuern und die Erneuerung automatisieren (Let's Encrypt/ACME), mit einer Warnung vor Ablauf. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS HTTPS-Port geschlossen | HTTPS auf dem Server oder beim Hoster aktivieren (kostenloses Let's-Encrypt-Zertifikat) und anschliessend http:// auf https:// weiterleiten. | |
| Erheblich | Erzwungene SMTP-Verschlüsselung im Transit (MTA-STS) EMAIL-MTA-STS | Einen TXT-Eintrag unter _mta-sts.<Domain> veröffentlichen (« v=STSv1; id=… »), dann die Richtliniendatei unter https://mta-sts.<Domain>/.well-known/mta-sts.txt, zuerst mit « mode: testing », nach der Prüfung mit « mode: enforce ». | |
| Erheblich | Signierte und überprüfbare DNS-Antworten (DNSSEC) EMAIL-DNSSEC | DNSSEC beim Anbieter der DNS-Zone aktivieren (oft eine einfache Option) und den DS-Eintrag beim Registrar der Domain veröffentlichen lassen – viele erledigen das automatisch. | |
| Erheblich | Browser zu dauerhaftem HTTPS gezwungen (HSTS) HEAD-HSTS | Sobald die Website vollständig per HTTPS ausgeliefert wird, den Header « Strict-Transport-Security: max-age=31536000 » (ein Jahr) hinzufügen ; « includeSubDomains » ergänzen, wenn auch alle Subdomains per HTTPS erreichbar sind. | |
| Erheblich | Gültigkeitsdatum angegeben (Feld Expires) STXT-EXPIRES Gültigkeitsdatum überschritten | Das Datum im Feld «Expires:» erneuern (ISO 8601, zum Beispiel in einem Jahr) und eine Erinnerung vor dem nächsten Ablauf einplanen. | |
| Erheblich | Automatische Weiterleitung auf HTTPS HEAD-REDIRECT | Den Server oder das Hosting so einrichten, dass jede http://-Adresse auf ihre https://-Entsprechung weiterleitet, vorzugsweise dauerhaft (301 oder 308). | |
| Erheblich | Gültigkeitsdatum angegeben (Feld Expires) STXT-EXPIRES | Die Zeile « Expires: » mit einem Datum in höchstens einem Jahr hinzufügen oder aktualisieren und eine Erinnerung einrichten, um sie vor Ablauf zu verlängern. | |
| Erheblich | Automatische Weiterleitung auf HTTPS HEAD-REDIRECT Weiterleitung auf eine Nicht-HTTPS-Adresse | Bereits beim ersten Schritt direkt auf https://<gleiche Domain>/ weiterleiten, ohne HTTP-Zwischenschritt. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise endet mit «~all» | «~all» am Ende des Eintrags durch «-all» ersetzen, sobald die berechtigten Absender vollständig erfasst sind («~all» ist nur als Testphase gedacht). | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=quarantine» | Von «p=quarantine» zu «p=reject» (Ablehnung) wechseln, sobald die rua=-Berichte geprüft und Fehlalarme ausgeschlossen wurden. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=none» (nur Beobachtung) | Von «p=none» zu «p=quarantine» (Quarantäne) wechseln, später zu «p=reject» (Ablehnung), sobald die rua=-Berichte geprüft wurden. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=none» ohne «rua=» | «rua=mailto:…» zum Eintrag hinzufügen, um Aggregatberichte zu erhalten: ohne sie ist nicht feststellbar, wann auf «p=quarantine» oder «p=reject» verschärft werden kann, ohne legitime E-Mails zu blockieren. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=reject» ohne «rua=» | «rua=mailto:…» zum Eintrag hinzufügen: die Ablehnungsrichtlinie bleibt unverändert, aber die Domain erhält endlich Berichte über Missbrauchsversuche und kann prüfen, ob ihre Konfiguration weiterhin wie erwartet funktioniert. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=quarantine» ohne «rua=» | «rua=mailto:…» hinzufügen, um Berichte zu erhalten, dann von «p=quarantine» zu «p=reject» (Ablehnung) wechseln, sobald diese Berichte geprüft und Fehlalarme ausgeschlossen wurden. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise endet mit «?all» | «?all» durch «-all» (Ablehnung) am Ende des Eintrags ersetzen, oder mindestens «~all» (Markierung) während einer Testphase: «?all» war nie mehr als ein Übergangszustand, keine beizubehaltende Richtlinie. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise Subdomains schwächer geschützt | «sp=reject» hinzufügen oder verschärfen, um die Subdomain-Richtlinie an die Hauptdomain anzugleichen – mindestens «sp=quarantine». | |
| Erheblich | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS teilweise unvollständige Zertifikatskette | Auf dem Server die vollständige Kette installieren (Zertifikat + Zwischenzertifikate : Datei « fullchain.pem » bei Let's Encrypt, « Bundle » bei anderen Stellen) und danach mit SSL Labs (ssllabs.com/ssltest) prüfen : der Hinweis « Chain issues: Incomplete » muss verschwinden. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise ohne «all»-Abschluss | «-all» (oder «~all» während einer Testphase) am Ende des Eintrags hinzufügen. | |
| Gering | Berichte über SMTP-Verschlüsselungsfehler (TLS-RPT) EMAIL-TLSRPT | Einen TXT-Eintrag unter _smtp._tls.<Domain> veröffentlichen (« v=TLSRPTv1; rua=mailto:tls-berichte@beispiel.ch »). | |
| Gering | Eingeschränkte Zertifizierungsstellen (CAA) EMAIL-CAA | In der DNS-Zone der Domain einen CAA-Eintrag veröffentlichen, der die genutzte(n) Stelle(n) nennt, zum Beispiel « 0 issue "letsencrypt.org" ». | |
| Gering | Zugriff auf Browserfunktionen eingeschränkt (Permissions-Policy) HEAD-PERMISSIONS | Eine Richtlinie hinzufügen, die Ungenutztes schliesst, zum Beispiel « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Gering | Eingeschränkte Informationen an externe Links (Referrer-Policy) HEAD-REFERRER | Den Header « Referrer-Policy: strict-origin-when-cross-origin » hinzufügen. | |
| Gering | Liste erlaubter Skripte und Ressourcen (CSP) HEAD-CSP | Eine auf die Website zugeschnittene Richtlinie festlegen, sie zuerst im Modus « Content-Security-Policy-Report-Only » testen, das Gemeldete korrigieren und sie dann anwenden. | |
| Gering | Dateityp nicht vom Browser neu interpretiert (nosniff) HEAD-NOSNIFF | Den Header « X-Content-Type-Options: nosniff » in der Serverkonfiguration hinzufügen. | |
| Gering | Schutz vor Einbettung in unsichtbare Rahmen (Anti-Clickjacking) HEAD-FRAME | « X-Frame-Options: SAMEORIGIN » oder die Direktive « frame-ancestors 'self' » in der CSP-Richtlinie hinzufügen. | |
| Gering | Verschlüsselungsschlüssel veröffentlicht (Feld Encryption) STXT-ENCRYPTION | Eine Zeile « Encryption: https://beispiel.ch/pgp-schluessel.asc » hinzufügen, die auf den öffentlichen Schlüssel des Sicherheitsteams verweist. | |
| Gering | Geschützte Cookies (Secure, HttpOnly, SameSite) HEAD-COOKIES | Jedem von der Website gesetzten Cookie die Attribute Secure, HttpOnly und SameSite (mindestens Lax) hinzufügen. | |
| Gering | Kontaktsprachen angegeben (Feld Preferred-Languages) STXT-LANGUAGES | Eine Zeile « Preferred-Languages: de, fr, it, en » mit den für Meldungen akzeptierten Sprachen hinzufügen. | |
| Gering | Softwareversion nicht offengelegt HEAD-VERSION | Den Server so konfigurieren, dass die Versionsnummer in den Headern Server und X-Powered-By verborgen bleibt (zum Beispiel ServerTokens Prod und ServerSignature Off bei Apache, expose_php = Off bei PHP). | |
| Gering | Datei mit und ohne www erreichbar STXT-BOTH-VARIANTS | Dieselbe Datei unter beiden Varianten ausliefern oder die eine auf die andere weiterleiten. | |
| Gering | Geschützte Cookies (Secure, HttpOnly, SameSite) HEAD-COOKIES teilweise | Jedem von der Website gesetzten Cookie die Attribute Secure, HttpOnly und SameSite (mindestens Lax) hinzufügen. | |
| Gering | Liste erlaubter Skripte und Ressourcen (CSP) HEAD-CSP teilweise nur Report-Modus | Sobald die Reports ohne Fehlalarme geprüft sind, dieselbe Richtlinie unter dem Header «Content-Security-Policy» (ohne «-Report-Only») veröffentlichen, damit sie tatsächlich angewendet wird. | |
| Gering | Browser zu dauerhaftem HTTPS gezwungen (HSTS) HEAD-HSTS teilweise Dauer (max-age) zu kurz | max-age auf mindestens 15552000 (6 Monate) erhöhen – idealerweise 31536000 (1 Jahr) mit includeSubDomains. |
Ausführliche Leitfäden (auf Französisch): security.txt : le guide complet du signalement des vulnérabilités · SPF, DKIM, DMARC : le guide complet de la sécurité des emails · En-têtes de sécurité HTTP : le guide complet (HSTS, CSP, cookies)
Entwicklung
Monatliche Entwicklung des gesamten Registers, alle Einheiten zusammen.
| Monat | Stark | Teilweise | Zu verstärken | Bewertete Einheiten |
|---|---|---|---|---|
| 2026-08 | 30 % | 53 % | 17 % | 96 |
| 2026-09 | 23 % | 31 % | 46 % | 97 |
| 2026-10 | 23 % | 30 % | 47 % | 97 |
Methodik und Grenzen
Die Bewertungen beruhen auf dem Stand des Beobachtungsdatums und ausschliesslich auf öffentlich zugänglichen Informationen, die passiv und ohne Authentifizierung erhoben wurden. Sie stellen weder ein Sicherheitsaudit noch einen Penetrationstest noch eine Zertifizierung dar. Ein «solides» Ergebnis garantiert nicht die Abwesenheit von Schwachstellen; ein «zu verstärkender» Punkt bedeutet weder eine Kompromittierung noch die Verletzung einer gesetzlichen oder vertraglichen Pflicht.