How the SecureMonk score works, penalty by penalty

A security score you cannot audit is marketing, not measurement. This page is the complete SecureMonk scoring methodology: every check, every penalty value, the conditions that cap a score, and exactly how the final 0-100 number is assembled. It matches the scoring code running in production. If the code changes, this page changes with it.

The shape of the score

A scan produces two independent sub-scores, each on an internal 0-100 scale:

• a TLS score, covering the certificate, protocol versions, and cipher configuration, and
• a header score, covering HTTP security response headers.

Each sub-score starts at 100 and loses points per finding. For display, each is halved to a value out of 50, and the overall score is simply their sum:

overall = round(tlsScore / 2) + round(headerScore / 2)   // 0-100
// then capped at 64 if any critical gap exists (see below)

The two halves are weighted equally on purpose. Transport security and application-layer headers defend against different attacks, and excellence in one does not compensate for absence of the other. If the header scan fails outright (some hosts block it), the overall score falls back to the TLS score alone rather than punishing the site for headers we could not observe.

TLS: instant fails

Three conditions zero out the TLS sub-score immediately, because each one means the encryption is not actually protecting visitors:

• Certificate is self-signed, expired, or does not match the hostname (critical certificate issue)
• Certificate has expired
• Server is vulnerable to Heartbleed (CVE-2014-0160)

TLS: penalty table

When no instant-fail applies, these deductions are taken from 100. The penalties shown in your scan report are these exact values, halved to match the displayed /50 scale.

Some TLS observations are reported as informational and never deduct points: server cipher-preference ordering, OCSP stapling, and the theoretical BEAST condition that every modern browser mitigates client-side. They appear in the report because they are worth knowing, not because they are defects.

Headers: penalty table

Each header is evaluated to a status: secure, partial (present but weakened, for example an HSTS max-age that is too short), invalid (present but wrong), or absent. Penalties by header and status:

The weighting states a clear opinion: HSTS and CSP are the two headers that matter most, at -25 each. They are the primary defenses against protocol downgrade and cross-site scripting respectively, which is why together they account for half of the header scale. The newer cross-origin isolation headers (COOP, COEP, CORP) are reported but not yet scored; they matter most for specific architectures, and penalizing every site for them would add noise, not signal.

The 64-point caps

A site can score well on many checks while missing something foundational. To prevent a misleadingly high grade, the overall score is capped at 64 when any of these is true:

• Certificate not trusted by public CAs
• No modern TLS at all (neither TLS 1.2 nor TLS 1.3)
• Content-Security-Policy header missing
• Strict-Transport-Security header missing

Why 64? Our badge tiers change at 70. The cap keeps any site missing a foundational control out of "Good" territory while still letting the rest of the score show how much else is right. Every cap that applied to your scan is listed in the report next to the score, so a capped 64 is never mysterious.

The caps have a visible effect at population scale: the median site in our scan corpus scores exactly 64, because missing CSP or HSTS is the single most common critical gap on the web.

Badges

• 90 to 100: Excellent
• 70 to 89: Good
• 50 to 69: Needs Improvement
• 0 to 49: Critical

What never affects the score

The vulnerability scan results (detected technologies, matched CVEs, exposure probes, and dependency findings) are informational only and never enter the score. This is a hard invariant in the scoring code, for two reasons. Version-based CVE matching has an irreducible false-positive rate, and a score should not swing on a maybe. And the vuln scan is optional per scan, so the score must mean the same thing whether or not it ran.

A worked example

A site has flawless TLS except that it does not offer TLS 1.3, and its headers are missing Content-Security-Policy and X-Content-Type-Options but everything else is right.

TLS:      100 - 5 (no TLS 1.3)                    = 95  → 48/50
Headers:  100 - 25 (no CSP) - 10 (no XCTO)        = 65  → 33/50
Raw overall: 48 + 33                              = 81
Cap: CSP missing                                  → capped at 64
Final score: 64 (Needs Improvement)

Adding a CSP fixes it twice over: the 25-point penalty goes away (headers become 90, or 45/50) and the cap lifts. The same site then scores 48 + 45 = 93, jumping from "Needs Improvement" straight to "Excellent". One header, 29 points. That is the cap doing its job: the grade moves when the foundational control appears, not gradually around it.

Small print

• Scan results are cached for about 10 minutes per hostname, so a config change may take a few minutes to show up in a re-scan.
• If the certificate could not be retrieved on a given run, the report says so explicitly instead of guessing. A transient retrieval failure is never scored as a defect.
• For what each individual check defends against, see every check mapped to the attack it stops. For the header on ramp, start with the four security headers worth fighting for.