Methodology

The census checks public web and email security settings for about 2,200 Swiss municipal, cantonal and federal bodies. It runs daily. The public website shows national figures, not named results.

Who and what

Municipalities come from the federal commune register; cantons and federal offices are also listed. Web domains come mainly from Wikidata and mail domains from public records and DNS. These mappings have not all been checked by hand. A wrong domain can make every result for that body wrong; please report corrections to the contact address in the scanner's User-Agent.

Web and mail domains are measured separately because they often differ. Schools, hospitals and utilities are outside this census.

The six key checks

Each check has one of four results: passed, partly, failed or not measured. A measurement error is never treated as a confirmed failure; errors are retried once. On the website every share is out of all listed bodies, and the bodies not measured are shown as their own part.

The score

Each body gets a score from 0 to 100. It weighs what each setting protects: the six key checks give 64 of the 100 points, and eleven further measurements give the rest. Each component earns a share of its points: passed 1, partly 0.5, failed 0. A body's score is the points it earned out of the points it could be measured on, times 100.

Two kinds of gap are left out instead of counting as zero:

• Not applicable: cookie attributes on a homepage that sets no cookies, and web-domain spoofing protection when mail and website use the same domain.
• Not measured: a check error, a timeout, a homepage that did not answer.

A body has a score only when at least 80% of its applicable points were measured. A hosting outage therefore removes bodies from the score figures instead of lowering them; the number left out is shown next to the median. The score is a measure of these settings, not an overall security rating. It starts on 2026-10-21, the first run that recorded every component.

By canton, the map and table show the median score and the share of each key check for the cantonal administration and its municipalities together. Cantons with fewer than 20 bodies are combined into one group, as in the statistics.

Each run also records an older summary for comparison: a 12-point score (2 points per key check passed, 1 per check partly passed) and the share of bodies passing TLS, HSTS, SPF and DMARC. Both are in national.json but are no longer shown on the website.

Other signals

These observations are recorded but do not change the score:

• Mail: authenticated MX DANE/TLSA record presence and a Microsoft 365 DKIM selector where applicable. Selector or TLSA presence does not prove that messages are signed or that a certificate matches. (DANE or MTA-STS as a whole is scored.)
• IPv6: whether the website or at least one mail server publishes an IPv6 address. This is a DNS adoption signal, not a test of IPv6 reachability.
• Homepage: known third-party resource categories visible in static HTML, and a complete PHP version disclosed in X-Powered-By or Server, compared with the upstream fixed releases for CVE-2026-109618 and CVE-2026-109619. Scripts are not executed, so JavaScript-added resources are missed.
• Infrastructure: open TCP ports, valid SMTP STARTTLS, estimated Swiss IP allocation, large hosting networks and whether a web domain's nameservers all map to one network. These figures count distinct public IPs, not bodies. One IP can serve many bodies and unrelated customers. An open port is not proof of a vulnerability; an IP's allocation country is not its physical location.

Trackers, IPv6, the PHP version banner and the infrastructure survey stay out of the score: they are not a body's own security setting, or the evidence is too weak.

How collection works

DNS is queried through a validating resolver. For each web domain the collector requests security.txt and the HTTP and HTTPS homepages, follows up to five redirects, and tries one TLS handshake per protocol version. It inspects up to 64 KiB of the final HTTPS homepage in memory and discards it. Cookie names and values, homepage bodies and complete service banners are not stored. A precise PHP version found in a banner is retained with its derived patched, affected or unknown classification. This is low-confidence evidence: headers can be hidden, forged, cached or added by a proxy, and vendors can backport fixes without changing the upstream-looking version. When no version is disclosed, the result is unknown, never safe. This passive comparison is based on php2shell-audit and does not test exploitability.

A separate survey resolves the listed website and mail-server names, excludes non-public and opted-out addresses, and checks each distinct public IP once per run. It checks TCP ports 21, 22, 23, 25, 80, 443, 445, 1433, 3306, 3389, 5432, 5900, 6379, 8080, 8443, 9200 and 27017. Connections to one IP are at least one second apart. On open web ports it sends one HTTP HEAD request; on port 25 it may send EHLO and STARTTLS to check the mail certificate. No mail, login or form is sent. Requests identify the project and its contact address.

A refusal means closed. A timeout or network error means unknown, not closed. A shared IP's port or STARTTLS result is never attributed to an individual body.

Port counts are not shown on the site: firewalls that accept every connection make an accepted connection a poor sign of a real service, so these shares overstate exposure.

Publication and change

Only national aggregates are published. Small cells are withheld; a small unknown count does not hide an otherwise well-measured yes/no share. IP addresses, banners and entity-to-IP mappings never enter the public dataset. Named results stay off. Trends compare runs, and a change is more persuasive when it persists across several runs. Each run records the methodology date and code commit.

To correct a domain or opt out, contact the address in the User-Agent. The next run uses the corrected list.

Measurement incidents

• 2026-10-21: about 190 websites did not answer during the run, most of them on two hosting networks; 82 bodies hosted by one provider were unreachable for every visitor that evening. Their web checks count as not measured: the published TLS, HSTS and security.txt shares are lower for this run, and those bodies have no score.

Changes

• 2026-10-22: The website shows one score, the 0-100 score added the same day (first called the Census Index). The 12-point score and the baseline are still recorded but no longer shown. Every share on the website is out of all listed bodies, with not measured shown as its own part. The national figures are published as open data under CC BY 4.0.
• 2026-10-22: Added the Census Index, a weighted 0-100 score from the six checks and eleven recorded observations, with gaps left out instead of scored as zero. Added the canton map, like-for-like changes for the baseline and the index, and the about page with the correction policy. The six checks, the 12-point score and the baseline are unchanged.
• 2026-10-21: Added an unscored, passive PHP2Shell version comparison using headers from the existing HTTPS homepage request. It adds no network request and does not attempt exploitation.
• 2026-10-20: Stopped showing open-port shares; firewalls that accept every connection made them overstate exposure.
• 2026-10-19: Added unscored homepage, mail and infrastructure observations, including the deduplicated public-IP survey. Corrected DNSSEC handling of web domains that alias into a provider's zone and DMARC inheritance for subdomains. The six scored checks, their weights and the baseline are unchanged.