What Perimeter checks — and how the ruleset stays current

Current ruleset: 2026.08.25

Perimeter grades the security and compliance posture that anyone on the internet can already observe about your site: your TLS certificate and protocol, your HTTP security headers, your public DNS and email-authentication records, and the accessibility of your rendered HTML. Everything below is what sits behind a grade — no black box. It's read-only and external; we never touch the inside of your systems.

The one distinction that matters

Perimeter checks configuration posture against current best practice — not CVE-style exploit signatures. That's a deliberate choice. A vulnerability scanner chases a firehose of new exploit signatures every day and needs a constantly-refreshed threat feed. The things Perimeter watches — is your certificate valid, are the right headers present, is your DMARC policy actually enforcing — change slowly and are governed by stable, published standards. So our "signatures" are rules grounded in those standards, and keeping them current means tracking standards, not racing a feed. If you also need deep application-layer vulnerability scanning, Perimeter sits alongside that; it doesn't replace it.

The four families of checks

Transport security (TLS / SSL)

• Certificate validity, trust chain and hostname match.
• Time to expiry — warned well ahead (30 / 14 / 7 days), critical once expired.
• Protocol version — anything below TLS 1.2 is flagged; 1.3 is preferred.

HTTP security headers

• HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, clickjacking protection (X-Frame-Options / frame-ancestors), and Permissions-Policy.
• Each contributes to a 0–100 header score, so you can see what's present and what's missing at a glance. The headers guide explains what each one defends against.

DNS & email authentication

• SPF presence and syntax, DMARC presence and policy strength (none < quarantine < reject), and CAA.
• DNS answers are queried over DoH and filtered by record type, which avoids the classic false "MX but no SPF" flag on CNAME-flattened domains.

Accessibility (WCAG)

• Static analysis of the served HTML for the failure classes that dominate real-world audits: images without alt text (WCAG 1.1.1), form fields without labels or accessible names (3.3.2), empty links and buttons (2.4.4 / 4.1.2), missing document language (3.1.1), missing page title (2.4.2), pinch-zoom disabled (1.4.4), heading structure and untitled iframes.
• Scope, honestly: automated checks catch roughly a third of WCAG issues — the most common third. They can't judge color contrast in full CSS context or screen-reader flow; full conformance also needs manual testing, and our reports say so. Try it on the accessibility checker.

How the grade is built

The grade comes from the worst issue present, moderated by how many there are: a clean site is A+, a single minor note is A-, warnings pull you to B/C, and anything critical (an expired certificate, say) caps you at D or below. The same inputs always produce the same grade — it's deterministic, so your evidence is reproducible.

How the ruleset is updated

The ruleset is versioned with a date (2026.08.24 today) and that version is stamped onto every result and every dated compliance report — so an auditor can see exactly which ruleset produced a given piece of evidence. Because Perimeter is a hosted service, there is nothing to update on your side: when we tighten a threshold or add a check, we bump the version, note what changed, and deploy once — and the very next check for every customer uses the new ruleset. No agents, no plugins, no version drift between customers. When a standard moves — a protocol is deprecated, a header becomes expected, an email-auth spec is revised — the rule moves with it and the version records when.