You can deploy EDR.

You can implement a SIEM.

You can buy advanced email security.

You can enable Microsoft Defender.

You can have vulnerability scanning, backup, mobile security and identity protection.

And still have incidents that should have been prevented or detected earlier.

Why?

Because buying a security product and building an effective security capability are two different things.

A tool can generate an alert.

But someone still needs to know:

Who investigates it?

How quickly?

When is it escalated?

What happens after containment?

Who owns the underlying problem?

That's why I've increasingly come to believe that cybersecurity maturity isn't measured by how many security products an organisation owns.

It's measured by how effectively people, processes and technology work together.

The Expensive Dashboard Problem

Imagine an organisation invests in several security platforms.

The environment now has:

EDR
SIEM
Email security
Identity protection
Vulnerability management
Backup
Cloud security
Mobile security

On paper, that looks mature.

But then I start asking questions.

Who checks the alerts?

Nobody is completely sure.

What happens to a critical alert after hours?

There's no defined process.

How quickly should a high-severity vulnerability be remediated?

There's no agreed SLA.

When should an incident be escalated?

It depends on who sees it.

When were backups last restored and tested?

Nobody remembers.

Suddenly, the number of security products matters much less.

A Detection Without a Response Process Is Just Information

Suppose an EDR detects suspicious behaviour.

The tool has done its job.

It generated an alert.

But imagine the alert sits untouched for two days.

The organisation technically had detection capability.

Operationally, it didn't have effective response capability.

I think about it like this:

Detection
    ↓
Triage
    ↓
Investigation
    ↓
Decision
    ↓
Containment
    ↓
Remediation
    ↓
Recovery
    ↓
Lessons learned

If those steps aren't defined, the technology can only take the organisation so far.

Automation Doesn't Remove Ownership

Modern security products can automate a lot.

They can:

• Block files

• Quarantine threats

• Isolate endpoints

• Correlate alerts

• Remove malicious emails

• Trigger workflows

• Generate incidents

Automation is valuable.

But I don't think automation removes the need for human judgement.

Suppose an EDR automatically blocks malware.

Great.

I still want to know:

How did the malware arrive?

Did anything execute before the block?

Did the user enter credentials somewhere?

Did other endpoints receive the same file?

Was persistence created?

Does the attack expose a larger security weakness?

Automation can perform an action.

An investigation needs to understand the story.

Security Processes Need Clear Ownership

One of the simplest questions I like asking is:

Who owns this?

Imagine a vulnerability scanner identifies a critical vulnerability.

Security identifies the risk.

But who patches it?

Maybe infrastructure.

Maybe the application owner.

Maybe a third-party provider.

Maybe nobody has clearly defined ownership.

Then the vulnerability remains open.

Not because the security tool failed.

Because the process after detection failed.

Vulnerability Management Is a Good Example

Running a vulnerability scan isn't vulnerability management.

A scanner can give you thousands of findings.

The real work begins afterward.

Discover
   ↓
Validate
   ↓
Prioritise
   ↓
Assign owner
   ↓
Remediate
   ↓
Verify
   ↓
Report

Without those stages, an organisation doesn't really have vulnerability management.

It has vulnerability discovery.

Those aren't the same thing.

Severity Alone Isn't Enough

Security products often label findings:

Critical

High

Medium

Low

Those ratings are useful.

But organisations still need context.

Suppose I have two high-severity vulnerabilities.

One affects an internet-facing production system.

The other affects an isolated test machine.

Do I treat them exactly the same?

Probably not.

I want to understand:

Is it exploitable?

Is the system exposed?

What data does it contain?

What privileges could an attacker gain?

Is there active exploitation?

What business service depends on it?

That's where process and analyst judgement turn scanner output into risk management.

The Same Problem Happens With SIEM

An organisation can deploy Microsoft Sentinel or another SIEM and say:

"We now have centralised security monitoring."

But I would ask:

Which logs are actually connected?

Are critical systems represented?

Are analytics rules tuned?

Who investigates incidents?

What is the escalation path?

Are detections tested?

Are false positives being reviewed?

Are playbooks documented?

Because this:

SIEM deployed ✓

doesn't necessarily mean:

Effective security monitoring ✓

More Alerts Can Actually Make Things Worse

Another mistake is believing that more alerts automatically mean better security.

Imagine a SOC receives:

10,000 alerts per month

but most are low-quality or repetitive.

Analysts eventually become overwhelmed.

Important detections can disappear into the noise.

That's alert fatigue.

A better security programme asks:

Which detections provide value?

Which repeatedly generate false positives?

Which alerts should be automated?

Which require immediate escalation?

Which can be tuned?

The goal isn't maximum alerts.

The goal is meaningful detection.

Playbooks Matter

If a suspicious account login happens today and again six months from now, the investigation shouldn't depend entirely on which analyst happens to be working.

That's where incident-response playbooks help.

For a suspected account compromise, for example, a playbook could guide analysts through questions such as:

Validate alert
     ↓
Review authentication
     ↓
Check MFA changes
     ↓
Review mailbox rules
     ↓
Check forwarding
     ↓
Determine affected services
     ↓
Revoke sessions
     ↓
Reset credentials
     ↓
Hunt related indicators
     ↓
Document findings

A playbook doesn't replace analyst judgement.

It creates consistency.

But Playbooks Need Testing Too

Writing a beautiful incident-response document doesn't mean the organisation is ready for an incident.

That's why I like the idea of tabletop exercises.

Take a scenario:

A privileged Microsoft 365 administrator account has been compromised.

Then ask:

Who receives the alert?

Who has authority to disable the account?

What if the attacker changes authentication methods?

How do we revoke sessions?

How do we determine what they accessed?

Who informs management?

What if sensitive information was accessed?

Who handles external communication?

Suddenly, weaknesses in the process become visible without needing a real attacker to expose them first.

Documentation Should Survive the Person Who Wrote It

Another lesson I've learned is that a process shouldn't exist only inside someone's head.

If the only person who knows how to respond to a particular incident is unavailable, that's a security risk.

Processes should be documented clearly enough that another capable person can follow them.

That includes:

• Escalation paths

• Incident procedures

• System ownership

• Contact information

• Security baselines

• Exceptions

• Recovery procedures

• Decision criteria

Good documentation creates operational resilience.

Tools Also Need Maintenance

Security products aren't "set and forget."

Environments change.

Users change.

Applications change.

Attack techniques change.

Business requirements change.

A detection rule that worked two years ago may no longer be useful.

An exclusion created temporarily might still exist.

An administrator account might still have permissions it no longer needs.

An endpoint might stop reporting.

A data connector might fail.

Security controls need continuous validation.

I like asking:

Is the control merely configured, or is it still effective?

Those are different things.

The People Matter Too

Security processes can also fail when they're unrealistic for the people expected to follow them.

For example, a policy might say:

"Users must never use unsanctioned applications."

Fine.

But what if the approved application doesn't allow them to perform an essential part of their job?

People will find another way.

This is why security teams need to understand how people actually work.

The strongest security process isn't necessarily the strictest one.

It's the one that reduces risk and can realistically be followed.

Security Maturity Is About Connections

I've worked across environments involving different endpoint, email, backup, mobile and Microsoft security technologies.

One thing that becomes obvious when working with multiple tools is that security doesn't happen inside one console.

An attack might move through:

EMAIL
   ↓
IDENTITY
   ↓
ENDPOINT
   ↓
CLOUD
   ↓
DATA

Meanwhile, the response might involve:

SOC
 ↓
Endpoint team
 ↓
Identity team
 ↓
Cloud team
 ↓
Management
 ↓
Business owner

Technology needs to connect.

But so do people.

What I Look for Beyond the Tool

When I see a security product in an environment, I increasingly ask five questions.

1. What risk is this tool supposed to reduce?

If we can't answer that, why do we have it?

2. Is it configured properly?

Having a licence isn't the same as having protection.

3. Who owns it?

Someone needs responsibility for maintaining and reviewing it.

4. What happens when it detects something?

There should be a defined operational process.

5. How do we know it's working?

Controls need validation and measurement.

Those questions apply whether I'm looking at EDR, SIEM, email security, vulnerability management, backup or cloud security.

The Bigger Lesson

Security technology is important.

I enjoy working with security tools.

But tools aren't the security programme.

A mature security capability looks more like:

PEOPLE
   +
PROCESS
   +
TECHNOLOGY
   ↓
SECURITY CAPABILITY

Remove one of those and the others become weaker.

Technology without process creates alerts nobody handles.

Process without technology can leave teams without visibility.

Technology and process without capable people can lead to poor decisions.

All three need to work together.

Final Thoughts

When evaluating an organisation's cybersecurity maturity, I wouldn't start by asking:

"How many security products do you have?"

I'd rather ask:

What risks are you trying to manage?

What controls address those risks?

Who owns those controls?

How do you detect when they fail?

What happens when an incident occurs?

How quickly can you respond?

Can you recover?

And how do you know any of this actually works?

Because an expensive security platform with nobody monitoring it is just an expensive dashboard.

The real value comes when technology supports a security process that people understand, own and continuously improve.

It's useful because it gives you a quick indication of security controls that could potentially be improved.

But there's a mistake I think organisations can make:

Treating Secure Score like an exam where the goal is simply to reach 100%.

For me, the real question isn't:

"How do we get the highest possible score?"

It's:

"Which recommendations will meaningfully reduce risk in this environment?"

Because a higher number doesn't automatically mean an organisation is secure.

Here's how I think about using Microsoft Secure Score as part of a broader security-improvement programme.

What Is Microsoft Secure Score?

At a high level, Microsoft Secure Score measures the implementation of recommended security actions across supported Microsoft services.

Depending on the environment, recommendations can relate to areas such as:

• Identity

• Devices

• Applications

• Data

• Microsoft 365 security controls

Think of it as Microsoft saying:

"Based on what we can see in your environment, here are security improvements you should consider."

As controls are implemented, the score can improve.

That makes Secure Score useful.

But it also creates a temptation:

Chase the number.

That's where I think security teams need to be careful.

A Score Isn't the Same as Risk

Imagine two recommendations.

Recommendation A

Implement stronger controls around privileged administrator access.

Recommendation B

Make a lower-impact security configuration improvement affecting a small part of the environment.

Both might increase Secure Score.

But they don't necessarily reduce the same amount of organisational risk.

If I have limited resources, I shouldn't automatically implement whichever recommendation gives me the easiest points.

I should ask:

Which weakness creates the greatest risk?

That's the difference between score optimisation and security improvement.

My First Step: Understand the Current Position

Before changing anything, I want a baseline.

I would review:

Current Secure Score

What is the organisation's current position?

Recommendations

Which improvement actions are outstanding?

Control categories

Where are the biggest gaps?

Existing controls

Which recommendations are already addressed through another control or technology?

Trend

Is the security posture improving or declining?

This gives me a starting point.

But I wouldn't immediately start enabling everything.

Step 2: Prioritise by Risk

This is where the security analyst or engineer needs to add judgement.

I would consider factors such as:

Potential impact
        +
Likelihood
        +
Exposure
        +
Privilege
        +
Data sensitivity
        +
Business context
        ↓
PRIORITY

For example, weaknesses involving privileged identities would normally get my attention quickly.

Why?

Because the blast radius of a privileged account compromise can be significant.

Similarly, an internet-facing workload with a serious security weakness may deserve faster attention than a lower-risk configuration issue on an isolated system.

Identity Would Be High on My List

If I'm assessing a Microsoft environment, identity controls are one of the first areas I would review.

Questions might include:

Is MFA appropriately implemented?

Are legacy authentication methods still creating unnecessary exposure?

Are privileged roles permanently assigned?

Is Conditional Access being used effectively?

Are administrative accounts properly protected?

Is Privileged Identity Management being used where appropriate?

The reason is simple:

If an attacker compromises a powerful identity, many of the other security controls in the environment become much harder to rely on.

Step 3: Understand the Recommendation Before Implementing It

I don't think a security recommendation should become:

Microsoft says enable this, therefore enable it.

I want to understand:

What risk does this recommendation address?

Which users or systems will it affect?

Could it disrupt a business process?

Does the organisation already have an equivalent control?

How will we test it?

How will we roll it back if something goes wrong?

This becomes particularly important with controls affecting authentication or access.

Security improvements that unexpectedly lock legitimate users out of business systems aren't successful implementations.

An Example: Conditional Access

Imagine Secure Score recommends strengthening an identity control.

I wouldn't immediately create a policy and enforce it across the entire organisation.

My process would look more like:

Identify recommendation
        ↓
Understand the risk
        ↓
Review current environment
        ↓
Design the control
        ↓
Identify affected users/apps
        ↓
Test
        ↓
Report-only / pilot where appropriate
        ↓
Review results
        ↓
Enforce
        ↓
Monitor

That takes longer than clicking Enable.

But security engineering isn't supposed to be a competition to see who can change production fastest.

Step 4: Identify Quick Wins

Not every security improvement needs a six-month project.

Sometimes there are controls that:

• Reduce meaningful risk

• Have relatively low operational impact

• Can be implemented safely

• Require limited resources

Those are valuable quick wins.

I like identifying these early because they allow the organisation to improve its security posture while larger remediation projects are still underway.

But I wouldn't confuse:

Easy to implement

with:

Most important.

Sometimes the most important control is also the hardest one.

Step 5: Create a Remediation Roadmap

If an organisation has many recommendations, trying to implement everything simultaneously isn't realistic.

I would rather create a roadmap.

For example:

Immediate

Address critical identity and privileged-access risks.

Short Term

Improve endpoint, email and authentication controls.

Medium Term

Address larger configuration, governance and data-protection gaps.

Long Term

Continue security maturity improvements, automation and optimisation.

Now Secure Score becomes more than a dashboard.

It becomes one input into a security improvement programme.

Step 6: Assign Ownership

One challenge with security recommendations is that the security team doesn't always own the system that needs changing.

A recommendation could require involvement from:

• Identity teams

• Endpoint teams

• Cloud teams

• Messaging teams

• Application owners

• Infrastructure teams

• Compliance teams

• Business stakeholders

So each remediation item should ideally have:

Recommendation
      ↓
Risk
      ↓
Priority
      ↓
Owner
      ↓
Target date
      ↓
Implementation
      ↓
Validation

Without ownership, recommendations can sit on dashboards for months.

Step 7: Measure More Than Secure Score

Secure Score is useful.

But I wouldn't use it as my only security KPI.

Suppose an organisation moves from:

Secure Score: 55%
        ↓
Secure Score: 82%

That looks excellent.

But I still want to know:

Did critical risks actually decrease?

Are privileged accounts better protected?

Are endpoints properly covered?

Are security incidents being detected faster?

How long does remediation take?

Are critical vulnerabilities being addressed?

Are security controls actually working?

These questions tell me whether security maturity is improving.

Security Controls Need Validation

This is another important point.

A control being configured doesn't necessarily mean it's effective.

For example:

An organisation might have MFA.

Great.

But:

Does it cover the right users?

An organisation might have endpoint protection.

Great.

But:

Are all endpoints onboarded and healthy?

An organisation might have Microsoft Sentinel.

Great.

But:

Are the necessary logs connected and detections actually working?

An organisation might have Conditional Access.

Great.

But:

Are there exclusions that undermine the policy?

This is why I think security teams need to move from:

"Is the product enabled?"

to:

"Is the control effective?"

What I Would Present to Leadership

Senior stakeholders don't necessarily need a list of 70 Microsoft recommendations.

I would translate the technical findings into risk.

Instead of saying:

"We have 26 outstanding Secure Score improvement actions."

I would rather communicate something like:

"Our assessment identified several high-priority identity and endpoint gaps. The first remediation phase focuses on privileged access, stronger authentication and endpoint coverage because these controls have the greatest potential impact on account compromise and incident containment."

Now we're talking about business risk, not dashboard points.

Secure Score and Security Frameworks

I also wouldn't allow Secure Score to become the organisation's entire security framework.

Organisations may need to align security controls with frameworks and standards such as:

• CIS Controls

• NIST Cybersecurity Framework

• ISO 27001

• Internal organisational security standards

• Regulatory requirements

Secure Score can support that work.

But it doesn't replace governance, risk management or a proper security programme.

The Senior-Level Question

Earlier in my career, I might have looked at Secure Score and thought:

"How do I increase this number?"

Now I think the better question is:

"Which recommendation should we implement first, why does it matter, what could it affect, and how will we know it actually reduced risk?"

That's a very different conversation.

It moves security from:

Recommendation
      ↓
Enable
      ↓
Points

to:

Risk
      ↓
Prioritisation
      ↓
Control design
      ↓
Testing
      ↓
Implementation
      ↓
Validation
      ↓
Measurement

And that's how I believe Secure Score should be used.

Final Thoughts

Microsoft Secure Score is valuable because it gives security teams visibility into potential improvements.

But the number shouldn't become the objective.

The objective is reducing risk.

If my Secure Score increases because I've implemented meaningful security controls, that's useful.

But if I'm implementing low-value recommendations simply because they generate easy points, I may be improving the dashboard more than I'm improving security.

So when I review Secure Score, I don't ask:

"How quickly can we reach 100%?"

I ask:

"What is our biggest risk today, and which control will make the biggest difference?"

Because ultimately, attackers don't care what percentage is displayed on the dashboard.

They care about the weaknesses that remain.

Security vendors are adding AI assistants to their platforms. Analysts can use AI to help summarise incidents, understand alerts, generate queries and work through large amounts of security data much faster than before.

As someone working in cybersecurity, I find that exciting.

But there is another side to the conversation that I think is just as important:

Defenders aren't the only ones who have access to AI. Attackers do too.

And that changes things.

AI Doesn't Need to Create New Attacks to Be Dangerous

When people talk about AI and cyberattacks, the conversation can quickly become futuristic.

Autonomous hackers. AI-generated malware. Machines attacking organisations without human involvement.

Those possibilities get attention, but I think there is a more immediate concern.

AI can make attacks we already understand faster, cheaper, more scalable and more convincing.

Phishing is a good example.

For years, one piece of security-awareness advice has been to look for things like poor grammar, spelling mistakes and unusual wording.

But what happens when an attacker can generate a professional email in seconds?

They can ask AI to make it:

• More professional

• More urgent

• More convincing

• Specific to an industry

• Written for a particular audience

• Translated naturally into another language

Suddenly, poor grammar isn't such a reliable warning sign anymore.

Social Engineering Can Become More Personal

Social engineering has always been about understanding people.

Attackers take advantage of:

Trust. Urgency. Fear. Authority. Curiosity.

AI doesn't invent those techniques.

What it changes is how easily they can be applied.

Imagine an attacker gathers publicly available information about a company and its employees.

Instead of sending the same generic phishing email to everyone, AI could help create messages that appear relevant to different roles.

Someone in finance receives a payment-related request.

Someone in HR receives something that appears related to employee information.

Someone in IT receives what looks like a technical request.

The attack becomes more convincing because the message fits the person receiving it.

Business Email Compromise Could Become Even More Convincing

Business Email Compromise is another area that concerns me.

BEC attacks often don't require sophisticated malware.

They rely on trust.

An attacker might compromise an email account and observe how people communicate.

Who approves payments?

Which suppliers does the organisation use?

How does the finance team communicate?

How does a manager normally write?

When are invoices normally processed?

AI could potentially make analysing and imitating those communication patterns much easier.

The attack might simply become:

Compromised account → Understand conversation → Generate convincing request → Create urgency → Employee acts

No malware is necessarily required.

And an endpoint security product can't simply quarantine a convincing sentence.

But Defenders Get AI Too

This is why I don't see AI as purely an attacker advantage.

Security teams are gaining powerful capabilities as well.

Think about a security analyst investigating an incident involving:

• Hundreds of authentication events

• Endpoint telemetry

• Email alerts

• Network activity

• Threat intelligence

• Multiple users and devices

Manually connecting all that information takes time.

AI can potentially help analysts summarise information, identify relationships and understand large amounts of telemetry faster.

That can be extremely valuable in a SOC where time matters.

AI Can Help Me Ask Questions Faster

One area where I see real value is investigation assistance.

Suppose I'm investigating suspicious authentication.

I might want to know:

Which users generated multiple failed sign-ins from the same IP address during the last 24 hours?

AI can help generate a starting KQL query:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize
    FailedAttempts=count(),
    TargetedUsers=dcount(UserPrincipalName)
    by IPAddress
| order by FailedAttempts desc

That's useful.

It saves time.

But there is an important distinction.

AI can help me write the query. I still need to understand what the query is doing.

If I don't understand the data, the table or the logic behind the query, I can't reliably determine whether the result actually answers my investigation question.

AI Should Assist My Investigation, Not Become My Investigation

This is probably one of the most important principles for me.

AI can produce answers that sound extremely confident.

That doesn't necessarily mean they're correct.

Imagine an AI assistant analyses an incident and says:

"The authentication activity appears benign."

Would I close the incident immediately?

No.

I would still want to understand the evidence.

What IP address was involved?

What location?

What device?

Was the authentication successful?

What happened immediately before it?

What happened afterward?

Was MFA involved?

Did the user access unusual applications?

Were account settings changed?

Were other users affected?

AI can help me reach the evidence faster.

But AI shouldn't replace the evidence.

The Risk of Trusting AI Too Much

The more capable AI becomes, the easier it becomes to trust it.

And I think that creates an interesting security problem.

If an analyst automatically accepts every AI-generated explanation, query or recommendation, eventually they may stop asking:

Why?

That is dangerous.

Cybersecurity investigations depend on curiosity.

An alert tells me something happened.

My job is to determine what that something actually means.

If AI says:

"This process is suspicious."

I still want to know why.

If AI recommends isolating a device, I want to understand the business impact.

If AI generates a detection rule, I want to understand what behaviour it detects.

If AI writes KQL, I want to understand the query before using its results to make a security decision.

AI should make analysts faster.

It shouldn't make us stop thinking.

AI Also Creates New Security Problems

The AI conversation isn't only about attackers and security products.

Employees are using AI too.

That creates a completely different security challenge.

Imagine someone copies information into a public AI service:

Customer information.

Internal documents.

Source code.

Security configurations.

Incident information.

Financial information.

Maybe they aren't trying to expose company information.

They're simply trying to work faster.

But from a security perspective, I still need to ask:

What information are employees allowed to put into AI systems?

Which AI services has the organisation approved?

How is that information handled?

Do employees understand the difference between public and enterprise AI services?

Can we monitor the use of sensitive information?

This is where AI becomes a data-protection and governance problem.

Shadow AI May Become the New Shadow IT

Security teams have dealt with Shadow IT for years.

Employees find an application that makes their job easier and start using it without going through the organisation's normal approval process.

AI creates something similar.

Shadow AI.

Employees may start using AI services before security teams have:

• Assessed the service

• Understood how data is handled

• Established acceptable-use policies

• Defined which information can be shared

• Implemented enterprise controls

• Provided training

• Established monitoring

The organisation may already be using AI extensively.

Security simply may not know about it yet.

Blocking everything isn't necessarily the answer either.

If AI genuinely improves productivity, employees will want to use it.

The security challenge becomes:

How do we enable AI without losing control of our data?

AI Agents Make Identity Security Even More Interesting

AI agents take the conversation another step.

Imagine an AI agent that can:

Read email.

Access documents.

Query databases.

Create tickets.

Send messages.

Update records.

Now, as a security professional, I immediately have questions.

What identity does the agent use?

What permissions does it have?

How does it authenticate?

What data can it access?

Can it perform privileged actions?

Are its activities logged?

Can its access be revoked?

What happens if someone manipulates the agent into performing an action it shouldn't?

These sound like AI security questions.

But they're also familiar cybersecurity questions.

They involve:

Identity.

Least privilege.

Access control.

Monitoring.

Data protection.

Incident response.

The technology is new.

Many of the security principles aren't.

AI Will Change What Makes a Good Security Analyst

I don't think AI means security analysts disappear.

I think it changes where analysts provide the most value.

Some repetitive tasks will become easier.

AI may help summarise incidents.

It may help generate queries.

It may help explain malware behaviour.

It may help correlate security events.

It may help analysts work through large amounts of telemetry.

But someone still needs to decide:

Does this make sense?

What evidence supports it?

What should we investigate next?

What is the actual risk?

Should we contain the system?

What could containment affect?

How far did the attacker get?

Those decisions require judgement.

I Don't Want AI to Replace My Curiosity

This is probably the biggest thing I want to protect as AI becomes more integrated into cybersecurity.

My curiosity.

If an authentication event looks strange, I want to ask:

Why?

If five accounts authenticate from the same unusual IP:

Why?

If an endpoint suddenly launches PowerShell:

What launched it?

If an AI assistant tells me an incident is low risk:

What evidence supports that conclusion?

The moment I stop asking questions because AI gave me an answer, I become less effective as an analyst.

The Bigger Picture

I don't think the future of cybersecurity is:

Humans vs AI.

And I don't think it's:

AI replaces cybersecurity professionals.

The reality is much more interesting.

Attackers will use AI.

Defenders will use AI.

Employees will use AI.

Security vendors will build AI into their products.

Applications will increasingly interact with AI.

AI agents will receive access to organisational systems and data.

And security teams will have to protect all of it.

Eventually, simply having AI won't be an advantage.

Almost everyone will have access to it.

The advantage will come from knowing how to use it effectively while understanding its limitations.

Final Thoughts

AI is changing cybersecurity.

But I don't think it's replacing the fundamentals.

If anything, it makes them more important.

We still need:

Identity security.

Least privilege.

Data protection.

Monitoring.

Incident response.

Human judgement.

Curiosity.

AI can help me investigate faster.

It can help me understand information faster.

It can help me automate repetitive work.

It can help me become a more efficient security analyst.

But there's one thing I don't want it to do:

Think for me.

Because cybersecurity isn't only about finding answers.

It's about knowing which question to ask next.

A user might report that emails are missing, messages are being marked as read, or someone received an email they don't remember sending.

But behind that behaviour could be an attacker who has gained access to the user's Microsoft 365 account and is trying to remain unnoticed.

In this article, I'll walk through how I approach investigating a suspected Microsoft 365 account takeover, from the initial alert through containment and recovery.

Note: This is based on the investigation process I use in real-world security operations. Client and user information has been excluded.

The Scenario

Imagine a user account shows suspicious authentication activity.

During the investigation, we also discover an unexpected inbox rule.

The rule is automatically moving or deleting certain emails.

That's immediately concerning.

Attackers involved in business email compromise (BEC) often want to maintain access without attracting the user's attention. Manipulating email rules can help hide security notifications, replies, financial conversations or other messages that could expose their activity.

At this point, I wouldn't treat the inbox rule as an isolated email problem.

I would investigate the account as potentially compromised.

Step 1: Investigate the Sign-In Activity

My first question is:

How did someone access this account?

Using Microsoft Entra ID and the available Microsoft security telemetry, I would review authentication activity for indicators such as:

• Sign-ins from unusual countries or locations

• Unfamiliar IP addresses

• New devices or browsers

• Multiple failed logins followed by a successful login

• Impossible or unusual travel patterns

• Changes in authentication methods

• Suspicious MFA activity

One unusual login doesn't automatically mean compromise.

The goal is to build context around the authentication event and determine whether the behaviour makes sense for that particular user.

Step 2: Check the User's Mailbox

If compromise is suspected, I want to understand what the attacker may have changed after gaining access.

One of the first things I check is the user's inbox rules.

For example, using Exchange Online PowerShell:

Get-InboxRule -Mailbox user@company.com

I'm looking for unexpected rules that:

• Delete messages

• Move messages into unusual folders

• Mark messages as read

• Forward emails

• Redirect emails externally

• Target specific senders or keywords

If I confirm that a rule is malicious, it needs to be removed as part of containment.

Remove-InboxRule -Mailbox user@company.com -Identity "SuspiciousRule"

However, I don't stop the investigation there.

Removing the rule fixes one symptom.

It doesn't answer the bigger question:

What else did the attacker do while they had access?

Step 3: Determine the Scope

This is where incident response becomes more than simply resetting a password.

I want to establish the attacker's blast radius.

Questions I would investigate include:

What did they access?

Did they only access Exchange Online, or was there activity involving SharePoint, OneDrive, Teams or other Microsoft 365 services?

What did they change?

Were inbox rules, forwarding settings, MFA methods or account settings modified?

What did they send?

Did the attacker send phishing emails or fraudulent payment requests from the compromised mailbox?

Who did they interact with?

Internal and external recipients may need to be identified if malicious messages were sent.

Are other accounts affected?

If the original attack involved phishing or credential theft, there may be additional compromised users.

The objective is to move from:

"This user's mailbox was compromised."

to:

"We understand what the attacker accessed, changed and attempted to do."

Step 4: Contain the Account

Once compromise has been confirmed, containment becomes the priority.

Depending on the environment and severity of the incident, I would typically consider actions such as:

• Resetting the user's password

• Revoking active sessions

• Removing malicious inbox or forwarding rules

• Reviewing registered MFA methods

• Enforcing or re-registering MFA where necessary

• Blocking the account temporarily if the threat is still active

• Checking for suspicious applications or permissions

• Investigating related users, IP addresses and indicators

Revoking sessions is particularly important.

Changing the password alone should not be treated as the entire containment strategy.

The goal is to remove the attacker's access, not simply change one credential.

Step 5: Hunt for Related Activity

Once the immediate account is contained, I would use the available telemetry to determine whether the activity extends further into the environment.

This is where tools such as Microsoft Defender XDR and Microsoft Sentinel become valuable.

Using KQL, for example, I could investigate authentication behaviour and correlate suspicious activity across users, IP addresses and devices.

A simplified hunting approach might start with something like:

SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "user@company.com"
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType
| order by TimeGenerated desc

From there, I can pivot.

If I identify a suspicious IP address, I can ask:

Did that same IP authenticate to any other accounts?

SigninLogs
| where TimeGenerated > ago(7d)
| where IPAddress == "SUSPICIOUS_IP"
| summarize
    SignInCount=count(),
    Users=make_set(UserPrincipalName)
    by IPAddress

That's one of the things I enjoy about threat hunting.

A good investigation keeps generating the next question.

Step 6: Recover Securely

After containment, the account needs to return to normal operation without reintroducing the same risk.

Recovery can include:

• Confirming the password reset

• Confirming legitimate MFA methods

• Verifying mailbox rules

• Checking forwarding configurations

• Reviewing account permissions

• Confirming suspicious sessions are terminated

• Monitoring the account for additional suspicious activity

I would also communicate with the affected user.

They need to understand what happened, what actions were taken and what behaviour they should report if they notice anything unusual again.

Step 7: Ask How We Prevent It From Happening Again

For me, this is one of the most important parts of incident response.

An incident shouldn't end with:

"We fixed the account."

It should also ask:

"What control could have prevented or detected this earlier?"

Depending on the root cause, improvements could include:

• Stronger Conditional Access policies

• MFA improvements

• Blocking legacy authentication

• Better risky sign-in detection

• Improved email security controls

• User phishing awareness

• Alerting for suspicious inbox rules

• Better Sentinel or Defender detection rules

• Improved incident-response playbooks

This turns an individual security incident into an opportunity to improve the organisation's overall security posture.

The Biggest Lesson

One of the biggest lessons I've learned from security operations is that an alert is rarely the whole story.

A suspicious login isn't just a login.

A malicious inbox rule isn't just an inbox rule.

Each indicator is a starting point.

The security analyst's job is to determine:

What happened?

How did it happen?

What did the attacker access?

How far did they get?

How do we remove them?

And finally:

What do we change so that the next attack is harder?

That's the difference between simply closing an alert and actually investigating an incident.

Topics: Microsoft 365 Security · Incident Response · Microsoft Defender XDR · Microsoft Sentinel · Microsoft Entra ID · KQL · Business Email Compromise · Cybersecurity