Everything on the outside of your domain is already public

Your TLS configuration, your DNS records, your response headers and the version banners your software volunteers are visible to anyone who asks for them. No access, no permission, no relationship required. The only question is whether you have looked at that surface as carefully as the people who look at it for a living.

Why this stopped being only a security topic

For a long time the external posture of a domain mattered mainly to the security team. Three changes moved it into commercial territory:

• Procurement asks. Vendor questionnaires now routinely cover transport security, email authentication and subdomain hygiene. The answers are checkable, which means a wrong answer is worse than an uncomfortable one.
• Supply chain expectations tightened. Larger organisations — and, in the EU, entities within scope of the NIS2 framework — increasingly push security requirements down to their suppliers. Being small is no longer an exemption from being asked.
• Insurers and auditors check the easy things first. An expired certificate or a missing email authentication record is trivial to verify and hard to explain away.

What tends to be wrong, and why nobody noticed

Outside-in findings are rarely exotic. They are almost always the result of something that used to be true:

• A certificate that renews everywhere except one host — the API endpoint, the staging box that quietly became production, the redirect domain nobody owns.
• Email authentication left in monitoring mode years after it was introduced "temporarily", so anyone can still send mail claiming to be you.
• DNS entries pointing at services that were decommissioned, which is how subdomain takeovers happen.
• Security headers set on the marketing site but not on the app, because they were added by whoever built the marketing site.
• Software versions announced in response headers, turning a known-vulnerability lookup into a five-second exercise.

None of these require a sophisticated attacker. They require someone to check, once, and then keep checking — because every one of them was correct on the day it was set up.

What TCSR does

TCSR — the Talivio Cyber Security Report — is a product of Talivio Technology OÜ, the company that also publishes Talivio News.

• A tiered scan across in-house modules, from passive OSINT through active checks to matching against known vulnerabilities.
• Domain verification before scanning. You scan what you control — which is also why the report means something to a third party.
• An independently verifiable report with a SHA-256 checksum, so the document you send to a customer can be shown to be the document that was produced.
• Continuous monitoring, because posture decays: a certificate expires, a record is edited, a header is dropped in a refactor.
• A self-updating trust badge reflecting the current state rather than the day it was installed — the same badge you will find in this site's own footer.

What an external scan is not

This matters more here than for most products, because an overstated security claim can lead someone to skip a control they actually needed.

TCSR looks at your domain from the outside. It is not a penetration test, not a code review, and not an assessment of your internal network, your access controls or your backup strategy. A clean external report means the surface everyone can see is in order. It says nothing about what is behind the login, and it is not a certification.

That is still worth having — the externally visible surface is where most questions start, and it is the only part of your security posture that your customers can evaluate without asking you.

See TCSR →