Your Cloud Counts: Regulators Now Expect It in Inventory and SLAs

Your Cloud Counts: Regulators Now Expect It in Inventory and SLAs

Key takeaway: If it runs your business, on-prem or cloud or hosted by a vendor, it now lives in your inventory, sits under a clock, and must be patched and monitored in days, not weeks.

The scope just expanded

CISA’s new Binding Operational Directive 26-04 does something private-sector operators should read carefully. It pulls in on-premise systems, third-party hosted platforms, and cloud services used by agencies, FedRAMP and non-FedRAMP alike. It mandates continuous monitoring and reporting of asset metadata within 180 days. And it ties patching urgency to two variables that have nothing to do with whose data center the system runs in: internet exposure and the Known Exploited Vulnerabilities catalog. Internet-exposed, known-exploited flaws get a three-day clock. Others get fourteen. BleepingComputer’s write-up of the directive notes it revokes the older BOD 19-02 and BOD 22-01 rules and replaces them with this single, sharper framework.

Translation: regulators are writing down that cloud and vendor systems are assets you must see, measure, and fix on the same clocks as your data center.

Velocity is already past you

Microsoft shipped 206 patches in its June 2026 Patch Tuesday, the largest single update in the program’s 23-year history per CyberScoop. Multiple zero-days were already under active exploitation. That is the productivity stack. Windows, Office, Server, Teams. Uptime and revenue live there. You cannot patch 206 with the same urgency. You triage by exposure, exploitability, and impact. That is exactly how CISA is structuring the clock.

Then the FBI’s IC3 published PSA I-052126 on Kali365, a phishing-as-a-service kit that hijacks Microsoft 365 OAuth device codes to grant attackers Outlook, Teams, and OneDrive access without a password and without completing any additional MFA challenge. The attack bypasses MFA as designed, not by breaking it. The IC3’s own recommended mitigation is to block device code flow in Conditional Access for all users, with limited exceptions. If your tenant policy does not block device code flow today, “we have MFA” does not mean what you think it means.

Why this matters to operators who are not federal

Standard of care bleeds. Fast. When a regulator writes down a time-boxed, risk-based approach, it gives everyone else a yardstick. Insurers and auditors read the same documents. Buyers and diligence teams do too. The bar is shifting from “we patch monthly” to “we patch internet-exposed, known-exploited flaws in days, and we can prove it across our cloud and our vendors.”

Carriers will align questionnaires and claims reviews. Private-equity buyers will drive reps and warranties around inventory and patch SLAs. Customers will push addenda into MSAs. Older, slower practices start to look negligent once a published, exposure-based model is sitting on the table. When something goes wrong, claim denials, regulatory questions, and deal friction follow.

Treat cloud and vendor systems as first-class assets

Not exceptions. Not “owned by IT.” Assets, with owners, with metadata, with clocks.

The honest test is whether you can enumerate every business-critical platform you run, by name, across data center, SaaS, IaaS, and third-party hosting. For each, you should know whether it is internet-exposed and whether it maps to a Known Exploited Vulnerability when advisories hit. When a high-risk, known-exploited issue lands, you should be able to remediate or mitigate in three to seven days and prove it with logs. If you hesitate on any of that, the hesitation is your risk.

Inventory is a feed, not a spreadsheet. For on-prem, EDR and a vulnerability scanner are your data sources. For cloud, pull the APIs: AWS Organizations, Azure Resource Graph, Microsoft 365 Secure Score and Service Health. For SaaS, pull from each platform’s admin API. Capture system name, business owner, technical owner, internet exposure, data classification, MFA state, logging state, and patch or change mechanism.

Vendors are part of the same inventory. I wrote in May that a managed service provider with remote access into forty client networks is more valuable to a ransomware affiliate than a single hardened enterprise. One compromise, forty front doors. The same logic applies to your hosted ERP, your payments platform, your niche IT supplier. The vendor is not the headline. It is the door. Get vulnerability and patch SLAs into the contract. Borrow the CISA clocks: known-exploited internet-facing issues mitigated or patched within three days, others within fourteen, notification when their platform is impacted by a KEV entry, evidence on request.

Identity is the other half

Conditional Access is now the control plane. The Kali365 example is not a one-off. OAuth device-code abuse is the current attacker playbook because it bypasses MFA without breaking it. If you use Microsoft 365, treat phishing-resistant MFA and Conditional Access policies that explicitly block device code flow as non-negotiable for admins and for anyone with access to finance, HR, and intellectual property. Monitor for unusual token consent and OAuth app grants. That is where attackers live when they pivot in cloud.

A common pattern in MFA rollouts is that the admin tier gets skipped. It is easy to focus on the broad user base and leave break-glass and service accounts for later. Later is when claims get denied because the application said MFA was enforced. Fix the admin tier first, prove it, and document the exception process for non-human accounts with compensating controls like certificate-based auth and Privileged Access Workstations.

Proving speed is almost as important as being fast. Diligence, underwriting, and post-incident review will all ask the same question: how long did it take from advisory to mitigation? Time-stamp the KEV entry or MSRC advisory. Time-stamp pilot deployment. Time-stamp broad deployment. Keep the logs. If a vendor is remediating, track their ticket ID and dates. The bar is not perfection. The bar is disciplined response tied to exposure and exploitation.

Two asks this week

Audit one control: Microsoft 365 admin accounts. Today. Confirm with evidence that Conditional Access is enforced for admins with phishing-resistant MFA wherever possible; that device code flow is blocked tenant-wide with a documented exception list; that legacy authentication is blocked; that administrator roles are limited and just-in-time where possible; and that audit and sign-in logs are retained and exported to a SIEM or archive you control. This is the identity backbone. It is the pivot point for Teams, Outlook, and OneDrive. The IC3’s Kali365 advisory lands here. If this tier is weak, attackers move fast and insurers take note.

Schedule one contract conversation: your most critical hosted vendor. The ERP, the practice management system, the payments platform, or the MSP. Ask for their vulnerability management policy and SLAs aligned to CISA’s structure: KEV affecting internet-exposed systems mitigated or patched within three days, critical vulnerabilities on externally reachable services within seven to fourteen, notification to you when their platform is affected by a KEV entry with interim mitigations and expected resolution dates. Ask for evidence proving last quarter’s performance. If they push back, that is a signal. Decide whether to accept, renegotiate, or plan an exit.

These two are enough to start. The inventory build-out, the staffing decisions, the board narrative all follow from doing these well.

Where Corvus comes in

Negotiating patch SLAs into vendor MSAs is a Corvus engagement. So is taking a Microsoft 365 tenant from “we have MFA” to “we block device code flow at the policy layer and we can prove it in diligence.” If either conversation is in front of you, that is the work we do.

You cannot drive speed you cannot see. Build the inventory. Set the clock. Hold the line.

Now, it’s your move.