How to Externally Check a Vendor's Foundational Cyber Practices Before You Sign

You're about to renew a contract with a SaaS vendor, onboard a new payroll provider, or extend access to a logistics partner. Someone in your organization asks: "Are they actually secure?" You don't have a security team to answer that. You don't have time to read their 80-page SOC 2 report. And you can't install anything on their systems.

What you can do is check what's visible from the outside - the same view an attacker has. This guide walks through the foundational checks any business can run before extending trust to a third-party vendor.

Why the Vendor's Public Surface Matters

Every organization leaks signals. Open ports, expired certificates, misconfigured DNS records, leaked credentials on dark-web forums - none of these require a breach to surface. They accumulate over time, quietly, and they reflect how seriously a vendor treats basic security hygiene.

Before you evaluate a vendor's controls documentation, look at what they actually expose. Documentation describes intent. The external surface describes reality.

Check 1: SSL/TLS Certificate Health

An expired or misconfigured TLS certificate on a vendor's main domain or subdomains is a yellow flag. It suggests either poor operational discipline or a fragmented environment where someone isn't watching.

What to look for:

Free tools like SSL Labs' server test give you a letter grade. If a vendor you're about to trust with your data is running a B or below on their own login page, ask why before you sign.

Check 2: Open Ports and Services

A vendor's internet-facing infrastructure shouldn't expose services that have no business reason to be public. Databases, admin panels, legacy protocols - these are common findings on external scans and common entry points in supply-chain compromises.

You don't need to be a penetration tester to notice red flags. Tools like Shodan let you search a domain or IP range for exposed services. If you see RDP, VNC, or a database port exposed to the public internet, that's a conversation to have with the vendor before you extend them access to your systems.

Check 3: DNS Configuration and Email Security

DNS tells you a lot about how organized a vendor's security program is. Specifically:

These are free to configure, widely understood, and have been best practice for years. A vendor missing all three in 2026 is a vendor that hasn't been paying attention.

Check 4: Security Headers

When you visit a vendor's web application, your browser receives HTTP response headers. Some of these headers are security controls - they tell the browser not to load content from untrusted sources, not to expose the site to clickjacking, and so on.

Headers worth checking:

Tools like securityheaders.com scan a URL and grade the response. A vendor whose customer-facing application gets an F on basic browser security controls has a gap worth flagging.

Check 5: Dark Web Credential Exposure

This one is easy to miss because it doesn't show up in a port scan. Credential dumps from past breaches - breached email/password combinations, internal usernames, session tokens - circulate in dark-web forums and markets for months or years after the original breach.

If a vendor's employee credentials from a past breach are circulating in these markets and the vendor hasn't rotated access or enforced MFA, those credentials may still work. That's a supply chain risk to you.

You can check this manually with partial tools (Have I Been Pwned covers known public breaches), but systematic monitoring across a vendor's domain requires a more structured approach.

Putting It Together: Continuous vs. Point-in-Time

The checks above give you a point-in-time snapshot. The problem with point-in-time assessments is that vendor environments change - new subdomains spin up, certificates expire, credentials leak on a rolling basis. A clean scan today doesn't guarantee a clean surface next month.

For vendors who represent meaningful risk to your business, ongoing monitoring of their external surface gives you a more accurate picture than an annual questionnaire.

What This Looks Like in Practice

Tools like Safe Intelligence (safeintel.io) are designed for exactly this workflow - domain-based, agentless external scans that cover open ports, SSL certificates, DNS configuration, and security headers, plus continuous dark-web monitoring for credential exposure tied to a domain. It was built for organizations without a dedicated security team, which means the output is readable without a SOC analyst.

If you're evaluating third-party vendors or want to run the same check on your own domain first, it's a reasonable starting point for building a vendor risk habit without adding headcount.

The Takeaway

You don't need access to a vendor's internal systems to form a reasonable opinion about their security hygiene. Their external surface - certificates, DNS, open ports, credential leaks - is public by definition. Checking it before you sign, and monitoring it after, is a straightforward due-diligence step that most small and mid-size businesses skip simply because they don't know it's available to them.

It is. Start with what's visible.

Safe Intelligence by Apona | safeintel.io

This post is about Safe Intelligence.

More on this