Cloud Detection and Response (CDR) Explained

Updated: October 2026

Your clients' data sits in Microsoft 365, AWS and a dozen SaaS apps, and the antivirus on their laptops sees none of it. Attackers know that, so they sign in with a stolen token instead of dropping malware. Cloud detection and response (CDR) is the layer built to catch that activity, and this guide covers what it watches, how it differs from CSPM, XDR and SIEM, and when a small team needs it.

What Cloud Detection and Response Means

CDR watches the activity inside your cloud accounts and responds when something looks malicious. The activity is logins, permission changes, API calls, file sharing and workload behavior. The response is a small action: revoke a session, disable a key, isolate a workload, open a ticket.

It exists because the work moved. The State of BCDR Report 2025, as cited by Kaseya, found that over 50% of workloads now run in public cloud, with 61% expected within two years. An EDR agent sits on a laptop or a server. It can't see a mailbox rule created through an API, or an access key minted in an AWS account nobody has opened for months.

CrowdStrike's April 2026 explainer lists the traits that break the old model: resources are ephemeral, identities and permissions drive access, infrastructure is API-driven, and activity spans several accounts and providers. Detection has to follow the identity, not the device. Wiz's CloudSec Shorts video draws the idea in a couple of minutes.

What CDR Sees That EDR Can't

Take a plain account takeover. An attacker phishes a token, signs in from a new country, registers an authenticator, grants an OAuth app access to mail, adds a forwarding rule and exports the mailbox. Kaseya's CDR guide lists the same toolkit: OAuth permission abuse, exposed shared links, repeated MFA prompts and stolen credentials.

Every one of those steps happens in the cloud. No file lands on a disk, so endpoint tools stay quiet. CDR reads the cloud's own audit trail instead: Entra ID sign-in logs, the Microsoft 365 audit log, AWS CloudTrail and Google Workspace audit logs. It compares each event to that user's normal behavior and chains related events into one incident.

The same logic covers infrastructure. A compromised server in AWS or Azure shows up as a new access key, a storage bucket flipped to public, a spike in outbound traffic or a process nobody deployed. Those workloads can be short-lived, so a scheduled scan misses them. CDR collects runtime signals while they exist and keeps the history for the investigation afterward.

CDR vs CSPM vs XDR vs SIEM

Four acronyms, four questions. CSPM (cloud security posture management) asks whether the configuration is safe: a public storage bucket, an admin without MFA. It's a checkup before anything happens, and our security posture assessment guide covers how to run one. CDR asks whether someone is abusing the cloud right now. CSPM finds the unlocked door. CDR sees who walked through it.

XDR correlates detections across endpoints, network, email and cloud. CDR can feed an XDR platform, or stand alone when the cloud is where your clients live. Our EDR vs XDR comparison covers the endpoint half of that split.

A SIEM collects logs from everywhere and lets you search and alert on them. It stores the evidence, and CDR interprets the cloud slice of it. The SIEM guide explains how that collection works. You'll also see CNAPP, a platform that bundles CSPM, workload protection and often CDR into one product.

What a Good Detection Looks Like

Five detections are worth switching on first:

• Inbox forwarding rules. A new rule that sends mail to an outside address is a classic move after a takeover.
• New OAuth app consent. An app asking for mail or file access that nobody approved.
• MFA method changes. A new authenticator registered right after a login from somewhere new.
• Audit logging turned off. Disabling CloudTrail or a tenant's audit log is someone hiding.
• Access keys on idle accounts. New keys on a service user, or any use of the AWS root account.

A detection that fires is only half the job. In an October 2025 r/msp thread, an owner described the management overhead of a SaaS alerting tool and asked about moving to a managed ITDR service. The replies split between noise complaints and praise for tools that stayed quiet until something happened.

The yardstick is how many alerts a technician reads before the one that matters. Wiz says SOC teams spend an average of 32% of their time on false incident investigations, which is the cost of an untuned queue. Our alert fatigue guide covers how to cut it.

Why Response Speed Decides the Outcome

Detection without a response plan is a notification. One r/msp poster in December 2025 argued that several ITDR products take 5 to 15 minutes to contain a threat, and that an attacker can set up persistence and dump mailboxes in that window. Treat that as one practitioner's measurement, and test your own tool the same way.

The fix is deciding the response before the alert. Sort actions into three tiers. Automatic: revoke sessions and block the sign-in. Approve first: disable the account or isolate a workload. Never automatic: delete anything. Write the tiers down with the client, so a technician at 2am isn't waiting on a phone call to act.

The scenario below is illustrative, and the gap it shows is the argument for pre-approved actions. Your incident response plan should name who owns the rest, and our incident response guide has a template.

Do You Need CDR, and Where to Start

Start with what the platforms already include. Entra ID Protection raises risk detections on sign-ins (some need an Entra ID P2 license), Microsoft Defender for Cloud Apps watches SaaS activity, Amazon GuardDuty analyzes AWS logs, and Google Workspace has an alert center. None of them are called CDR on the box, and together they cover much of the ground.

Before any of that, turn on the logs and keep them long enough to investigate. Our log management guide covers retention, and cloud monitoring tools covers the uptime and cost side so security alerts don't land in the same pile.

Then ask who reads the queue. If nobody watches it overnight, a managed service closes that gap, and our MDR explainer shows what to expect from one. OpenFrame, the open, AI-native infrastructure layer for IT and security, handles device inventory and scripts across a client's fleet. It doesn't do cloud detection, so pair it with one of the options above.

Cloud Detection and Response in Short

CDR is detection and response for the places EDR can't see: identities, SaaS tenants, cloud APIs and workloads. CSPM checks the setup, CDR watches the activity, XDR stitches domains together and a SIEM keeps the records. Turn on logs, switch on the five detections, write down who can act at 2am, and add a managed service if nobody is awake to read the queue.