The score compresses a lot of observations into one number between 0 and 100. It is built to help you triage, not to express a probability that you are secure. Treat a drop as a prompt to read the findings.
The seven categories
| Category | Weight | What moves it |
|---|---|---|
| Certificate Health | 30% | Expired, revoked, or near-expiry certificates being served; revoked OCSP responses |
| Confidentiality and Agility | 20% | Forward secrecy gaps, RSA-only hosts, DNSSEC zone enumeration |
| Protocols | 15% | SSLv3, TLS 1.0, TLS 1.1, certain OCSP stapling failures |
| Ciphers | 15% | Flagged cipher families on assessed hosts |
| Web Hardening | 10% | HTTP redirect gaps, missing HSTS, browser security headers |
| Reliability | 5% | Selected connection failures, missing or broken DNSSEC, signature expiry risk |
| Future Readiness | 5% | TLS 1.3, elliptic-curve certificate, and post-quantum coverage |
Bands: Good at 80 and up, Fair 60 to 79, Poor 40 to 59, Critical below 40. These are SSLBoard’s bands.
Certificate Health being nearly a third of the score is intentional. An expired certificate is the one finding that is already breaking things for real users.
Why the same finding costs different amounts
The score is not a count of findings, and this is the part worth understanding.
Each category starts at 100. Every applicable issue multiplies down the category’s remaining score, using a rule-specific multiplier raised to an exposure amount. For most rules:
exposure = log2(affected + 1) + 3 × affected / eligibleTwo things fall out of that shape:
- The first bad endpoint hurts most. The logarithmic term means going from 1 to 2 affected costs more than going from 50 to 51.
- Proportion matters as much as count. The
affected / eligibleterm means one bad host out of two is punished far harder than one bad host out of two hundred. A half-finished rollout looks worse than a single stray box, which is correct.
Reliability rules normalize the logarithmic part by log2(eligible + 1) where an eligible count exists. The overall score is the weighted sum of the category scores.
Future Readiness works differently: it combines coverage rather than penalties. TLS 1.3 is half the category, elliptic-curve certificates a quarter, post-quantum readiness a quarter. Components with no eligible observations drop out and the rest are renormalized.
What the number ignores
Plenty of the report does not touch the score at all:
- Email security results, in full. Transport and policies are reported separately.
- CAA policy rows.
- Adjacent domain relationships.
- Key-strength detail beyond the RSA-versus-ECC coverage used in scoring.
Missing observations are also not automatic failures. A category with no applicable penalties stays at 100, and Future Readiness defaults to 100 when it has no eligible components.
So a high score on a domain with heavy connection errors mostly measures how little was measured. Check coverage before you quote the number to anyone.
Comparing two reports
Compare findings and affected endpoints first, the number second. New discovery data, changed DNS answers, different eligible counts, and scoring changes can all move the score while your servers sit untouched.
The real proof a fix worked is the affected endpoint no longer showing the problem in a fresh report. See fixing and retesting.