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. A host hidden behind a firewall does not drag the score down just because it could not be tested.
So a high score on a domain with some connection errors mostly measures the hosts that answered. Check coverage before you quote the number to anyone.
When no host answers over TLS
There is one exception to the rule above. If not a single host completes a TLS handshake, every category drops to 0 and so does the score. That covers broken handshakes, timeouts and DNS failures alike: with nothing measured, there is nothing to vouch for. The report flags it as a critical finding and lists the errors each host returned.
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.