What is scan target validation in plain terms?

Scan target validation is the pre-flight discipline that proves, before any scan traffic leaves the platform, that each target on the scan list is owned or authorised by the requester, is reachable in the way the scan plan expects, is not on a platform or regulatory blocklist, and has a recorded authorisation tied to a named human and a timestamp. Validation is not the same as scoping. Scoping decides what should be tested. Validation proves that what was decided to be tested can lawfully and safely be tested, and produces the evidence record that survives an audit, a dispute, or an unauthorised-scanning complaint.

Why is target validation different from scan scoping?

Scoping is a policy decision: which assets fall inside the assurance question and which do not. Validation is an evidence step: each target the scope names has to be proven to belong to the requester, to be reachable for the scan class chosen, to clear blocklist and rate-limit guards, and to carry an authorisation record. Programmes that conflate the two end up with a scope document that nobody can defend at the target level. Auditors, customers in dispute, and abuse complaints do not read the scope statement; they read the per-target evidence trail. The scope sets the question; validation produces the answer the scanner runs against.

What does ownership verification prove and what does it not prove?

Ownership verification proves administrative control of the target at the moment of verification. DNS TXT, HTML meta tag, and file upload checks each demonstrate that the requester can place a marker that only an administrator could place. What ownership verification does not prove is current authorisation to test. A verified domain can change ownership through an acquisition, a registrar transfer, or a hosting change. A verified application can be transferred to a different business unit with a different authoriser. The defensible pattern pairs ownership verification with an authorisation attestation that names a current authoriser, captures the IP and timestamp of the attestation, and is re-signed when the relevant context changes. Without the attestation, ownership verification turns stale.

What is the legal attestation step and why is it separate from verification?

The legal attestation step is a signed declaration by a named individual confirming they have authority to authorise security testing against the listed target, that the testing falls within the scope of their authority, and that the listed target is not subject to a third-party agreement that prohibits scanning. The attestation is captured immutably with the signer identity, the IP, the user agent, and the timestamp. It is separate from verification because verification proves administrative control of an asset and the attestation proves authority to act. A registrar can verify ownership of a domain without having authority to authorise security testing of the application running on it. The two evidence artefacts answer different questions, and an audit trail that carries both is materially stronger than one that carries only verification.

How should target validation handle subdomains, wildcards, and shared infrastructure?

Subdomains inherit the parent verification only when the verification method explicitly covers them. A DNS TXT record on the apex domain does not, on its own, authorise scanning of every subdomain; the validation step needs an explicit subdomain list checked against verification, with the specific subdomains either covered by the parent verification or verified individually. Wildcards are an operating risk: a wildcard inclusion can sweep in dynamically registered tenant subdomains that the requester has no authority over. The defensible pattern is to enumerate the in-scope subdomains explicitly, validate each one, and treat wildcards as a deliberate exception with a documented authorisation. Shared infrastructure (cloud provider control planes, third-party CDNs, payment processors, DNS resolvers) is excluded from validation by platform blocklist, because the requester cannot lawfully authorise testing of infrastructure they do not control.

How does authenticated scan target validation differ from external?

External validation proves that the public-facing target belongs to the requester or has been authorised. Authenticated validation has to prove three additional things. First, that the credentials supplied for the scan are owned by an account inside the in-scope application, with permissions consistent with the assurance question. Second, that the credentials authorise the scanner to exercise the named operations rather than destructive operations the validation has not consented to. Third, that the application owner has authorised the use of those credentials for scanner traffic, which includes test-only accounts, environment isolation where required, and explicit exclusion of payment, deletion, or data export endpoints unless the assurance question demands them. Authenticated validation produces a credential authorisation record that pairs with the ownership and the attestation. Without it, the authenticated scan operates on an evidence base too thin to defend.

What blocklist categories should a target validation step always enforce?

Five categories are non-negotiable on a multi-tenant scanning platform. Government and military domains and TLDs (.gov, .mil, .gov.uk, .mod.uk, equivalents in other jurisdictions). Critical infrastructure (police, NHS, electoral commissions, central banks, regulators, the platforms that name themselves as critical sector). Cloud provider management and control planes (AWS, Azure, Google Cloud, Cloudflare, CDN edge networks) where the requester does not have authority and the platform itself prohibits scanning of its own infrastructure. The scanning vendor own infrastructure (the validation step blocks self-targeting attempts that scan tools sometimes treat as benign). Internet infrastructure (ICANN, IANA, root DNS servers, public certificate transparency logs). Each block has to fail closed: the validation refuses the target with a reason code and the refusal is logged so the request and its denial are part of the audit trail.

When should target validation be re-run rather than treated as one-time?

Five triggers re-open validation. First, the verification record has aged beyond the policy window (typical windows are 90 to 365 days; the record needs a defensible refresh interval). Second, the asset DNS, certificate, or hosting has changed in a way that suggests transfer or ownership change. Third, the workspace owner has changed, the team membership has changed, or the named authoriser on the attestation is no longer with the organisation. Fourth, the scan class has expanded since the last attestation (an authenticated scan added on top of a previously external-only authorisation requires a new attestation that covers credentials and authenticated paths). Fifth, the regulator or the customer has requested a fresh authorisation as part of a renewed assurance question. Each trigger produces a new validation record rather than appending to the old one, so the chronology of authorisation is reconstructable.

How does a defensible target validation record reconcile to the scan execution?

Each scan execution carries a reference to the validation record that authorised it. Six fields are the minimum: the verified target identifier, the verification method and timestamp, the named authoriser on the attestation, the attestation IP and timestamp, the scan class authorised (external, authenticated, code, configuration), and the per-target authorisation reason. When the validation chain breaks, the scan does not run. When the auditor reads the chain, the path from scan execution to verified ownership to attested authority is one query, not a reconstructed narrative. The discipline is making the evidence travel with the scan record on the same workspace, so the question what authorised this scan has a single defensible answer.

How does SecPortal handle scan target validation and authorisation?

SecPortal validates scan targets at three control points before traffic leaves the platform. Domain ownership verification proves administrative control through DNS TXT records (secportal-verify token), an HTML meta tag, or a file upload at /.well-known on the target. Legal attestation is captured immutably with signer identity, IP, user agent, and timestamp before the first scan against a verified domain. Platform blocklists fail closed against government, military, critical infrastructure, internet infrastructure, cloud provider control planes, and SecPortal own domains, returning the BLOCKLISTED guard code with the request denial logged. The scan-guard layer reconciles each scan request against domain verification, attestation, blocklist, plan limits, and cooldown before allowing the scan worker to dispatch. The activity log records every state change with timestamp and acting user, and the workspace holds the validation record alongside the scan execution so the chain from scan to authorisation is one record.

← Back to Scanner Information

Scanner guide16 min read

Scan Target Validation and Authorization: A Production Guide

Validation is not the same as scoping. Scoping decides which assets fall inside the assurance question. Validation proves, before any scan traffic leaves the platform, that each target on the list is owned or authorised by the requester, is reachable for the scan class chosen, clears the blocklist, and carries an authorisation record tied to a named human and a timestamp. Programmes that conflate the two end up with a scope document nobody can defend at the target level when an auditor, a customer, or an abuse complaint asks the question that actually matters.

This guide covers what target validation is, how it differs from scoping, the three control points a defensible validation chain enforces (verification, attestation, and blocklist), how validation handles subdomains and authenticated scans, when validation has to be re-run, and how internal security, AppSec, vulnerability management, and provider workspaces operate target validation as a continuous discipline rather than as a one-time onboarding step.

Validation and scoping answer different questions

Most scanning platforms collapse target validation into the scoping conversation, and the audit evidence collapses with it. The two questions are not the same.

Step	Question it answers	Evidence produced
Scoping	Which assets belong inside the assurance question and which do not?	A scope document with inclusion list, exclusion list, scan classes, depth, and rationale.
Validation	Can the scope decision lawfully and safely be executed against each target?	A per-target validation record: ownership proof, authorisation attestation, blocklist clearance, and the attribution that ties them to the requester.

The defensible pattern is sequential: scoping decides, validation proves, scanning runs. Each step writes to its own record on the engagement. The scan scoping and target selection guide covers the upstream decision the validation step inherits. This guide picks up where the scope document is finalised and walks through the validation chain that turns the scope into something a scanner can run against without exposure.

The three validation control points

A validation chain that holds up under abuse complaints, customer disputes, and audit scrutiny enforces three control points. Each one fails closed: a missing or invalid artefact at any point stops the scan from running and writes a denial record to the audit trail.

1. Domain ownership verification

The first control point proves administrative control of the target. Three methods cover the common cases: a DNS TXT record placed at the apex (or the relevant subdomain), an HTML meta tag served at the verified URL, and a verification file served from a well-known path. Each method requires the requester to place a marker that only an administrator of the target could place. The verification record carries the method used, the token presented, the timestamp of successful verification, and the requester identity. Verification proves control at the moment of verification; it does not, on its own, prove ongoing authority.

2. Legal attestation of authorisation

The second control point captures a signed declaration by a named individual with authority to authorise security testing. The attestation states that the listed target is owned or controlled by the signer organisation, that the scanning activity falls within the scope of the signer authority, and that the target is not subject to a third-party agreement that prohibits scanning. The attestation is captured immutably with signer identity, IP, user agent, and timestamp before any scan traffic is dispatched. The combination of verification and attestation is what lets the platform answer the question who authorised this scan with one queryable record rather than a reconstructed email thread.

3. Platform blocklist enforcement

The third control point fails closed against categories of target the requester cannot lawfully authorise testing for, regardless of what the verification or the attestation claims. Government and military TLDs, critical infrastructure, cloud provider management and control planes, internet infrastructure, and the scanning platform own infrastructure are blocked at the platform layer. The blocklist is not configurable per workspace because authority to override it does not exist at the customer layer. The denial is logged with a reason code so the attempt and its refusal are part of the audit record.

For the broader operating context the verification record sits inside, the domain verification feature covers the workspace-level mechanics, and the responsible scanning guide covers the rationale behind the verification methods.

Ownership verification: what each method proves

The three verification methods are not interchangeable. Each carries a different evidence weight and a different operational profile, and the validation step records which method produced the verification so the audit reader can interpret the proof.

DNS TXT record

A DNS TXT record at the apex (or specific subdomain) carrying the verification token. DNS TXT verification carries strong evidence weight because the record can only be placed by someone with administrative access to the authoritative DNS zone. It works for the apex domain and for any subdomain whose DNS the same administrator controls. It does not, on its own, authorise wildcard or dynamically-provisioned subdomains.

HTML meta tag

A meta tag served by the target page carrying the verification token. Meta tag verification proves write access to the served HTML at the verified URL at the moment of verification. It is convenient where DNS access is gated behind a separate team but is more easily lost on platform changes (CMS migration, edge caching that strips the tag, header conflicts that move the tag below the fold of the parser). The verification step records the URL the tag was found on so the evidence path is reproducible.

Verification file at /.well-known

A static file served from the /.well-known directory of the target carrying the verification token. File-upload verification follows the IETF /.well-known convention used by Let Encrypt, security.txt, and similar verification flows. It proves write access to the well-known path on the target server at the moment of verification. The file path and content are recorded so the audit reader can reconstruct the proof.

All three methods produce a verification record that pairs with the attestation. The record names the method, the verifier identity, the verification timestamp, and the policy window after which re-verification is required.

Subdomains, wildcards, and shared infrastructure

The most common validation gap is the subdomain that quietly extends beyond the verified surface. A DNS TXT record on the apex domain proves control of the apex zone; it does not, on its own, prove authority to scan a third-party SaaS subdomain that the marketing team configured as a CNAME. The defensible pattern enumerates the in-scope subdomains explicitly and validates each one.

Subdomain enumeration before validation

The validation step expands the scope into a concrete subdomain list using certificate transparency logs, the workspace DNS records, the customer-supplied inventory, and any continuous discovery output. Subdomains that resolve to third-party infrastructure (SaaS vendors, payment processors, CDN edges) are separated from subdomains the requester controls. Each remaining subdomain is validated as an independent target, not as an inherited claim against the parent.

Wildcards as a deliberate exception

Wildcard inclusions look efficient and create the largest validation gaps. A wildcard can sweep dynamically-registered tenant subdomains the requester has no authority over. The defensible pattern is to refuse wildcards by default, allow them only as a documented exception with a named authoriser and an explicit acknowledgement that the authoriser accepts responsibility for any tenant subdomain that resolves under the wildcard, and re-validate the wildcard on a shorter cadence than other inclusions.

Shared infrastructure stays out of validation

Cloud provider management and control planes, third-party CDNs, payment processors, DNS resolvers, and logging vendors are not the requester to validate. The requester does not have authority over infrastructure they do not control, regardless of whether the application traffic transits the infrastructure. The platform blocklist enforces this category separately from the workspace verification step so a requester cannot accidentally authorise scanning of a cloud provider control plane through a verification record on an application subdomain.

Authenticated scan target validation

Authenticated scans need three additional validation steps on top of the external chain. Each one produces an evidence artefact that pairs with the verification and the attestation.

Credential ownership and authority

The credential supplied for the authenticated scan has to belong to an account inside the in-scope application, with permissions consistent with the assurance question. A workspace administrator credential supplied for a scope that targets the unauthenticated marketing site fails the authority check. A test account provisioned outside the in-scope environment fails the credential ownership check. The validation step records the credential type, the account scope, and the authoriser who confirmed the credential belongs to the application.

Operation-class authorisation

Authenticated scanners can exercise destructive operations (delete, transfer, payment) if the scan plan authorises them. The validation step makes the operation class explicit. The default position excludes destructive operations, payment endpoints, data export endpoints, and irreversible state changes unless the assurance question demands them. Operation-class authorisation is recorded as a positive list (the operations the scanner may exercise) rather than as a negative list (the operations the scanner must avoid), so the evidence reads as what was permitted rather than what was hoped to be excluded.

Environment isolation where required

Where the assurance question targets a production environment, the validation step records that the application owner has authorised production scanning, that the rate plan and the credential class are appropriate for production, and that rollback paths exist for any state change the scanner could induce. Where the assurance question targets a staging environment, the validation step records the staging environment isolation discipline (data parity with production, separate credential namespace, separate billing path) so the scanner output reads against a defensible reference environment.

The credential record itself is a perishable artefact. The scanner credential rotation and lifecycle guide covers the rotation cadence the credential authorisation has to keep up with.

Blocklist categories that fail closed

Five categories of target are non-negotiable on a multi-tenant scanning platform. The platform refuses each category at the validation layer regardless of what the workspace verification or attestation claims, because the requester cannot lawfully authorise testing of infrastructure they do not control.

Government and military

Domains and TLDs operated by national, state, or local governments and the armed services. Examples include .gov, .mil, .gov.uk, .mod.uk, .police.uk, and equivalents in other jurisdictions. Authorisation to test government and military systems flows through formal procurement and authorisation pathways that do not terminate at a workspace attestation.

Critical infrastructure

Healthcare networks, electoral systems, public-safety services, and other critical-sector platforms whose disruption would cause public harm. The category names the platforms that name themselves as critical and the platforms regulators have designated. The block is precautionary; lawful scanning of critical infrastructure runs through formal sector pathways rather than through a self-attestation flow.

Cloud provider control planes

AWS, Azure, Google Cloud, Cloudflare, and similar provider management and edge infrastructure. The cloud provider terms of service themselves prohibit scanning of provider infrastructure outside narrow vendor-administered programmes. The block separates application traffic (which a requester can authorise where they control the application) from provider infrastructure (which they cannot).

Internet infrastructure

ICANN, IANA, root DNS servers, public certificate transparency logs, and similar shared internet infrastructure. The category captures the operators of the shared substrate of the internet, where any scanning attempt is, by definition, outside the requester authority.

Scanning platform own infrastructure

Self-targeting attempts (scanning the scanning platform domains) are blocked at the validation layer. Some scanner workflows treat the platform as a benign target during configuration testing; the validation step refuses and records the attempt so the operating record reflects the request and its denial.

When validation has to be re-run

Validation is not a one-time onboarding step. Five triggers re-open the chain. Each trigger produces a new validation record rather than appending to the old one, so the chronology of authorisation is reconstructable across the lifecycle.

Verification record age: the verification has aged beyond the policy window. Typical windows are 90 to 365 days. The defensible pattern aligns the window with the broader credential and access review cadence rather than treating verification as permanent.
Asset transfer signal: DNS, certificate issuer, hosting, or registrar has changed in a way that suggests transfer or ownership change. The validation step re-runs verification before the next scan, and the prior record is retained as evidence of the chain transition.
Authoriser change: the named authoriser on the attestation has left the organisation, the team membership has changed, or the workspace owner has been transferred. A new attestation is captured against the current authoriser before the next scan.
Scan-class expansion: an authenticated scan added on top of a previously external-only authorisation requires a new attestation that covers credentials and authenticated paths. The previous external attestation is not silently extended.
Customer or regulator request: a renewed assurance question (audit cycle change, regulator inquiry, customer renewal of authorisation) produces a fresh attestation. The prior attestation remains in the record as part of the chronology.

For the cadence that pairs with re-validation, the scan scheduling and baseline cadence guide covers how scheduled scans interact with the validation window, and the scan evidence retention and governance guide covers how the validation evidence is retained alongside the scan record.

How compliance frameworks read target authorisation evidence

Frameworks read target validation evidence in two places: the technical vulnerability management control (does the programme scan the right targets, with authority) and the access control narrative (did the requester have authority to direct the scan). The expectations below set the floor; programmes justify additional discipline on a risk basis.

PCI DSS v4.0 Requirement 11.3 expects internal and external scans against the in-scope cardholder data environment, with evidence the scope is correct and the scans are authorised. The validation record demonstrates the authorisation side of the requirement, alongside the scan cadence.³
PCI DSS v4.0 Requirement 12.5 expects maintenance of an asset inventory tied to the cardholder data environment. The validation record reconciles the asset inventory to the in-scope target list so the scan output reads against the documented scope.³
ISO 27001:2022 Annex A 8.8 (technical vulnerability management) expects a documented programme. The validation record evidences that scans operate against the right targets with authority, which is the precondition the control depends on.⁵
ISO 27001:2022 Annex A 5.20 (information security in supplier agreements) is read against the validation record when scans run on infrastructure operated by suppliers, so the supplier authorisation chain reconciles to the per-target validation chain.⁴
SOC 2 Trust Services Criterion CC6.1(logical and physical access controls) reads the attestation as evidence the scanner traffic is an authorised activity inside the access control framework rather than an external test.⁶
NIST SP 800-53 RA-5 (vulnerability monitoring and scanning) and CA-2 (control assessments) expect authorisation for the scanning activity as part of the assessment plan. The validation chain is the operational form of the authorisation the control language describes.²

Two legal frames sit underneath the framework expectations. The Computer Fraud and Abuse Act in the United States and the Computer Misuse Act 1990 in the United Kingdom both make unauthorised access an offence regardless of whether the access produces harm. The authorisation attestation is the artefact that distinguishes authorised from unauthorised activity in the operational record.^8,9

Operational checklist for a defensible target validation chain

At workspace onboarding

Each in-scope domain has a verification record with the method, token, and timestamp.
Subdomains in scope are validated explicitly rather than inherited from the apex.
Wildcards are refused by default and recorded as an exception only when justified.
The first attestation is captured before the first scan, with signer identity, IP, and timestamp.
The attestation references the in-scope target list and the authorised scan classes.

Before each scan dispatch

The scan request reconciles to a current verification record for each target.
The scan request reconciles to a current attestation for the scan class requested.
The scan target clears the platform blocklist; denials are logged with the reason code.
Authenticated scans carry a credential authorisation record naming the operations permitted.
Per-target rate limits and cooldowns are checked before dispatch.

During the scan lifecycle

The scan execution record references the validation record that authorised it.
State changes (new finding, suppression, acceptance) carry the actor and timestamp.
Activity log entries bracket each scan with the dispatch and completion records.
Validation re-evaluation triggers (registrar transfer, authoriser change, scan-class expansion) produce new records.
Out-of-scope traffic attempts are denied at the validation layer and surface as alerts rather than as quiet failures.

At audit or dispute

Each scan execution traces in one query to its validation chain.
The verification record carries the method, the verifier, and the verification timestamp.
The attestation record carries signer identity, IP, user agent, and the timestamp.
Blocklist denials are visible alongside successful scans so the operating posture reads as the full record.
Re-validation events are documented as part of the chronology rather than as overwrites.

For internal security, AppSec, and vulnerability management teams

Internal security teams operate target validation as the precondition that makes the rest of the vulnerability programme defensible. The discipline applies whether the scanner is operated in-house, by a managed service, or by a security testing provider running scans against the workspace target list.

Hold verification records per target with the method, the verifier identity, and the verification timestamp.
Capture the attestation against the current authoriser before each material change to the target list or scan class.
Treat wildcards as deliberate exceptions that re-validate on a shorter cadence than other inclusions.
Reconcile the asset inventory to the validated target list so the scope and the validation chain agree.
Wire the validation evidence to the scan execution record so the audit chain is one record, not a reconstructed thread.

For internal security teams, vulnerability management teams, AppSec teams, and GRC and compliance teams, the operating commitment is to keep the chain from scope to validated target to scan execution single-record-traceable. The security testing program management workflow covers where the validation record sits in the broader programme cadence, and the asset ownership mapping for findings workflow covers the reconciliation between the validated target and the finding owner the remediation path depends on.

How SecPortal handles scan target validation and authorisation

SecPortal enforces the validation chain at the platform layer before any scan worker dispatches traffic. The evidence travels with the scan record on the same workspace, so the question what authorised this scan resolves in one query.

Domain ownership verification with three methods

The workspace verifies each in-scope domain through a DNS TXT record (with a secportal-verify token), an HTML meta tag, or a verification file under the /.well-known path on the target. The verification record carries the method, the token, the verifier, and the verification timestamp. The domain verification feature covers the workspace-level mechanics.

Legal attestation captured immutably

Before the first scan against a verified domain, the workspace user signs an attestation confirming authorisation for the listed targets. The signing event records the signer identity, the IP, the user agent, and the timestamp. The attestation reference travels with each subsequent scan request so the audit chain pairs verification with attestation.

Platform blocklist that fails closed

Government, military, critical infrastructure, internet infrastructure, cloud provider management and control planes, and SecPortal own domains are blocked at the validation layer. The denial returns a structured guard code (BLOCKLISTED, DOMAIN_NOT_VERIFIED, DOMAIN_EXPIRED, NO_ATTESTATION, COOLDOWN, SCAN_LIMIT, SUBDOMAIN_NOT_ALLOWED, AUTH_NOT_ALLOWED, CREDENTIAL_NOT_FOUND, CREDENTIAL_DOMAIN_MISMATCH) and the request is logged so denials are part of the audit record rather than silent.

Compound scan guard at request time

The platform scan-guard reconciles each scan request against domain verification, attestation, blocklist, plan limits, cooldown, subdomain allowance, authenticated scan eligibility, credential ownership, and credential-to-domain match before the scan worker dispatches. A failure at any check stops the scan and writes the reason code to the activity log.

Activity log records every state change

The activity log captures every verification, attestation, scan request, scan denial, scan completion, and finding state change with timestamp and acting user. CSV export supports audit and dispute review against the workspace record. The activity log feature covers the chain-of-custody record the validation evidence reads against.

Authenticated scan target gating

Authenticated scan targets carry a credential authorisation record alongside the domain verification. Credentials are stored encrypted with AES-256-GCM and associated with a verified domain at registration. A credential mismatch (a credential bound to a different verified domain than the scan request names) fails at the guard layer with CREDENTIAL_DOMAIN_MISMATCH, so the credential and the target stay reconciled. The encrypted credential storage feature covers the credential lifecycle.

For abuse and unauthorised-scanning context, the acceptable use policy covers the platform side of the contract, and the scanner information page covers how the SecPortal scanner identifies itself in target logs.

Related scanner discipline

Target validation pairs with the upstream scoping decision and the downstream scan-evidence record. The pages below cover the surrounding decisions.

Scan scoping and target selection covers the upstream decision validation inherits.
Scanner coverage and limits covers what each scanner class can reach so the validation chain matches the scan plan.
Scanner authentication failure modes covers how authenticated validation fails operationally and how to read the diagnostic signal.
Scanner credential rotation and lifecycle covers the credential lifecycle the authorisation chain depends on.
Scan evidence retention and governance covers how the validation evidence is retained alongside the scan record.
Scan baseline and trend comparison covers how the trend reads against the validated target list across cycles.
Asset ownership mapping for findings covers the reconciliation between validated target and finding owner.

For wider context on the responsible-scanning rationale, the responsible scanning guide covers the verification methods themselves, and the security tool coverage overlap research covers how validated target lists across overlapping tools reconcile so the audit chain is single-source.

Scope and limitations of this guide

Target validation is a discipline, not a product feature. No verification method on its own confers authority; no attestation on its own proves administrative control; no blocklist on its own substitutes for the requester due diligence on assets they cannot self-validate. The chain is the artefact, not any single step.

Programmes that treat validation as a one-time onboarding event lose the operating evidence between the first scan and the audit window that reads against it. Programmes that treat validation as a continuous discipline, with re-evaluation on material change and a clean record at each step, produce evidence that survives the audit, the customer dispute, and the abuse complaint without manual reconstruction.

Frequently Asked Questions

Sources

Make the chain from target to scan execution single-record traceable

SecPortal verifies each in-scope domain through DNS TXT, meta tag, or file upload, captures the legal attestation immutably with IP and timestamp, fails closed on government, critical infrastructure, cloud provider control planes, and platform own domains, and reconciles each scan request through the compound scan-guard before dispatch so the audit chain is one record rather than a reconstructed thread.

Start free See domain verification