A stolen session token does not trip your firewall, does not land on an endpoint, and does not ask for a second factor. It just logs in as someone you trust. We watch the sign-ins, the tokens, the mailbox rules and the app permissions across Microsoft 365 and Google Workspace, and we shut the account down before it becomes an incident.
Identity threat detection and response, or ITDR, is the continuous monitoring of your identity provider for signs that an account has been taken over: stolen session tokens, multi-factor bypass, malicious mailbox rules, unauthorised application consents and privilege changes. It watches how accounts are being used, and contains the ones being abused.
Cyberwall delivers ITDR as a managed service across Microsoft 365 and Google Workspace, monitored by the same 24/7 Security Operations Centre that runs your detection and response.
Your identity provider records everything that happens to an account. Almost nobody reads those logs until after something has gone wrong. We read them continuously, and we act on what they show.
An attacker who steals a valid session cookie is already past MFA. The token carries proof that the second factor was satisfied, so nothing prompts again. We watch for the signature of a replayed session: the same account appearing from a new device fingerprint, a new network, or two locations that cannot both be true, mid-session rather than at sign-in.
Response: revoke every active session and token for that account, not just the password.
Repeated push prompts until someone taps approve to make it stop. A new authenticator registered at 3 a.m. with no help desk ticket behind it. A user quietly moved from an app-based factor back to SMS. Legacy protocols that never supported MFA still accepting logins. Each is visible in the audit log the day it happens, and each is an account takeover in progress.
The first thing an intruder does in a mailbox is make sure you do not notice. A rule that forwards everything to an outside address. A rule that deletes replies containing the word invoice, so the finance thread only has one participant. A delegate or send-as permission granted to an account nobody recognises. We flag new and modified rules, external forwarding, and delegation changes as they are created, on Exchange Online and on Gmail.
This is the one that survives a password reset. A user approves an OAuth consent prompt, often a free PDF tool or a fake document viewer, and grants a third-party application standing permission to read mail and files. The attacker never needs the password again, and resetting it changes nothing. We watch new app registrations and consent grants, flag the ones requesting more than their function requires, and revoke the grant rather than just the credential.
A new global or super administrator. A conditional access or context-aware access policy loosened during a project and never restored. A break-glass account used outside an emergency. A dormant admin account active again after months of nothing. These are the changes that turn one compromised mailbox into tenant-wide access, and they rarely come with a ticket.
Offboarded staff still licensed and still able to sign in. Shared mailboxes with a password on them. Service accounts and integrations with no second factor and no expiry. We inventory them, tell you which ones are reachable from the internet today, and keep the list current instead of producing it once at onboarding.
Every one of these is a sign-in, not a break-in. Your firewall, your endpoint agent and your email filter are all looking somewhere else when it happens.
These three get confused constantly, usually by vendors who sell only one of them. They answer different questions and most organisations end up running all three.
| ITDR | MDR | SIEM | |
|---|---|---|---|
| What it watches | Your identity provider: sign-ins, tokens, app consents, mailbox rules, privilege changes | Your endpoints and network: processes, files, lateral movement | Everything that produces a log, collected and correlated |
| The attack it catches | An attacker signing in with a valid credential or a stolen token | An attacker running something on a device you manage | Patterns that only appear when sources are compared |
| When you need it | Your people work in Microsoft 365 or Google Workspace | You manage laptops and servers | An auditor asks for retention, or an investigation needs history |
| What it produces | A locked account and a revoked session | A contained device | An evidence trail |
At Cyberwall all three run through the same Security Operations Centre, so a compromised account and the device it reaches land in one investigation rather than three tickets.
An identity alert is only worth what happens next. Ours goes to the same 24/7 SOC analysts who handle the rest of your environment, and they act rather than forward:
If what we find is bigger than one account, it escalates into our incident response process, with a triage callback, active engagement inside the hour, and a fully mobilised team within four.
Containment actions that affect a user's access are agreed with you in advance. You decide during onboarding which we take immediately at 3 a.m. and which wait for a phone call.
Before anything is monitored, we run a configuration and posture assessment of your environment. It is read-only, it has a quick turnaround from the moment access is granted, and it produces a document you can hand to your leadership without translating first.
What comes back:
Most of what turns up is not an attack. It is a policy someone loosened two years ago, an app a departed employee authorised, an admin account belonging to a contractor who finished the project 3 years ago. That is the point: you cannot monitor your way out of a configuration you do not know you have.
The assessment is yours whether or not you go any further with us.
The attacks are identical across both. The words are different, so here is the mapping:
| Microsoft 365 | Google Workspace | |
|---|---|---|
| Sign-in and audit telemetry | Entra ID sign-in and audit logs | Admin console audit and login events |
| Conditional policy | Conditional Access | Context-Aware Access |
| Elevated rights | Global and privileged role assignment | Super admin and delegated admin roles |
| App permissions | Enterprise app registrations and OAuth consent | Marketplace apps and API access grants |
| Mail manipulation | Exchange Online transport and inbox rules, delegation and send-as | Gmail filters, forwarding and delegation |
If you run both, and organisations your size often do, whether from an acquisition or one department that never migrated, both are covered under the same service and appear in the same monthly report.
Read-only connection to your identity provider. No agents, no endpoint installs, nothing for your team to deploy. The posture assessment runs against your live configuration.
Assessment findings reviewed with you. We separate what is an active risk from what is merely untidy, and agree the remediation order. We also agree the containment rules, covering what we do automatically and what needs a call first. The detections begin learning what normal looks like in your organisation, including who travels, who works nights, and which integrations sign in at odd hours.
Tuning. False positives removed, thresholds set against your working patterns, escalation contacts confirmed. Tuning continues through the first weeks of service as the behavioural picture fills in, so expect us to check a few things with you after go-live.
A report showing what was detected, what was contained, how your posture score moved, and what is still outstanding. Written to be forwarded, not decoded.
An identity alert nobody tuned is a pager that goes off until someone turns it off. The tuning period is why ours does not.
Ten years ago an attacker had to get through something: a firewall, a VPN, an unpatched server. Today the fastest route into an organisation your size is a valid credential and a session token, bought or phished, used from a laptop that looks unremarkable. Nothing is exploited. Nothing is installed. There is no malware for an endpoint agent to find, because no malware was used.
An analysis of 661 incident response and managed detection cases put an identity-related root cause behind roughly two-thirds of them.* Whatever the exact figure in your environment, the direction is not in dispute. The account is the attack surface now.
Most organisations we assess have done the obvious things. MFA is on. Endpoint protection is deployed. Email filtering works. And nobody is reading the sign-in logs, nobody noticed the forwarding rule created in March, and nobody can say which applications hold permission to read the company's mail.
That gap is what this service closes.
ITDR stands for identity threat detection and response. It is the practice of monitoring an identity provider such as Microsoft Entra ID or Google Workspace for signs of account takeover, and containing the account when one is found. It sits alongside endpoint detection rather than replacing it.
MFA stops credential stuffing and most password reuse, and it is the single highest-value control you can turn on. It does not stop a stolen session token, because the token already carries proof that MFA was satisfied. It does not stop a user approving a malicious app. And it does not stop push fatigue. MFA raises the floor. ITDR watches what happens above it.
Partly, and it is worth being precise. Business Premium includes Entra ID P1, which covers conditional access and the audit logs everything here depends on. The risk-based detections sit in P2, which is a separate licence. Either way the native tooling generates signals. It does not investigate them, correlate them with your endpoint and email telemetry, or act at 3 a.m. We will tell you exactly what your current licensing already covers as part of the assessment, including where the honest answer is that you do not need us for a particular piece.
MDR watches your endpoints and network for things being run. ITDR watches your identity provider for things being signed into. They overlap at the point where a compromised account is used to reach a device, which is why the same SOC runs both and both land in one investigation rather than two tickets.
No framework names ITDR as a product. What they require is the underlying control. SOC 2 and CMMC both expect monitoring of access and privileged accounts, logging of authentication events, and a defined response when something anomalous appears. ITDR is how those controls get operated rather than merely documented, and the assessment output maps to them directly.
Yes. Sign-ins, admin activity, Marketplace app grants, Gmail forwarding and filters, and delegation are all covered, and appear in the same monthly report as any Microsoft tenants you run.
Renewal questionnaires now commonly ask about multi-factor coverage including service accounts, administrator inventory, and authentication logging and retention. The assessment output maps to those questions directly. We coordinate with your carrier and provide the documentation they ask for. We are not on carrier panels and we do not place coverage.
Our analysts investigate it then, not in the morning. If it is confirmed, we contain it inside the rules you set during onboarding and you get a written account of what happened and what was done. If it is bigger than one account, it becomes an incident response engagement.
Most IT teams do not, and finding out takes a read-only connection and a quick turnaround. Start with the assessment, or book a preparedness call and we will walk through what your current licensing already covers.
* Sophos analysis of 661 incident response and managed detection and response cases.