Domain · External attack surface

What an attacker sees of you, checked regularly.

We list what your organisation exposes on the Internet, spot forgotten services, vulnerabilities and changes, and track remediation until it is verified.

Situations

You are in the right place if…

  • You do not know how many servers, domains and services you expose on the Internet.
  • An old website, a test environment or an admin interface is still online.
  • A provider opened an access for a job, and nobody closed it.
  • A critical vulnerability is announced on an edge device: you do not know whether you have one.
  • A client sends you the security score an external rating service gives you.
Our conviction

Exposure changes: controlling it takes regular checks.

Your attack surface moves with every release, every new cloud service, every provider intervention. An inventory made once is stale weeks later; attackers, for their part, scan the Internet continuously.

So we check your exposure at an agreed pace, flag what has changed, and close a finding only when the next check confirms the fix.

Our approach

From discovery to exposure under control.

Passive, non-intrusive observation; deeper tests are entrusted to a provider you mandate, on a scope authorised in writing.

  1. 01DiscoverDomains, subdomains, addresses, certificates, cloud services: everything that ties you to the Internet.

    You getAn inventory of exposed assets

  2. 02QualifyFor each asset: owner, purpose, open services, versions and known vulnerabilities.

    You getFindings ranked by severity

  3. 03Get it fixedClose, restrict, update: each finding becomes an action with an owner.

    You getA remediation plan

  4. 04Re-checkAt each pass, new items are flagged and fixes confirmed.

    You getA history of your exposure

What the texts say

What the texts expect of exposure control.

Knowing your assets and what you expose is the starting point of most texts.

  • DORADORA art. 8(1) · DORA art. 8(4)

    Financial entities identify and document all their ICT assets, including on remote sites, map those that are critical and review this classification at least once a year.12

  • DORADORA art. 25(1)

    Their testing programme includes appropriate tests, such as vulnerability assessments and scans and network security assessments.3

  • ReCyFReCyF v2.5, objectif 7 · ReCyF v2.5, objectif 18

    The ReCyF (working version) sets entities the objective of identifying their exposure needs and filtering inbound and outbound flows, and essential entities that of limiting the attack surface of their components.45

Our engagement

The same topic, at three levels of engagement.

You choose the level; the scope and deliverables are set by contract.

Level 01

Monitor

We check your exposure at an agreed pace and alert you to each new item and each visible vulnerability.

Deliverables
  • Inventory of exposed assets kept up to date
  • Alerts on new services and vulnerabilities
  • History of findings and their fixes
Level 03

Drive

We run remediation with your teams and providers until it is verified, without making the changes in your systems.

Deliverables
  • Tracking of remediation and its timelines
  • Reminders to asset owners
  • Re-check of each fix
Accelerators

What we bring from day one.

Non-intrusive discovery

A first map from public sources, without touching your systems, from the scoping stage.

Diff between two passes

Each check compares with the previous one: you see what appeared, what disappeared, what changed.

Your tracking web app

Assets, findings and remediation in one tool shared with your teams and providers.

Frequently asked questions

Before we start.

Are your checks intrusive?

Discovery relies on public sources and requests comparable to a visitor’s. Any deeper test is entrusted to a provider you mandate, with written authorisation, an agreed scope and timing; we help you choose it.

What about an asset nobody claims?

It is often the riskiest. We help find its owner; failing that, decide to close it, with your agreement.

How often should we check?

According to the pace of your changes and the criticality of assets: we set it at scoping, and tighten it when a critical vulnerability hits a type of device you expose.

Do the texts require an inventory of our assets?

For a financial entity subject to DORA, yes: identifying, documenting and mapping its ICT assets, and reviewing this classification at least once a year. The inventory of exposed assets is part of it, the most visible part.12

Start with a first map.

Give us your main domains. We come back to you with a proposal for a first, non-intrusive check.

Sources

The excerpts quoted.

Exact text, in its original language, from the frameworks extracted from the official text.

Show the 5 excerpts quoted
  1. 1DORA art. 8(1)32022R2554-a8-p1
    As part of the ICT risk management framework referred to in Article 6(1), financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk. Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  2. 2DORA art. 8(4)32022R2554-a8-p4
    Financial entities shall identify all information assets and ICT assets, including those on remote sites, network resources and hardware equipment, and shall map those considered critical. They shall map the configuration of the information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  3. 3DORA art. 25(1)32022R2554-a25-p1
    The digital operational resilience testing programme referred to in Article 24 shall provide, in accordance with the criteria set out in Article 4(2), for the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.
    Normative force
    directly applicable EU law (regulation, level 1)
    Source
    Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector
    Version
    CELEX 32022R2554 — ELI reg/2022/2554
    Official text
  4. 4ReCyF v2.5, objectif 7recyf:obj-7
    Les entités [importantes ou essentielles] identifient les besoins d’exposition des services et interfaces de leurs systèmes d’information ainsi que les besoins d’interconnexion de leurs activités et services à des systèmes d’information tiers. Ces entités filtrent les communications entrantes et sortantes de leurs systèmes d’information, en particulier les flux dont l’origine, le transit ou la destination est un système d’information tiers. Les entités [essentielles] cloisonnent leurs systèmes d’information en zones de sécurité cohérentes et contrôlent les communications entre ces zones de sécurité pour les utilisateurs, les prestataires et les fournisseurs.
    Normative force
    obligation (decree, resilience bill)
    Source
    ReCyF — Référentiel Cyber France (NIS 2, transposition nationale)
    Version
    2.5 du 17/03/2026 (version de travail)
    Status
    Working version: not binding until the transposition is enacted
    Official text
  5. 5ReCyF v2.5, objectif 18recyf:obj-18
    Les entités [essentielles] limitent la surface d'attaque des composants de leurs systèmes d’information. Pour ce faire, elles s’assurent que seules les ressources logicielles nécessaires à la réalisation de leurs activités et services ou au maintien en condition opérationnelle ou de sécurité sont installées ou conservées sur leurs systèmes d’information, et elles configurent les ressources de leurs systèmes d’information de manière sécurisée en s’appuyant sur les recommandations de l’autorité nationale de sécurité des systèmes d’information, de l’éditeur de la fonctionnalité ou du fabricant de la ressource..
    Normative force
    obligation (decree, resilience bill)
    Source
    ReCyF — Référentiel Cyber France (NIS 2, transposition nationale)
    Version
    2.5 du 17/03/2026 (version de travail)
    Status
    Working version: not binding until the transposition is enacted
    Official text