Monitoring and Alerts

External Attack Surface Monitoring: Subdomains, Open Ports & Certificate Expiry

Microsoft 365 posture management tells you a lot about a customer's identity, email, and endpoints. It tells you nothing about the marketing site a contractor spun up two years ago, the database port left open after a migration, or the TLS certificate that expires on a Saturday. That customer-facing infrastructure is part of the attack surface you are accountable for, and it lives outside the tenant.

The blind spot outside the tenant

A Microsoft 365 assessment is scoped to the tenant: Secure Score, Conditional Access, Defender, identity signals. That work is valuable, but it is bounded. The externally reachable footprint — domains, subdomains, web applications, exposed services, certificates — is where opportunistic attackers look first, because it requires no credentials and no phishing.

MSPs inherit this footprint at onboarding without an inventory. The customer often cannot tell you every subdomain that exists, every host that answers on the public internet, or every certificate that has been issued for their domains. If it is not written down, it is not being monitored, and if it is not being monitored it is not in your customer reports.

The gap tends to widen over time. Marketing engages an agency, a developer stands up a demo environment, a supplier is given a CNAME on the customer domain. None of that reaches your change process, and none of it is captured in a Microsoft 365 assessment. Discovery is the mechanism that closes the gap without relying on the customer to remember.

Subdomains you forgot you had

Subdomains accumulate: staging sites, campaign microsites, vendor-hosted portals, old application hostnames pointed at cloud services. Two risks follow. First, a forgotten subdomain running outdated software is an entry point no one is patching. Second, subdomain takeover: a DNS record still points at a de-provisioned cloud service that an attacker can re-register and control.

Discovery should be passive and continuous. Certificate Transparency logs and DNS enumeration surface hostnames the customer never listed. New subdomains appearing between reviews are worth a look on their own, because they usually mean a change you were not told about.

Exposed services and open ports

Beyond the website on port 443, customer infrastructure sometimes answers on ports that should never face the internet: remote desktop, database engines, file shares, administrative panels, debug endpoints. These are almost always accidental — a firewall rule added during a migration, a cloud security group left broad, a device given a public address.

Monitoring here should be connect-only: confirm what is reachable, do not attempt to exploit it. The finding is "this port is open to the world," and the remediation is a firewall change rather than a patch. Web-application exposure belongs in the same category: exposed source-control or environment files, publicly listed directories, backup archives, and reachable staging environments.

Run this on a schedule, not once. Exposure appears the day a rule changes and disappears the day it is corrected, so a quarterly manual check will miss most of it. A scheduled scan that compares against the last run turns "a port opened this week" into a finding while the change is still fresh in someone's memory.

Certificate expiry

An expired TLS certificate breaks the site or service for every user and erodes customer trust in your management. Expiry is entirely predictable and entirely preventable, yet it still happens, because no one owns the calendar across every customer domain and every subdomain — including the ones discovery has just found.

Monitoring should roll expiry up across the whole portfolio with tiered warnings: a comfortable lead time first, then an urgent one, so renewals are scheduled rather than scrambled. Certificate Transparency also shows certificates you did not expect. A certificate issued for a customer domain on a host you do not manage is worth understanding.

What automatic discovery should cover

A discovery and monitoring pass on a customer's external footprint should account for all of the following, then re-run on a schedule so changes surface as findings:

  • Domains and their DNS configuration, including records, DNSSEC, MX, and CAA.
  • Email authentication depth: SPF, DMARC, DKIM, and related controls.
  • Passive subdomain and asset discovery from Certificate Transparency and DNS.
  • Subdomain-takeover detection on dangling records.
  • Reachable non-web services and open ports, checked connect-only.
  • Web-application exposure: exposed source control, environment files, backups, directory listing, and administrative panels.
  • A certificate inventory and an expiry rollup with tiered alerts.

How this complements M365 posture management

External attack surface monitoring does not replace tenant posture work. A customer with a clean external footprint can still have weak Conditional Access, and a customer with a hardened tenant can still be leaking a database port. The two are complementary halves of the same review, and neither one tells you the state of the other.

Practically, that means one cadence and one queue. If the tenant assessment runs monthly, the external scan should run at least as often, and the findings from both should carry the same severity labels so your team is not switching between two mental models. When a customer asks "are we secure," the answer they expect covers the website and the certificates as much as the identity configuration.

Run them in the same customer workspace, rank findings in the same severity language, and report them together. SecurityScore.me registers customer domains and websites as monitored assets alongside the Microsoft 365 tenant — see domain and website monitoring — so external findings and tenant findings land in one queue. For how this fits multi-customer operations, see the MSP security platform overview.

Frequently asked questions

Learn more

Bring the external attack surface into your customer reviews