MSP Security Monitoring: What to Track Across Every Customer Tenant

Knowing that a customer has forty endpoints, three servers, and a Microsoft 365 tenant with sixty licensed seats is useful for billing and for operations. It tells you nothing about whether that tenant's Conditional Access policies still match what was configured at onboarding, whether a subdomain from a marketing campaign two years ago is still resolving to a decommissioned host, or whether a certificate on a customer-facing service expires next weekend.

Asset inventory and RMM tooling are built to answer "what exists." Security posture monitoring has to answer "has anything changed for the worse since we last looked," and that is a continuous question, not a one-time count. Treating the two as the same problem is how a customer ends up with an accurate device list and an expired certificate no one was watching.

The rest of this article is about the second question: the four signal types that actually indicate security drift for a managed customer, and why they need to be tracked across a portfolio rather than one tenant at a time.

A tenant configured correctly at onboarding does not stay that way on its own. A Conditional Access policy gets switched to report-only to unblock a user and never gets switched back. A license change removes a security add-on that a Secure Score improvement depended on. An admin adds a "temporary" exclusion during a support call and moves on to the next ticket.

None of these show up unless something is comparing today's configuration against last month's. Secure Score gives you a number; it does not tell you which specific control moved and when. Monitoring means re-running the same identity and configuration checks on a schedule and surfacing the difference as a finding, not waiting for the next scheduled review to notice the policy has been off for six weeks. See Entra ID & Conditional Access review for MSPs for the specific checklist this monitoring is built on.

Everything in the previous section lives inside the Microsoft 365 admin center. None of it covers what sits outside the tenant: the customer's domains, the subdomains that accumulated from old campaigns and vendor integrations, the services that answer on the public internet. That footprint is not in any tenant console, because it is not tenant-scoped — it is internet-scoped.

Two failure modes recur here. A forgotten subdomain still resolves to a service that was decommissioned, which is a subdomain-takeover risk once someone else can claim that service name. Or a port gets opened during a migration and never gets closed — a database engine, a remote-access service, an administrative panel, reachable from anywhere. Neither shows up in an asset list, because no one added them to it; they were discovered, not declared. Full coverage of what discovery should check is in External attack surface monitoring.

Certificate expiry gets treated as a calendar problem, and it is one — an expired certificate breaks a customer-facing service outright, in a way that is entirely predictable and entirely avoidable. But certificates carry a second, less obvious signal. Certificate Transparency logs record every certificate issued for a domain, including ones no one on your team requested.

A certificate you did not issue, for a subdomain you did not know existed, is exactly the kind of undocumented change that asset inventory misses by design — it was never entered anywhere to be tracked. Rolling certificate expiry and issuance up across a whole portfolio, with tiered warnings ahead of the actual deadline, turns a once-a-quarter scramble into a scheduled renewal.

A new CVE affecting software you have detected on a customer's external assets is a security-drift event in the same sense as a disabled Conditional Access policy: nothing on the customer's side changed, but their exposure did, the moment the vulnerability became public and someone confirmed exploitation. Tracking this across a portfolio means correlating what CVEs are actively exploited or trending toward exploitation against what technology each customer is actually running — not chasing every CVSS score that gets published.

That correlation and triage order — matching CISA KEV and EPSS against detected technology, not treating every critical CVSS score as equally urgent — is covered in CVE prioritization: NVD vs CISA KEV vs EPSS. The result belongs in the same queue as everything else here, ranked with the same severity language, not in a separate spreadsheet someone checks when they remember to.

Every check described above can be done by hand, in the native Microsoft 365 admin center, one tenant at a time. That works for one customer. It stops working the moment you manage twenty, because the admin center was built for an organization managing itself, not for a technician context-switching between twenty separate tenants, each with its own login, its own baseline, and no shared view across them.

The cost is not just time. Without a shared severity language across customers, a critical finding in tenant twelve looks the same on a technician's screen as a minor one in tenant three, because there is no portfolio view ranking them against each other. Findings get triaged by whoever happens to be logged into that tenant that day, not by actual severity across the book of business.

The same problem repeats for the external attack surface and CVE tracking: each is a separate tool, a separate login, and a separate mental model, multiplied by every customer. A portfolio-wide workspace is not a convenience feature here — it is the only way the four signal types above stay checked consistently instead of depending on someone remembering to log into the right console. See Microsoft 365 monitoring for how the tenant side of this runs on a schedule across a portfolio.

Tenant drift, external exposure, certificate status, and CVE exposure are four different data sources with four different native homes. Treated separately, each one needs its own review cadence, its own login, and its own definition of "urgent," and coverage quietly narrows to whichever one someone remembers to check.

SecurityScore.me runs all four checks per customer workspace on a schedule and raises what changed as severity-ranked findings in one queue, so a critical CVE exposure and a disabled Conditional Access policy are directly comparable instead of living in separate tools. See the MSP security platform overview for how customer workspaces, findings, and reporting fit together across a portfolio.