Your EASM sees your website. Not your Siemens controller.
Mainstream EASM platforms are built for cloud and modern web environments. They see your subdomains, your TLS certificates, your misconfigured S3 buckets. They don't see your Modbus exposed on the Internet via a NAT misconfiguration, nor your Niagara Fox on the network of the contractor who maintains your HVAC. For half of Canadian organizations in manufacturing, energy, healthcare, that's exactly half the risk that's invisible.
Three capabilities. One complete external surface.
The scanner nobody else does.
8 industrial protocols. 15 ports. Protocol fingerprinting. Read-only mode systematic.
Three moments. Three uses.
Case 1
Manufacturing OT (controller exposed after maintenance)
1,200-employee manufacturer, 8 sites, Siemens S7 and Allen-Bradley fleet. A contractor intervenes on the Trois-Rivières site PLC. Sets up a temporary VPN for remote access. Forgets to close it on departure. At 48h, the FortaRisks OT scanner detects a Siemens S7-1200 controller accessible from the Internet. Slack alert at 2:22 PM. Confirmation by OT team at 2:45 PM. VPN closed at 3:10 PM. No incident.
Case 2
SaaS B2B (subdomain takeover)
80-employee SaaS publisher, 12 active marketing subdomains. A marketing campaign uses `partner.acme.ca` pointing to a Webflow page. Campaign ends. Webflow page deleted but DNS remains. At 6 hours, FortaRisks detects a possible takeover. Alert. DNS cleaned in 2 hours. Avoids a phishing attack exploiting a legitimate subdomain.
Case 3
Regional bank (DMARC missing vs Loi 25)
Quebec cooperative bank, 600 employees. FortaRisks scan: DMARC at `p=none`, MTA-STS missing, BIMI missing, IP in Spamhaus DNSBL. Email Health score: C. Quantified recommendations: DMARC `p=quarantine` then `p=reject` deployment in 60 days, MTA-STS, DNSBL removal. Score climbs to A in 90 days. Avoids a phishing wave impersonating the brand.
The scanner nobody else does.
EASM is not a silo. All pillars use its signals.
EASM produces real exposure signals. Without them, other pillars work in theory. With them, they decide based on what's actually exposed.
EASM → Posture & Compliance
An expected control (e.g., "TLS 1.2 minimum on all exposed services") can be objectively validated by EASM findings. No more declarative. No more questionnaire. The proof is observed.
EASM → CTI
Each detected exposed service (with its exact version via CPE) is automatically correlated to active CVEs. An Apache HTTP 2.4.49 exposed becomes immediately a critical finding if KEV applies.
EASM → TPRM
The 100+ findings are applied to third-party perimeters. The OT/ICS scanner is applied to industrial suppliers. No additional ingestion cost.
EASM → AI Risk Engine
EASM provides the "actual exposure" component of the risk score. Without EASM, the AI can't distinguish a theoretical risk from a tomorrow-morning exploitable risk.
FAQs
1/ Is the OT/ICS scanner active or passive?
Active read-only mode. Protocol fingerprinting (not banner-only) on the 8 protocols cited §E.5. No writes to controllers, no control commands, no state modifications. Rate limiting adapted to OT networks (default 1 request / 30s per target, configurable up to 1 / 5min). Aligned with NIST CSF 2.0 and IEC 62443-3-3 SR 6.2 for non-intrusive discovery phase. Ability to exclude ultra-sensitive IP ranges.
2/ Does the scan include exposed S3 / Azure Blob buckets?
Yes. Detection of misconfigured cloud buckets (S3, Azure Blob, GCS) is integrated into the System Health pillar with public listing or permissive ACL. Subdomain takeover detection on 83 services includes S3 (Amazon), Azure (Microsoft), GitHub Pages, Netlify, Vercel, Webflow, Statuspage, and 76 others.
3/ How do you guarantee not to scan a third party's assets (collateral damage)?
Three protections. (1) Ownership validation via DNS TXT, HTTP file, or administrative attestation before any scan. (2) Explicit IP range whitelist per tenant. (3) Configurable exclusions: IP, CIDR ranges, FQDN. Every scan first attempts resolution from your validated perimeter. Exportable scan audit trail.
4/ Are findings technically actionable or only informational?
All actionable. Each finding documented with: technical explanation, evidence (HTTP capture, certificate, DNS response, etc.), severity (Critical / High / Medium / Low / Info), step-by-step remediation recommendation, technical references (CVE, RFC, MITRE ATT&CK). Critical findings can be exported as Jira / ServiceNow ITSM tickets (native connectors on Q4 2026 roadmap, REST API available today).