SecQon failed its own scan

Everything on this page is about domains Infiqon owns: secqon.com, the product you are reading about, and docqon.com, a sibling Infiqon product. Neither is a customer. We publish results from our own assets because they are the only scan data we have the right to publish, and because a security product that has not been pointed at itself has not been tested.

On 29 August 2026 we ran six read-only probes against our own production systems. Alongside a set of scanner bugs, they found that our own site would have failed the scan we sell.

SecQon's security-headers check looks for five response headers that tell a browser how to protect the people using a site. On that day, neither the SecQon website nor the SecQon API sent any of them. Our own check would have filed five findings against us:

• HSTS header missing (medium) — nothing tells a browser to insist on HTTPS on the next visit.
• Content-Security-Policy header missing (medium) — nothing limits where scripts can load from if markup is ever injected.
• X-Content-Type-Options header missing (low) — the browser may guess a file's type instead of trusting the one declared.
• Clickjacking protection missing (low) — the page can be framed by another site.
• Referrer-Policy header missing (info) — full URLs can leak to third parties in the Referer header.

The same audit found something worse than a missing header: a check that could never fire. Our deprecated-TLS probe was meant to offer TLS 1.0 and TLS 1.1 to the server and see whether it accepted them. A modern OpenSSL refuses to offer those versions at its default security level, and it raises an error before a single packet leaves the machine. Our code caught that error in the same place it caught a server refusing, so every host, on every scan, looked as though it had turned the old versions off.

secqon.com and docqon.com both accept TLS 1.0 and 1.1. The scanner reported neither. Worse, earlier the same session we had checked this by hand with Python's ssl module and been fooled by exactly the same client-side refusal.

The probe now does what it claims. It makes up to three handshakes against the IP the scope guard authorised: one fully verified handshake, then one TLS 1.0 and one TLS 1.1 probe with verification off and the client configured so it can genuinely offer those versions. Each probe has three outcomes, not two: accepted, refused, or unknown. When the probe cannot tell, it files an evidence-free information note saying so, instead of recording "not enabled".

Fixing the probe did not fix the domains. For almost four weeks after we could see it, both still completed TLS 1.0 and 1.1 handshakes, and a SecQon scan of either reported Deprecated TLS 1.0 is enabled and Deprecated TLS 1.1 is enabled. On 24 September 2026 we set the minimum TLS version to 1.2 at our CDN edge, which is where the handshake actually happens for both domains; neither origin server needed changing. Offering TLS 1.0 and 1.1 by hand afterwards, all four hostnames refused with a protocol-version alert, while TLS 1.2 and 1.3 still connected.

The free instant check gives a posture score. On 29 August a domain that does not exist scored 89 (a B), higher than secqon.com's own 87. The instant check had never reached the host, so the only findings were "could not complete" notes, each worth a fraction of a point. A host we could not reach was being graded as a well-configured one.

Unreachable hosts are no longer graded. The score is also labelled for what it is on every report: a heuristic, 100 minus a fixed penalty per finding by severity, not a certification.

The site and the API now both send the five headers. Checked by hand on 24 September 2026, secqon.com serves:

• Strict-Transport-Security with a one-year max-age, includeSubDomains and preload.
• A Content-Security-Policy.
• X-Frame-Options: DENY.
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.

Our Content-Security-Policy is present but not finished. Its script-src still allows 'unsafe-inline', and SecQon's own check reports exactly that as a low-severity finding: Content-Security-Policy allows inline scripts. A header being present is not the same as it doing its job, which is why the check looks at values as well as names.

We are not publishing a re-scan score here. The TLS fix is verified by hand, not yet by a scan, and we do not have a score that reflects both fixes; an invented before-and-after number would be the exact thing this product exists to stop.

The blind TLS probe and the graded non-existent domain are the same bug in two costumes: an inability to check, recorded as a good result. It is the defect we have found most often in our own code, and it is the one a customer is least able to spot, because it looks like a clean report.

Our rule since then: a check that concludes anything from an empty or failed result has three outcomes, not two, and the report says when a check could not complete. Finding this kind of bug on our own domains is the reason we scan ourselves.