When Microsoft 365 Is Compromised: Building an Independent Crisis Communications Capability

When a major cyberattack compromises Microsoft 365, the immediate concern is usually containment: isolate systems, investigate the attack and restore critical services.

But there is another problem that can emerge just as quickly - how do you communicate when you can no longer trust the systems you normally use to communicate?

If Microsoft Entra ID, Exchange, Teams and other Microsoft 365 services are compromised, email and collaboration tools may not simply be unavailable. They may be actively untrustworthy. An attacker with access to corporate identities could potentially send apparently legitimate messages, access internal information and use familiar channels to influence the response.

That changes the communications requirement.

It is not enough to have another app available when Teams goes down. Organisations need a communications capability whose identity, authentication and communications channels are independent of the systems under attack.

This is where an out-of-band communications platform such as YUDU Sentinel can provide a critical layer of resilience.

When the communications infrastructure itself cannot be trusted

Consider a full-stack Microsoft compromise.

Active Directory and identity stores may be compromised. Exchange may no longer be trustworthy as either an email system or an identity signal. Teams and SharePoint may be unavailable or compromised, while domain-joined devices could be locked, wiped or under attacker control.

Even if Teams continues to work, that does not necessarily make it safe to use.

A working Teams conversation could mean the service has survived the attack. It could also mean the attacker has not disrupted it yet - or has access to the same conversations and identities being used by the response team.

The same applies to email. A message appearing to come from a senior executive or IT administrator may be genuinely authenticated using a compromised corporate account.

The key principle is simple: if a communication channel or identity check depends on the compromised environment, it should be treated as untrusted.

That is fundamentally different from planning for a conventional Microsoft 365 outage.

Why having another communications app isn't enough

Traditional continuity planning often recommends having a backup communication channel.

That is a useful starting point, but it does not solve the whole problem.

During an identity compromise, the question isn't simply: "Can we communicate?"

It is: "Can we trust who is communicating, and can our people trust the instructions they receive?"

An attacker with privileged access may be able to send messages from legitimate accounts, post using legitimate identities and exploit internal terminology, organisational structures and calendars to make malicious instructions appear authentic.

Switching from Teams to another collaboration application may therefore provide availability without providing independence.

A resilient out-of-band communications capability should sit outside the compromised identity and communications stack.

YUDU Sentinel is designed around this principle, providing an independent environment for crisis communications, collaboration and notification rather than relying on Microsoft 365 to remain operational or trustworthy.

What needs to be in place before the incident

An out-of-band communications strategy only works if it has been prepared before the crisis.

There is little value in deciding which platform to use after corporate identity systems have already been compromised.

At a minimum, organisations should establish eight capabilities.

1. Provision the platform independently

The out-of-band platform should not depend on the same identity infrastructure that may be compromised.

Accounts, authentication and access need to remain available even when corporate identity systems cannot be trusted.

With YUDU Sentinel, the crisis communications environment operates independently of the Microsoft 365 stack, providing a separate route into the organisation's crisis communications capability.

2. Maintain an offline contact tree

Keep a current contact tree containing the people, roles and contact information required to activate the response.

It should be available without relying on SharePoint, Exchange or another corporate system that could be inaccessible during an attack.

The contact tree should include the escalation chain and the means of reaching key personnel outside corporate email.

3. Establish identity verification procedures

If normal corporate identity signals cannot be trusted, organisations need another way to establish that someone is who they claim to be.

Pre-agreed verification procedures can provide an additional layer of confidence when joining crisis calls or responding to consequential instructions.

These procedures should be established and tested before an incident rather than invented during one.

4. Define who can activate out-of-band communications

There should be a clearly identified authority responsible for declaring that the organisation is moving to out-of-band communications.

This might be the Incident Commander, CISO or another designated senior role.

The decision should not require a committee meeting during the first critical minutes of an incident.

Define the triggers in advance and make sure the relevant people understand them.

5. Pre-build crisis communication spaces

Do not attempt to design the crisis communications structure while the organisation is under attack.

In YUDU Sentinel, dedicated Sentinel Spaces can be established in advance for different workstreams and audiences, for example:

• Incident Command
• IT and Security Response
• Executive Leadership
• Legal and Regulatory
• All-Staff Communications
• Customer and External Communications

This allows the response to move quickly from activation to coordinated action.

6. Make critical information available independently

Incident response plans, contact information, escalation procedures, holding statements and other critical documents should remain accessible when corporate systems are unavailable.

YUDU Sentinel can provide a secure location for distributing critical documents to authorised users, including information required during an incident.

The objective is straightforward: don't allow the loss of Microsoft 365 to also become the loss of your crisis playbooks.

7. Test access from non-corporate devices

If an attack affects corporate endpoints, staff may need to access crisis communications from phones or other devices.

That access should be tested before an incident.

It is not enough to know that a platform works in normal conditions on a corporate laptop. The organisation needs confidence that the people who need to respond can actually reach the crisis environment when corporate devices and systems are unavailable or untrusted.

8. Exercise the scenario

Finally, test the whole process. A useful exercise should go beyond the familiar scenario of "email is down".

Instead, assume that corporate identity has been compromised and that email, Teams and other Microsoft 365 services cannot be trusted.

• Can the organisation activate its alternative communications capability?
• Can employees find verified instructions?
• Can the executive team establish a trusted crisis room?
• Can IT and security coordinate independently?

And can leadership maintain an auditable record of what was communicated?

Activating the out-of-band response

Once an incident reaches the point where Microsoft 365 identities and communications can no longer be trusted, the organisation needs a simple activation sequence.

Step 1: Identify the trigger

Possible triggers include:

• Confirmed unauthorised access to privileged Microsoft Entra ID roles
• Unauthorised mass credential resets
• Ransomware indicators across endpoints or servers
• Evidence that MFA or other identity controls have been compromised
• Loss of confidence in the integrity of Microsoft 365 identities

Step 2: Activate the crisis communications environment

The designated authority activates the organisation's out-of-band communications capability.

The pre-built crisis structure becomes the operational environment for the response.

Step 3: Notify staff independently

Use out-of-band channels such as SMS, application notifications or voice communications rather than relying on email or Teams.

The initial message should make the change in communication protocol explicit.

For example:

Do not trust instructions received through corporate email or Teams until further notice. Official updates will be issued through the designated crisis communications platform.

Step 4: Establish dedicated response spaces

Incident command, IT/security, executive leadership, legal and other relevant teams can then coordinate in their dedicated environments.

This prevents operational conversations from being mixed with mass staff communications and ensures that sensitive information is shared only with the appropriate audience.

Establishing trust in messages and instructions

Once the normal identity infrastructure is compromised, every consequential instruction deserves greater scrutiny.

A resilient communications process should establish clear rules for verification.

Don't cross-post between trusted and compromised systems

Official crisis communications should not rely on content being forwarded between Teams, email and the out-of-band platform.

If a message originates in a compromised environment, moving it into a trusted environment does not automatically make the message trustworthy.

Verify high-impact instructions

Instructions involving financial transactions, system access, password changes, security controls or other consequential actions should be independently verified.

Use a pre-established contact method rather than simply calling the number included in the potentially malicious message.

Use additional verification for crisis calls

Where identity cannot be established through normal corporate authentication, pre-agreed verification procedures can provide an additional layer of confidence.

Apply dual control

For particularly consequential actions, require confirmation from two authorised individuals using the trusted communications channel.

The principle should be communicated clearly to employees:

If you receive an urgent instruction through corporate email or Teams during the incident, treat it as potentially compromised until it has been verified through the designated out-of-band channel.

Build communications around different audiences

Not everyone needs the same information during a cyber incident. A resilient crisis communications structure should separate audiences and workstreams.

This separation is particularly important during a high-pressure incident. Operational discussions should not overwhelm the communications channel employees rely on for clear instructions.

YUDU Sentinel supports this model through separate Sentinel Spaces, secure messaging, targeted notifications and controlled access to information.

Using YUDU Sentinel during the response

An out-of-band communications platform needs to do more than send a single emergency SMS. The response environment should support the organisation through the different stages of the incident.

Mass notification

YUDU Sentinel can provide an independent route for reaching employees through multiple communication channels, including SMS, email, voice and app-based notifications.

During a Microsoft 365 compromise, the important distinction is that staff notification does not need to depend on the corporate Microsoft identity and collaboration environment.

Sentinel Spaces

Dedicated Spaces allow crisis teams to separate communications by workstream, audience and level of sensitivity.

Incident command can operate separately from the all-staff communications stream, while executive, legal and regulatory teams can have their own controlled environment.

Secure messaging - Chat Channels and PiNG

Crisis teams need somewhere to communicate rapidly without falling back on the compromised collaboration platform.

YUDU supports secure messaging through Chat Channels and PiNG, creating a dedicated space for operational coordination while keeping staff-facing communications clear and controlled.

Video Crisis Rooms

Major incidents often require more than text.

A dedicated video crisis room allows incident leaders and subject-matter experts to meet, coordinate decisions and work through the developing situation without relying on the compromised collaboration environment.

Where appropriate, the resulting record can also support post-incident review and governance.

Critical document access

Crisis communications are only useful if people have access to the information they need.

Incident plans, escalation procedures, contact information, holding statements and other critical documents can be made available through the out-of-band environment rather than relying on SharePoint or other systems that may be unavailable.

Make the communication record part of the incident record

Crisis communications should be treated as an auditable part of the incident response - not an informal conversation happening alongside it.

A useful communications record should capture:

• When a message was issued
• Who issued it
• Who received it
• What information was communicated
• Which approved template or message was used
• Whether delivery was confirmed

This creates an evidence trail that can support post-incident review, governance and regulatory discussions.

It also gives leadership a way to reconstruct what employees were told, when they were told and how the organisation communicated during the most critical stages of the incident.

Don't automatically switch back when Microsoft 365 returns

Recovery presents another potential communications risk.

The fact that Microsoft 365 services are technically available again does not necessarily mean they should immediately become the trusted source of official instructions.

The organisation should define a formal stand-down process.

The all-clear should be issued through the established trusted channel, and the return to normal corporate communications should only happen once IT and security have confirmed that the underlying identity and communications environment has been restored and can be trusted again.

The out-of-band communications record should then be retained as part of the wider incident documentation.

Finally, conduct a communications-specific post-incident review.

Technical response reviews often focus heavily on containment and restoration. But organisations should also ask:

• Did employees know where to get trusted information?
• Did they understand which channels were compromised?
• Could everyone access the alternative communications platform?
• Were executive and operational teams able to coordinate effectively?
• Were important decisions and communications recorded?
• Where did confusion or delays occur?
  
  

The eight things to prepare now

A resilient out-of-band communications strategy should leave the organisation with eight clear capabilities:

1. An independent communications platform that does not rely on the compromised Microsoft identity stack.
2. A current offline contact tree for key personnel and escalation teams.
3. Defined identity verification procedures for crisis communications.
4. A named activation authority with clearly defined activation triggers.
5. Pre-built crisis communication spaces for different teams and audiences.
6. Independent access to critical documents and response information.
7. Tested access from non-corporate devices.
8. Regular exercises that assume full identity and communications compromise.
   
   

The real test of resilience

The real test of a crisis communications strategy is not whether your organisation can communicate when Teams goes down.

It is whether your organisation can communicate with confidence when the systems that normally establish identity and trust have themselves been compromised.

A Microsoft 365 compromise can turn familiar communications channels into potential attack surfaces. In that situation, resilience means having a communications environment that is deliberately separate from the systems under attack - and having the people, processes and procedures to use it immediately.

YUDU Sentinel provides that independent communications layer, giving organisations a dedicated environment for crisis notification, collaboration, secure information sharing and incident coordination when primary systems cannot be relied upon.

When your network goes down, your crisis response doesn't have to.