Digital Discovery
External attack surface discovery and a threat profile. Start from the IP addresses, domains and subsidiaries you know about; we look for internet-facing assets you’re missing, show the evidence for each, and set out which ones attackers who target organisations like yours would most likely go after first.
This service is in preparation: we are not yet taking on Digital Discovery clients. Talk to us if you would like to know when it opens.
Book a ConsultationThe assets you don’t know about are the ones nobody patches
Most asset lists trail reality. A subdomain set up for a campaign and never taken down. A test server that went live and stayed live. The domains and address ranges of a company you acquired. A cloud account opened on a team’s card, or a SaaS platform nobody told IT about — what NCSC guidance calls shadow IT: IT used for business purposes but not accounted for in asset and risk management. The same guidance says your inventory should include your internet presence: domain name registrations, IP address spaces, digital certificates and social media accounts.
Forgotten assets don’t stay harmless. A DNS record still pointing at a cloud resource you have deleted can let someone else claim that resource and serve content under your name — Microsoft notes they can even obtain a valid certificate for it. An admin login or remote-access service that nobody remembers opening is still exposed, and probably still unpatched. And the trail is public: CT-enforcing versions of Chrome reject a publicly trusted certificate unless it carries proof that it was submitted to certificate transparency logs, so in practice the certificates your public sites use are logged — and RFC 9162 (Experimental), the IETF’s latest CT document, warns that logs can reveal domain names that might not otherwise be easy to discover. Attackers read them too.
Digital Discovery starts from what you already know and works outwards through public sources to find what your list is missing. Every candidate comes with its evidence and a confidence level, and nothing is treated as yours until you confirm it. Alongside the inventory you get a threat profile: who, according to dated public reporting, goes after organisations like yours, and which of your assets they would most likely aim at first.
From the list you have to the estate you’ve got
You share what you know
The IP addresses, domain names, subsidiaries and brands you know about, however rough the list. We agree the scope, your contacts, and what may be shared with outside data services, in writing.
We work outwards
From each starting point we follow public sources: registries and filings to subsidiaries, registration data and certificate logs to domains, routing data to address space, and on to the hosts, cloud services and code that point back to you.
Evidence and confidence
Every candidate asset comes with the evidence that links it to you, the date we saw it and a confidence level. Candidates that look like someone else’s are marked as such.
You confirm what’s yours
You tell us which candidates are yours, which aren’t and which need checking. We never treat ownership as proven on our own say-so: only assets you confirm, and authorise in writing, go any further.
Light checks on confirmed assets
On assets you have confirmed and authorised in writing, light-touch checks of DNS and email security records, certificates and TLS configuration, and HTTP security headers. Port and service scanning belongs to Vulnerability Scanning or a penetration test. No logins, no exploitation.
Report and threat profile
Your inventory with evidence and confidence, the gap between your list and what we found, prioritised exposures with fixes, and the threat profile.
Repeat when you choose
Run it again on a schedule you choose. Each run is a fixed-scope report at a point in time, not continuous monitoring, and says what appeared, changed or is no longer seen since the last. Confirmed assets can join your Vulnerability Scanning scope once you add them to its written authorisation, and the Dark Web Monitoring watch list once that service opens.
Wherever your name leads
Subsidiaries & brands
Company registers, annual reports, securities filings and Legal Entity Identifier records, to map the companies you own — including ones you acquired — and the brands, trading names and published apps that belong to them. Filings can leave out smaller subsidiaries and not every parent link is public, so each link shows its source and date, and we say where the map is thin.
Domains, subdomains & certificates
Registration data (often redacted these days, so one source among several), certificate transparency logs, public DNS and historical DNS data from licensed third-party services, to find the domains and subdomains that point back to you. Records left pointing at deleted cloud resources are flagged as takeover candidates — we never claim the resource to prove it. Look-alike domains registered by others are reported to you, never tested.
IP space & hosting
Your own regional internet registry records, which you fetch and share with us, and public routing data, to find the address ranges and networks registered to you or announced for you, and internet-scan data, from services licensed for client work, to see what appeared to be running there, and when. Those are dated indications, not findings. Once you confirm an asset and authorise us in writing, our own checks cover its DNS and email records, its certificate and TLS on port 443, and its HTTP headers; what a dataset says is running there — a remote-access service, an admin login, a product version — stays a dated indication for you to check, or for Vulnerability Scanning to confirm under its own authorisation. Shared hosting and CDN addresses are marked as shared.
Cloud & SaaS footprints
Hosts in the cloud providers’ published address ranges, storage and application endpoints your DNS and web pages point to, and the verification records SaaS platforms ask you to publish in DNS. A provider’s address range identifies the provider, not the customer, so cloud candidates always need your confirmation, and each confirmation is dated because cloud addresses get reassigned. A full list of the SaaS your staff use needs data from inside, and we say so.
Code & data exposed in public
Public code repositories, package registries and search engines, for your domains, internal hostnames, configuration and references to your storage. Code is read in place, never cloned; exposed files, documents and storage are recorded by location, never opened or downloaded. A credential found this way is never used — we record that it exists, not its value, and tell your named contact straight away.
Dark web — when Dark Web Monitoring opens
Not available yet. Dark Web Monitoring is in preparation, and we are not yet taking on monitoring clients. When it opens, the plan is for Digital Discovery to cover leak sites, criminal forums and markets for your confirmed domains and brands under the same read-only rules: we never buy, bargain, post, use personas or sign in, and never download dumps.
Who goes after organisations like yours, and what they’d aim for
Alongside the inventory, you get a threat profile: which types of threat actor, and which campaigns, dated public reporting shows targeting organisations like yours — by sector, geography, technology and size — and which of the assets we found they would most likely go after first. A remote-access gateway on a forgotten address and a look-alike domain registered last month matter to different attackers; the profile says which matters to whom.
What’s in it
Threat-actor types — criminal groups, ransomware operations, initial access brokers, hacktivists, state-linked groups — with groups and campaigns named only as a cited public source names them. For each, the assets in your inventory they would most likely aim at, and the tactics involved, named from MITRE ATT&CK® — techniques only where a cited source names them.
Sources, dates, confidence
Every statement cites its source and its date — government cyber agencies, regulators and published research — and the profile records which ATT&CK version it uses. How likely something is, and how confident we are in that judgement (high, moderate or low), are stated separately, as intelligence-analysis guidance such as the FIRST CTI SIG’s suggests. A Traffic Light Protocol label shows who it can be shared with.
What it is not
Not attribution: we report the attributions a cited source makes and never make our own, and we never invent actor names or campaigns. Not evidence that anyone is targeting you now — it describes who targets organisations like yours. And not a targeted threat intelligence report for DORA TLPT, TIBER-EU or CBEST.
Look first. Touch only what you confirm.
- Passive first — discovery works from public records and from third-party data services licensed for client work; what we learn about a candidate comes from what is already published, not from probing it
- Nothing more until you confirm and authorise — until you confirm an asset is yours and authorise us in writing, it gets only the ordinary requests any visitor makes: a DNS lookup, a public web page, a TLS certificate. No brute-force guessing of names and no zone transfer attempts
- No scans, logins or exploitation before then — no port scans, vulnerability checks, sign-ins or exploitation on anything you haven’t confirmed and authorised; exposed data is noted, never downloaded, and a credential we come across is never used
- Someone else’s asset is reported, never tested — a supplier’s server, a hosting provider’s address, a look-alike domain registered by a stranger: your authorisation can only cover what you control, so we tell you about it and leave it alone
- Your names go only where you agree — searching a data service shows it what we search for, so we agree with you up front what may be shared with outside services
- Personal data kept to what the finding needs — names and email addresses turn up in registrations, certificates and code; we keep only what a finding needs, and never build profiles of individuals
- Dark Web Monitoring’s rules, unchanged — when the dark-web element opens, it follows Dark Web Monitoring’s read-only house rules: never buy, bargain, post, use personas or sign in, and never download dumps
What the rules expect of your inventory, and where our service stops
Several frameworks expect a complete, current inventory of your assets, and some expect you to understand the threats you face; most leave it to you how to find what that inventory is missing. Here is what they say, and what a discovery engagement can and cannot support. Current as of October 2026.
| Instrument | Status | What it means for discovery |
|---|---|---|
| NIS2 Directive (EU) 2022/2555 Art 21(2)(i) Implementing Reg (EU) 2024/2690 Annex 12.4 and 2.1.2(e) | Binding · the Directive’s measures apply through national law: Member States were to apply them from 18 Oct 2024, and the date in each country depends on its transposition — several transposed late, and in Jul 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for not notifying full transposition; the Dutch law took effect on 15 Aug 2026, and that case was closed in Oct 2026. Implementing Reg in force since 7 Nov 2024, for the entity types it lists. ENISA implementation guidance: guidance, Jun 2025 | Asset management is one of NIS2’s minimum cybersecurity risk-management measures. For in-scope DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed and managed security service providers, trust service providers, and providers of online marketplaces, online search engines and social networking services platforms, the Implementing Regulation calls for a complete, accurate, up-to-date and consistent inventory of assets, reviewed and updated regularly, with a history of changes — without saying how to make it complete. Its risk analysis takes cyber threat intelligence and vulnerabilities into account. ENISA’s non-binding guidance suggests, ideally, tools that continuously discover and track on-premises and cloud assets, or else manual update procedures; a periodic, analyst-led engagement isn’t that continuous tracking, but it can show internet-facing assets your inventory may be missing. The inventory stays yours. Other NIS2 entities should check their national law. |
| NIS2 Directive (EU) 2022/2555 Art 3(4)(b) and 27(2)(f) Amending proposal COM(2026) 13 | Binding through national law · entity lists due by 17 Apr 2025; Art 27 registry details due by 17 Jan 2025. COM(2026) 13: proposed · dated 20 Jan 2026; awaiting committee decision in the European Parliament as of Oct 2026 | NIS2 already has Member States require in-scope entities to give their competent authorities their contact details, “including email addresses, IP ranges and telephone numbers”, and to notify changes within two weeks. DNS service providers, TLD name registries, domain name registration services, cloud computing, data centre, content delivery network, managed and managed security service providers, and providers of online marketplaces, online search engines and social networking services platforms also give “the entity’s IP ranges” for ENISA’s registry. The proposal would not add this: it would give IP ranges a point of their own in the registration list and fold the registry details into it. It is not law, and its final content and timing are unknown. Discovery can show internet-facing address space your registration may not list; what you register stays your decision. |
| DORA Art 8(1), (2), (4) and (6) RTS (EU) 2024/1774 Art 4(2)(b)(vii) | Binding · DORA has applied since 17 Jan 2025; RTS in force since 15 Jul 2024. Not for entities under Art 16(1), which follow DORA’s simplified framework (Art 16; RTS Title III, where Arts 30–31 cover identification and threats) | Financial entities identify, classify and adequately document their ICT-supported business functions and the information and ICT assets supporting them, reviewing that classification at least yearly; identify all information and ICT assets, including those on remote sites, network resources and hardware; and update inventories periodically and on every major change. Art 8(2) has them assess the cyber threats and ICT vulnerabilities relevant to those functions and assets, and review risk scenarios at least yearly. Under the RTS, each ICT asset’s record includes whether it can be or is exposed to external networks, including the internet — discovery checks that from the outside, and a confirmed asset we find exposed that your records list as internal is a finding. The duties stay yours: discovery shows what an inventory may be missing, and a threat profile is one input to the threat assessment. |
| DORA Art 26 and Delegated Reg (EU) 2025/1190 (TLPT) TIBER-EU; CBEST | Binding for financial entities identified for TLPT · DORA has applied since 17 Jan 2025; Delegated Reg in effect since 8 Jul 2025. TIBER-EU (framework, Jan 2025) and CBEST (Bank of England implementation guide, 2024 edition, last updated Aug 2026) are supervisory frameworks | Threat-led penetration tests rest on targeted threat intelligence from a threat intelligence provider that meets each framework’s own criteria — always external in TIBER-EU, CBEST-accredited in CBEST. Some of that report’s contents overlap in kind with ours, such as look-alike domains and technical reconnaissance. Our threat profile is not a targeted threat intelligence report, a generic threat landscape report or threat intelligence provider work, and we do not deliver DORA TLPT, TIBER-EU or CBEST tests. |
| PCI DSS v4.0.1 Req. 12.5.1, 12.5.2, 12.5.2.1, 12.5.3 and 4.2.1.1 | Binding by contract — an industry standard, not law. 12.5.2.1, 12.5.3 and 4.2.1.1 in force since 31 Mar 2025; wording as in the public v4.0 SAQ D | You keep an inventory of in-scope system components and confirm your PCI DSS scope at least once every 12 months and on significant change, including every location where account data is stored, processed or transmitted, inside or outside the defined cardholder data environment; service providers confirm scope at least every six months, and review the scope impact of significant changes to organisational structure. PCI SSC notes that this confirmation is the entity’s own activity, and is neither the same as nor replaced by the scoping its assessor confirms. Discovery can surface hosts, domains and certificates your scope document doesn’t list; whether any of them touch account data is for you and your assessor to decide. Req. 4.2.1.1 adds an inventory of trusted keys and certificates protecting card numbers in transit — certificate transparency logs show only publicly trusted ones. |
| NCSC (UK) Cyber Assessment Framework 4.0, A3 and A2.b Asset management guidance | Guidance · CAF 4.0, Aug 2025; asset management guidance, May 2021 | At “Achieved”, A3.a has all assets relevant to the secure operation of your essential functions identified and inventoried, with the inventory kept up to date. A2.b (understanding threat) looks for an understanding of threat actors’ capabilities, methods and techniques and of which systems they may compromise. NCSC’s asset management guidance says an inventory should include your internet presence — social media accounts, domain name registrations, IP address spaces and digital certificates — and suggests recording a confidence score or last-seen timestamp. Each candidate carries our confidence level, and each entry the date we last saw it. |
| Cyber Essentials v3.3 (UK) | Voluntary certification scheme, though under PPN 014 UK central government and NHS bodies require it, or equivalent controls, of suppliers on certain contracts · v3.3 effective 27 Apr 2026 | You define the scope and agree it with the Certification Body; the requirements apply to in-scope devices and software that can accept incoming connections from the internet, make outbound connections or control the flow of data, and cloud services cannot be excluded from scope. Asset management isn’t itself a Cyber Essentials control, though the scheme says effective asset management can help meet all five. Discovery can show internet-facing systems and cloud services your scope may have missed. Our service is not a Cyber Essentials assessment. |
| NIST Cybersecurity Framework 2.0 ID.AM-01, ID.AM-02, ID.AM-04, ID.RA-02, ID.RA-03 | Guidance (voluntary framework) · 26 Feb 2024, still current | Outcomes include maintained inventories of the hardware, and of the software, services and systems, managed by the organisation; inventories of services provided by suppliers; cyber threat intelligence received from information sharing forums and sources; and internal and external threats identified and recorded. The CSF does not prescribe how outcomes are achieved. Our report and threat profile can feed these outcomes; they don’t certify them. |
| CISA BOD 23-01 and BOD 26-04 (US) | Binding on US federal civilian agencies only · BOD 23-01, 3 Oct 2022; BOD 26-04, 10 Jun 2026 | BOD 23-01 has agencies perform automated asset discovery — an activity it describes as non-intrusive — every 7 days, to identify what resides on their own networks. BOD 26-04 has them update or attest their publicly exposed IP addresses and agency-owned domain names each quarter, listing additions and removals, and, within 180 days of issue, continuously identify and tag all agency-owned assets reachable from outside. BOD 26-04 reaches contractors only where their contract says so. We cite both as a benchmark of what a government expects of its own estate, not as rules that bind you. |
| ISO/IEC 27001:2022, Annex A 5.9 | Voluntary certifiable standard · 2022 | Annex A 5.9 is the control ENISA’s NIS2 mapping table (v1.2, Aug 2025) links to the asset inventory point, while stating that the mapping is not a measure of equivalence. Our report is test evidence your certification auditor can review; the audit and the certificate are theirs. |
| EU GDPR Art 6(1)(f), Recital 49 | Binding · EU GDPR has applied since 25 May 2018. EDPB legitimate-interest guidelines: draft guidance, Oct 2024 | Publicly accessible personal information is still subject to data protection law in most jurisdictions, as the ICO and other data protection authorities said jointly in August 2023. Network and information security can be a legitimate interest where processing is strictly necessary and proportionate, and only where people’s interests and rights don’t override it; the EDPB’s draft guidelines add that security cannot justify excessive processing. So names and email addresses found in registrations, certificates or code are kept only where a finding needs them. |
| Computer Misuse Act 1990 (UK) s.1 and s.17(5) | Binding · in force. A defence to s.1 for security researchers is proposed (government statements Dec 2025 and Sep 2026; the Sep 2026 statement limits it to accredited researchers). The May 2026 King’s Speech promised a National Security Bill updating the Act; as of Oct 2026 it has not been introduced and no bill carries the defence | Causing a computer to perform any function with intent to secure unauthorised access to programs or data, knowing it is unauthorised, is an offence; access is unauthorised without consent from someone entitled to control it. On our reading, your written authorisation can only cover what you are entitled to control, which is why an asset that turns out to be someone else’s is reported, never tested. |
What you get
- Asset inventory with evidence and confidence — each asset we found, what links it to you, when we saw it, how confident we are and whether you have confirmed it, ready to reconcile with your own asset register
- The gap — what your list had and ours didn’t, what ours had and yours didn’t, and what turned out to belong to someone else
- Prioritised exposures with fixes — dangling DNS records, forgotten hosts, exposed admin and remote-access services, weak email and TLS settings, each with a concrete fix; anything urgent, such as a dangling record that looks open to takeover or an exposed credential, goes to your named contact as soon as we find it, not with the report
- Threat profile — who targets organisations like yours and which of your assets they would most likely go after, with sources, dates and confidence labels
- Hand-off of confirmed assets — ready to add to your Vulnerability Scanning scope with a written amendment to your authorisation, to the scope of a penetration test, or to the Dark Web Monitoring watch list once that service opens
- Change report on every repeat run — what appeared, changed or is no longer seen since the last run, on the schedule you choose
- Coverage statement — the kinds of source we used, what we could and couldn’t see, and the date of each observation
Find what you didn’t know you had.
Discovery will start with whatever list you have — IP addresses, domains, subsidiaries — and an agreed scope. The service is in preparation; talk to us if you would like to know when it opens.
Get in Touch