Product documentation
EightScope examines the internet-facing systems connected to a domain you control. It works from the public internet, without internal network access or customer credentials, to identify exposed services, weak configurations, unexpected assets and changes over time.
EightScope is designed to provide a clear view of externally observable risk. It combines attack-surface discovery, security checks, prioritised findings and repeatable monitoring in one place.
Before a production scan can run, the domain must be added to the customer’s organisation and ownership must be verified using a DNS TXT record.
Scanning is restricted to:
EightScope does not allow customers to use the platform as a general-purpose scanner for unrelated third-party targets.
Before contacting a hostname, EightScope resolves its DNS records and checks the returned addresses.
Scanning is blocked when a hostname resolves to:
This helps prevent the scanner from being used to reach internal services, cloud metadata endpoints or other unsafe destinations.
If a redirect leaves the verified domain’s scope, EightScope does not continue assessing the external destination as though it belonged to the customer.
EightScope focuses on externally observable configuration and exposure. It does not attempt to damage systems, bypass authentication, brute-force passwords or exploit discovered vulnerabilities.
Some deeper checks, particularly full TCP port scanning, can still trigger firewall, hosting or security-monitoring alerts. Customers should run these checks only against systems they are authorised to assess.
Verify the domain
The customer adds a domain and proves control using a DNS TXT record. This establishes the permitted scan boundary.
Discover internet-facing assets
Depending on the selected scan type, EightScope uses public certificate data, DNS-based discovery and other external signals to identify hostnames connected to the verified domain. Discovery is not the same as a completed security assessment. A hostname can be discovered without being selected for every scan module.
Build the asset inventory
Each in-scope hostname receives its own asset record. EightScope records information such as hostname, resolved public IP addresses, discovery source, HTTP and HTTPS reachability, CDN indicators, TLS assessment status, HTTP-header assessment status, and reasons a check was skipped or blocked.
Select assets for applicable checks
Some checks can run against every relevant result, while other checks are limited to a selected set of hosts so scans remain safe, timely and predictable. Selection is deterministic and prioritises useful targets such as reachable web services, the www hostname and security-sensitive names such as admin, login, vpn, api, staging, mail and similar services.
Run the selected security modules
The selected scan type determines which modules run. Checks collect external evidence and produce structured findings with affected asset, check name, status, severity, confidence, evidence, explanation and recommended remediation.
Score and compare the results
EightScope calculates the posture score from open findings and compares completed scans only when the coverage is suitable for comparison. A deeper scan may produce a lower score simply because it assessed more of the attack surface. That does not always mean the organisation became less secure.
Module counts stay aligned with the product so this page reflects what customers can run today.
7 modules · ~30 seconds
A fast external preview of the verified root domain. Quick scans cover core DNS, TLS, HTTP-header and web-exposure checks.
15 modules · ~2 minutes
The recommended baseline for regular posture monitoring. Standard scans combine core security checks with subdomain discovery, common-port assessment and broader external coverage while excluding the slowest modules.
26 modules · ~5 minutes
The broadest EightScope assessment. Full scans run every available external security module, including deeper discovery and higher-cost checks.
A deep port scan checks all 65,535 TCP ports and requires the relevant option and customer consent. When a normal port scan runs, EightScope also performs limited UDP checks for ports 53, 123 and 161. UDP coverage is not exhaustive.
EightScope may assess
DKIM discovery checks common selectors. An organisation may use a valid custom selector that EightScope does not discover.
EightScope may assess
EightScope may assess
EightScope may assess
An open port is not automatically a vulnerability. Its severity depends on the service, exposure, configuration and available evidence.
EightScope may assess
Secret detection is pattern-based. A matching value may be a real credential, a test value or a false positive and should be validated before action is taken.
EightScope may assess
When a provider integration is unavailable, the result must be shown as not assessed rather than passed.
EightScope maps relevant findings to externally observable Essential Eight risk indicators.
This mapping is provided to help customers organise risk. Many Essential Eight controls cannot be reliably assessed from the public internet, including internal application control, patch-management processes, administrative privileges, MFA coverage, backup practices and internal Microsoft Office settings.
The mapping is not an Essential Eight maturity assessment or compliance certification.
Discovery does not equal assessment.
EightScope lists the hostnames it discovers, but not every discovered hostname receives every security check during a single scan.
DNS resolution is attempted for discovered in-scope hostnames. Hostnames that do not resolve, return unsafe addresses or produce lookup errors are kept in the inventory with an appropriate status.
Reachability probing is capped and prioritised. A hostname that was not probed must be shown as not probed, not as unreachable or secure.
For Standard and Full scans, EightScope assesses:
For Quick scans, TLS and HTTP headers are assessed on the verified root domain only.
For non-root hostnames, reachable HTTP or HTTPS services are prioritised. Within those groups, www and security-sensitive hostnames receive higher priority, followed by deterministic hostname ordering.
TLS and HTTP headers are assessed separately for each hostname using the hostname’s own TLS SNI and HTTP Host identity.
Two hostnames are not treated as equivalent merely because they use:
This matters because different hostnames on shared infrastructure can present different certificates, redirects, headers, applications and security configurations.
Assessed
The module completed meaningful checks against the asset.
Not assessed
The asset was discovered but the module did not run or was outside the applicable scan limit.
Not probed
The asset was discovered but was not selected for an HTTP or HTTPS reachability probe.
Blocked for safety
The hostname resolved to a non-public or otherwise unsafe destination.
Assessment error
The check began but could not complete because of a timeout, connection problem or scanner error.
Inconclusive
The scan collected some evidence but could not make a reliable pass or fail decision.
None of these incomplete states should be interpreted as confirmation that an asset is secure.
| Status | Meaning |
|---|---|
| Pass | The tested condition met the check’s requirements at the time of the scan. |
| Fail | Evidence indicates a security issue or unsafe condition. |
| Warning | Evidence indicates a weakness, concern or condition requiring review. |
| Inconclusive | There was not enough reliable evidence to make a pass or fail decision. |
| Skipped / not assessed | The check did not run or could not safely complete. |
Only open Fail and Warning findings can reduce the headline posture score. Passed, skipped and inconclusive findings do not reduce it.
| Severity | General meaning |
|---|---|
| Critical | Direct or severe exposure that may enable serious compromise and requires immediate review. |
| High | Material security weakness with significant potential impact. |
| Medium | Meaningful weakness with lower immediate impact or exploitability. |
| Low | Security-hardening or hygiene issue with limited direct impact. |
| Informational | Context that may help investigation but does not directly reduce the score. |
Severity represents EightScope’s assessment of the observed external condition. It is not a complete business-risk calculation because EightScope does not know every asset’s business value, data sensitivity or internal compensating controls.
| Confidence | Meaning | Score treatment |
|---|---|---|
| Confirmed | Direct evidence supports the finding. | Full severity deduction. |
| Likely | Evidence strongly suggests the finding, but manual validation may still be needed. | Half severity deduction, rounded down. |
| Possible | A weak or indirect signal requires validation. | No score deduction. |
Possible findings remain visible so customers can investigate them without allowing uncertain detections to unfairly damage the headline score.
The EightScope posture score starts at 100 and subtracts points for open findings.
| Severity | Confirmed deduction | Likely deduction | Possible deduction |
|---|---|---|---|
| Critical | 12 | 6 | 0 |
| High | 6 | 3 | 0 |
| Medium | 3 | 1 | 0 |
| Low | 1 | 0 | 0 |
| Informational | 0 | 0 | 0 |
Likely deductions are calculated at half weight and rounded down to a whole point. The final score is limited to a range from 0 to 100.
EightScope avoids allowing one repeated configuration problem to overwhelm the headline score.
For host-level configuration checks, such as the same missing security header appearing across many hostnames, only the worst scoring instance from that check family contributes to the headline score.
Every affected hostname remains visible in the findings and asset inventory.
Distinct exposures can still contribute separately when they represent separate security targets, including:
Duplicate cookie-security findings covering the same cookie are collapsed to the worst relevant instance for scoring.
Individual module scores are intended for drill-down and may use module-specific behaviour. They may not exactly match the calculation used for the overall headline score.
| Score | Base grade |
|---|---|
| 90 to 100 | A+ |
| 80 to 89 | A |
| 70 to 79 | B |
| 60 to 69 | C |
| 40 to 59 | D |
| Below 40 | F |
Grade safety rules (ceilings only; never upgrades):
These ceilings prevent a high numeric score from hiding severe findings. They never raise a poor grade.
Optional AI-assisted report wording never changes findings, evidence, severity, priority, score or grade. EightScope remains authoritative for those results.
When enabled, AI may only write an executive summary, rewrite or summarise existing EightScope explanations and remediation guidance for up to eight findings in EightScope's existing priority order, and paraphrase scan limitations. It is not used as an authoritative source for new findings, CVEs, evidence, severity, priority or remediation.
Inputs are allowlisted and sanitised. EightScope does not send the complete scan result, raw evidence, hostnames, email addresses, IP addresses or WHOIS records to the model by design.
Generated output is validated. Output that introduces unsupported claims or structural changes is rejected and is not stored or displayed.
When AI-assisted wording is enabled and a generation runs, processing uses Amazon Bedrock in the Sydney region (ap-southeast-2).
AI-assisted wording is optional and off by default. Opening a saved report or downloading a PDF reads stored ready output only and does not call the model again.
Related disclosures: Trust Centre · Privacy Policy · FAQ
EightScope monitoring runs scheduled batch rescans using the frequency and scan depth available on the customer’s plan and domain settings.
Scheduled monitoring is not real-time or continuous surveillance. Changes that occur between scheduled scans may not be detected until the next scan runs.
Scheduled monitoring scans do not consume the customer’s manual monthly scan credits.
EightScope avoids claiming that a finding was fixed when the later scan did not reassess it.
Finding comparisons require suitable coverage, generally:
For example, a Quick scan must not mark a Full-scan finding as resolved when the Quick scan did not run that module.
Findings are tracked using stable information including:
This allows the platform to distinguish between new findings, ongoing findings, resolved findings, severity changes and asset-specific changes.
When EightScope changes its asset-coverage or finding-identity methodology in a way that would make historical comparisons misleading, the methodology version is changed.
Scans using incompatible methodology or coverage should not be presented as directly comparable without a clear warning.
A lower score does not always mean security became worse. It may also occur because:
The scan comparison should explain these coverage differences wherever possible.
EightScope is one layer of a security program. Important findings should be validated, prioritised using business context and combined with internal security testing where appropriate.