The score is useful context and completely useless as a work instruction. Nobody can act on “Web Hardening dropped four points.” A ticket that gets fixed names what was observed, where, and what success looks like.
Write the ticket
- Note the report date and what the affected service is for.
- Record the finding, the hostname, the IP and port where available, and the supporting evidence.
- Identify who controls that setting: CDN, load balancer, origin server, DNS provider, registrar, or mail provider. Getting this wrong costs a week.
- State the expected result concretely. “Endpoint 203.0.113.10:443 serves the wildcard certificate valid to 2027-03” beats “fix the certificate.”
- Schedule it with the real compatibility and availability constraints attached, not as an afterthought.
A certificate ticket should list every affected endpoint and the expected names. An HSTS ticket should say where the HTTPS response headers are produced and what policy the service can actually support.
Run a real retest
Open the full report through your purchase link or qualifying account and use the retest control, labelled Run it now where offered. Purchases include a 30-day free-retest window under the current product model. Outside that window, check the displayed eligibility and price first.
A retest produces a new report. Two things that do not:
- Reopening an old link. It re-reads the stored result.
- Submitting the domain on the home page. That can reuse a recent result.
Check the new scan time is after your deployment. Every other verification step depends on that one fact.
Verify the finding, then the score
In that order, and the order is the point.
Check the specific endpoint first. The expired certificate is replaced, the deprecated protocol is no longer offered, the intended policy is visible. Then confirm the other addresses got the same change.
Only then look at the categories and the overall number. Discovery changes, different eligible populations, and scoring revisions all move the score independently of your work, so a new finding somewhere else does not mean your fix failed. See how the score works.
When a finding will not go away
Run down this list before assuming the report is wrong:
- Did the change reach the machine that actually terminates public TLS, or only the origin behind a CDN?
- Did the process reload, or is it still running on the old configuration?
- Is DNS still handing out an old address?
- Did IPv6 get the change? Did every node in the pool?
- For DNS policies, have the TTLs expired, and did you edit the right zone in the delegation chain?
And one that looks like success but is not: if the retest shows missing evidence where the finding used to be, nothing has been proven. A check that did not run is not a check that passed. Read result states and connection errors to work out what the retest actually established.