footprintresearcher who rejects consensusresearchpreventionpredictions

Basic digital footprint check: what free tools find and what they miss

Sienna VanceApril 29, 2026

Basic digital footprint check: what free tools find and what they miss

Key takeaways

A basic digital footprint check using crt.sh, passive DNS, and Google dork operators takes under an hour and reliably surfaces subdomains, certificate history, and indexed documents — but stops at assets with no public TLS certificate and credential material in private repositories.
Every unrecognized asset surfaced by a basic check creates two questions: is it still reachable, and does it process personal data that should appear in a GDPR Article 30 record?
Free tools surface what exists. They do not surface what has changed since last checked. Configuration drift on known assets — the highest-severity finding category in Vulnox assessments — is invisible to point-in-time free-tool checks.
Staging environments are the most common high-severity finding from basic digital footprint checks: provisioned for temporary use, left reachable, running production-like data, and absent from every compliance scope.
A basic check that surfaces unknown assets and produces no action is not due diligence. Under GDPR Article 32, discovery creates an obligation to address. The check is the starting point, not the deliverable.

TL;DR

A basic digital footprint check with free tools is genuinely useful and genuinely limited. It surfaces subdomains, certificates, indexed content, and domain history in under an hour. It does not surface assets behind authentication, credential material in private code repositories, or configuration changes on assets that were clean last time. For regulatory purposes, running a basic check and acting on what it finds is substantively different from running a basic check and filing the output. The check creates the obligation. What happens after determines whether that obligation was met.

What a one-hour free-tool check actually produces

A compliance officer at a 60-person professional services firm ran a basic digital footprint check before a GDPR audit. She searched crt.sh for the company domain, ran a Google site: query, and pulled WHOIS records for the two domains the company actively maintained. The check took 45 minutes. The output showed the main website, the client portal, two social media profiles, and a certificate issued eight months prior to a subdomain she did not recognize: staging-crm.companydomain.com.

Turning point:

Following up on that subdomain took another 20 minutes. It was still resolving. It was running a version of the CRM platform that was two major releases behind the production instance, had been provisioned for a migration project the previous year, and was accessible with HTTP basic authentication using credentials that matched the pattern of the company's default test credentials. The CRM instance contained 340 client records with contact information and engagement history. The subdomain was absent from the company's Article 30 record. The audit was two weeks away. The basic check had found something the company's internal processes had entirely missed — and the check itself had taken under an hour.

What each free tool actually queries and what it cannot reach

Understanding what free tools query is the only way to understand what they miss. Certificate transparency is the most reliable source. Every publicly trusted TLS certificate issued since 2018 is logged within minutes of issuance. Searching crt.sh for a domain returns the full certificate history for that domain and all subdomains — including subdomains that were decommissioned, certificates that expired, and subdomains that were provisioned without ever being linked from the main site. The limitation is scope: CT logs only contain entries for assets that obtained a publicly trusted certificate. An asset accessible over HTTP, or using a private CA, or behind authentication that was never issued a public certificate, will not appear.

Passive DNS queries historical DNS resolution data from third-party aggregators. Tools like SecurityTrails, ViewDNS, and DNSdumpster maintain records of DNS entries over time, including entries that have since been removed. This surfaces subdomains that existed, even briefly, and may have left infrastructure reachable after DNS records were cleaned. The limitation is coverage: passive DNS data depends on what those aggregators have cached, which varies by domain popularity and query frequency.

Google dork operators — site:domain.com, filetype:pdf site:domain.com, inurl:admin site:domain.com — query what Google has indexed. This surfaces documents, configuration files, login pages, and directory listings that search engines crawled and stored. The limitation is indexability: assets behind authentication, assets that block crawlers, and assets that were never linked from any indexed page will not appear in search results.

What the combination misses: assets provisioned through cloud providers using rotating IPs and no organizational domain, credential material committed to private or now-deleted repositories, vendor-created subdomains that never had a public certificate, and configuration changes on assets that were clean at last check.

Example

In a Vulnox assessment following a client's self-conducted basic check, the client reported finding 12 subdomains through crt.sh and passive DNS. Passive recon using the same sources plus historical repository searches and archived web content surfaced 31 additional assets — including 4 subdomains with API endpoints documented in a developer portal that had been taken offline but not removed from web archives, and credential material in a public repository commit from 18 months prior that was still valid against the production API.

crt.sh supports wildcard searches using the percent sign as a wildcard character: searching for %.yourdomain.com returns all subdomain certificates. The JSON API at crt.sh/?q=%.yourdomain.com&output=json supports scripted queries for organizations that want to automate monitoring against the certificate log rather than running manual searches.

The basic digital footprint check: step by step

Step 1
Certificate transparency search
Output:
Full subdomain list with certificate issuance dates and issuing CA. Sort by most recent issuance to prioritize investigation of recently created subdomains not in the known inventory. Flag any subdomain not recognizable to current staff — including those with issuance dates preceding current team tenure.
Purpose:
Surface all subdomains that have ever had a publicly trusted TLS certificate, including decommissioned subdomains and short-lived certificates issued for temporary deployments.
Step 2
Passive DNS enumeration
Output:
DNS history for the primary domain including A records, CNAME targets, and MX records. Cross-reference against CT results to identify subdomains present in DNS history but absent from certificate logs — these are the assets most likely to have been provisioned informally and never properly decommissioned.
Purpose:
Surface subdomains that existed without a public TLS certificate, or that were active before CT logging became mandatory, or whose DNS records have since been removed but whose infrastructure may still be reachable.
Step 3
Google dork queries
Output:
Run site:yourdomain.com to see all indexed pages. Run filetype:pdf site:yourdomain.com, filetype:xlsx site:yourdomain.com, and filetype:env site:yourdomain.com for document and configuration exposure. Run inurl:admin site:yourdomain.com and inurl:login site:yourdomain.com for authentication panel exposure. Each result warrants a manual review for sensitivity.
Purpose:
Surface indexed documents, configuration files, login panels, and directory listings associated with the domain that search engines have crawled.
Step 4
WHOIS and reverse WHOIS
Output:
Domain list associated with the organization's registrant contact data. Domains not in the known asset inventory are candidates for review: are they still resolving, what are they serving, and do they process personal data that should appear in Article 30 records?
Purpose:
Identify additional domains registered to the same organization using the same registrant contact information — including acquisition domains, campaign domains, and test domains that may not be known to current staff.
Step 5
Manual spot-check of unrecognized assets
Output:
Per-asset record showing: resolves yes/no, content type, personal data handled yes/no, Article 30 record present yes/no, current owner. Assets that resolve, handle personal data, and have no Article 30 record require immediate attention before any other remediation prioritization.
Purpose:
For each asset surfaced that is not in the known inventory, confirm current reachability, identify what the asset is serving, determine whether it handles personal data, and assign an owner.

What a basic check reliably misses

Assets provisioned through cloud providers using non-organizational domains

A development team that spins up an AWS instance and accesses it via the EC2 public DNS name — something like ec2-54-123-45-67.compute-1.amazonaws.com — has provisioned infrastructure that will not appear in any search against the organizational domain. If that instance handles company data or is used to test production integrations, it is an external exposure invisible to domain-scoped basic checks. The only discovery mechanism is cloud provider inventory review, which requires access to the cloud account.

Credential material in archived or deleted repositories

Public code repositories are a common source of credential exposure — API keys, database connection strings, and authentication tokens committed during development and never removed. Basic checks rarely include repository searches. Even when they do, they typically search current repository state rather than commit history. Deleted repositories are cached by web archives and indexers. Credential material that was committed, then deleted, may remain accessible for years through these caches and may still be valid if rotation was not performed.

Vendor-created infrastructure resolving under organizational domains

Analytics platforms, marketing automation tools, and payment processors create subdomains and CNAME records under client organizational domains as part of their integration setup. These assets will appear in CT logs and passive DNS searches — but they may be misattributed to the organization's own infrastructure when they are actually vendor-controlled. The implication for GDPR is that these are processor arrangements: the vendor controls the infrastructure but the data controller bears responsibility for its security. Correctly identifying vendor-created assets requires following CNAME chains to their ultimate destination.

Configuration drift on previously checked assets

A basic check run today against an asset that was clean the last time it was checked tells you that the asset is clean today. It does not tell you whether the configuration changed between checks. An asset that had authentication in place three months ago may have had that authentication removed during maintenance. An asset running a current software version last quarter may have been updated to a vulnerable release. Detecting configuration drift requires comparison against a prior baseline — which point-in-time free-tool checks do not produce.

The organizations that run the most thorough basic checks find the most surprises

Common belief

Organizations with mature IT governance — formal change management, documented asset inventories, regular security reviews — will find fewer surprises in a basic digital footprint check than organizations with less structured processes.

What we found

In Vulnox assessments, the finding that consistently surprises security teams is not the misconfigured current asset but the perfectly functional forgotten one: a client portal from a discontinued service line still serving a login page, a developer tool from three years prior still reachable and still running valid session credentials. The IT team knows it is not actively used. It does not know it is still reachable.

In practice, the opposite pattern is more common. Organizations with mature IT governance have more operational history: more past projects, more acquisitions, more staff turnover, more years of accumulated infrastructure decisions. A basic footprint check against a 15-year-old organization surfaces more historical assets than a check against a 3-year-old one — regardless of how well-governed either is today.

The governance maturity controls the quality of what the organization knows about. It does not control what was provisioned before current processes were in place, what was created by teams that have since left, or what was inherited through acquisitions. A thorough basic check conducted by a compliance officer who has been with the organization for two years will surface assets provisioned before she arrived. The surprise is not evidence of poor governance — it is evidence of organizational history.

Where basic footprint checks create future compliance obligations

Supervisory authorities will begin treating the absence of any documented external asset discovery process as independent evidence of inadequate Article 32 implementation — separate from whether an incident occurred.
Current GDPR enforcement focuses on breach response: what happened, who was affected, what was done. Proactive enforcement against organizations that have not performed basic discovery is rare. As the regulatory community accumulates evidence that discoverable external exposures are prevalent and that basic free-tool checks are accessible to any organization, the argument that an organization did not know about a discoverable asset becomes harder to sustain. The shift from reactive to proactive enforcement on asset visibility is a trajectory already visible in NYDFS guidance.
Confidence: mediumAn EDPB opinion or national supervisory authority enforcement decision by end of 2027 that specifically cites failure to conduct external asset discovery as an independent Article 32 violation, not contingent on an incident having occurred.
The proliferation of AI-assisted development tooling will produce a new category of external exposure: automatically generated subdomains and API endpoints created by development copilots that provision cloud resources as part of code execution, leaving infrastructure reachable after the session ends.
Development tools that provision cloud resources on behalf of developers — executing code, deploying test environments, creating API endpoints for integration testing — are becoming standard in enterprise development workflows. These tools create external assets as a side effect of their primary function, without the developer necessarily being aware that persistent infrastructure was created. The organizational processes for tracking developer-provisioned infrastructure are already inadequate for manually provisioned assets. They are not designed for automatically provisioned ones.
Confidence: highA documented breach or regulatory finding by end of 2027 attributing initial access to AI-provisioned development infrastructure that was not tracked in any organizational asset inventory.

Running the check and filing the output are not the same thing

A basic digital footprint check that produces a list of findings and no subsequent action is not due diligence. It is evidence of awareness without response — which, under GDPR, is materially worse than no check at all. Article 32 requires appropriate technical and organizational measures. An organization that ran a check, found an exposed staging environment processing client data, and took no action has documented that it knew and did not act. That documentation is exactly what supervisory authorities look for when assessing whether an organization's response to a breach was adequate.

My position: run the check. But treat every unrecognized asset it surfaces as a task, not a finding. The check creates an obligation. Filing the output satisfies no one — not the regulator, not the organization, and not the clients whose data may be on the assets that were found and ignored.

Counterargument

The counterargument is that for very small organizations with no dedicated security staff, running any check and producing any output is a meaningful step, and that setting a standard of mandatory action on every finding creates a burden that makes checks less likely to happen. That argument has merit for the smallest organizations. For any organization handling personal data at commercial scale, the argument fails: the regulatory obligation is not proportional to whether a check was run. It is proportional to the risk to data subjects.

One thing to do this week

Go to crt.sh and search for %.yourdomain.com. Look at the results sorted by most recent certificate issuance date. Find the first subdomain in the list that you do not immediately recognize. Follow up: does it resolve, what is it serving, does it handle personal data, and is there a documented owner? That single follow-up is the action that separates a basic digital footprint check from a compliance obligation met. If you find the subdomain resolves, handles data, and has no owner, you have found the most common high-severity finding in external exposure assessments — in under an hour, for free.

Frequently Asked Questions

What does a basic digital footprint check actually reveal?

A basic check using free tools — certificate transparency searches, passive DNS queries, Google dork operators, and WHOIS lookups — reliably surfaces subdomains with active TLS certificates, historically registered domains, indexed pages and documents, and IP ranges associated with the organization. It does not surface assets that have never had a public certificate, infrastructure behind authentication that search engines have not indexed, or credential material in private repositories.

How do I run a basic digital footprint check using crt.sh?

Search crt.sh for your organization's primary domain using the wildcard syntax: %.yourdomain.com. The results show every TLS certificate issued for that domain and all subdomains since Certificate Transparency became mandatory. Sort by issuance date to find recent certificates for subdomains you do not recognize. Each unexpected entry warrants a follow-up: does the subdomain still resolve, what is it serving, and is it in your asset inventory?

What are the compliance implications of finding unknown assets in a digital footprint check?

Under GDPR Article 30, organizations must maintain records of processing activities covering all systems that handle personal data. An asset surfaced through a footprint check that processes personal data and does not appear in the Article 30 record creates a simultaneous security exposure and compliance violation. Discovery creates a dual obligation: address the technical exposure and update the processing record. Organizations that address only the security exposure leave the compliance gap open.

What does a basic digital footprint check miss that a professional assessment finds?

Free tools miss assets that were provisioned without public TLS certificates, infrastructure created through cloud providers that use rotating IP addresses not associated with organizational domains, credential material committed to private or now-deleted repositories, and vendor-created subdomains resolving under organizational domains. They also miss configuration drift: assets that were clean at last check but whose configuration has changed. A professional assessment combines passive recon with certificate transparency monitoring, historical DNS analysis, and public code repository searches that cover the gaps free tools leave.

How often should an organization run a basic digital footprint check?

A basic check using free tools is worth running monthly for any organization with active development or cloud usage. The external surface changes faster than quarterly — new certificates are issued, subdomains are provisioned, and staging environments are exposed within weeks of any active development cycle. Monthly passive checks catch material changes. They do not replace continuous certificate transparency monitoring, which detects changes within minutes of issuance.

What should I do when a basic footprint check surfaces an asset I don't recognize?

For each unrecognized asset: confirm whether it still resolves, identify what it is serving and whether it handles personal data, determine whether it appears in your asset inventory or GDPR Article 30 record, and assign an owner. If it resolves and serves content, do not defer the ownership question — an asset with no owner has no one responsible for patching or decommissioning it. If it handles personal data and is absent from Article 30, update the record before addressing the technical exposure.

What is the regulatory risk of not running any digital footprint check?

Under GDPR Article 32, organizations must implement appropriate technical and organizational measures to protect personal data. An argument that the organization did not know about an exposed asset is weakened significantly when the asset would have been discoverable through a basic free-tool check that takes under an hour. Supervisory authorities examining a breach involving a forgotten subdomain or exposed staging environment will ask whether any external asset discovery was performed. The absence of any check — including a basic one — is itself evidence of inadequate measure implementation.

SaaS digital footprint: what customer-facing infrastructure exposes before anyone attacks

In Vulnox assessments, the average SaaS company has 11 externally reachable assets its own team cannot name. That gap between what you think you expose and what is actually visible is where most breaches begin.

Digital footprint exposure and data protection risk: what regulators find that internal teams miss

Forgotten subdomains, undocumented SaaS integrations, and exposed API keys are data protection violations waiting to be discovered -- by a regulator, not your internal team. Vulnox assessments found at least one forgotten subdomain in 71% of environments reviewed. Here is what that exposure looks like through a regulatory lens.

How your digital footprint cyber risk score is actually calculated

Most organizations do not know which external assets are dragging their cyber risk score down until an insurer tells them. Here is what the scoring models actually weight, and what DFA data shows about where the gaps are.

Ready to Secure Your Digital Assets?

Get a comprehensive vulnerability assessment for your website today.