July 5, 2026

How To Trick Microsoft Graph Into Securing Your Entire Tenant

Microsoft Graph is often seen as a reporting and management API—but what if it could become one of your most powerful security tools? In this episode, we explore how Microsoft Graph can be leveraged to uncover hidden risks, automate governance, and continuously improve the security posture of an entire Microsoft 365 tenant. Rather than relying solely on traditional security dashboards, Graph provides direct access to identities, permissions, groups, applications, devices, and collaboration data, enabling organizations to detect problems before they become incidents.

You'll learn how to use Microsoft Graph to identify excessive permissions, orphaned resources, inactive accounts, risky application consents, external sharing, and configuration drift across Microsoft 365. The episode explains why security is ultimately a data problem and how Graph serves as the unified interface that makes tenant-wide visibility and automation possible.

We also discuss practical automation scenarios using Graph PowerShell, scheduled assessments, and custom governance solutions that continuously monitor your environment instead of relying on periodic manual audits. Whether you're responsible for security, compliance, identity management, or Microsoft 365 architecture, this episode demonstrates how Microsoft Graph can help transform reactive administration into proactive, data-driven security operations—often without requiring expensive third-party tooling.

In today's digital landscape, tenant security is more crucial than ever. Cyber threats loom large, with about 85% of tenants facing targeted attacks. You need robust measures to protect your organization. Microsoft Graph emerges as a powerful tool that enhances security. By leveraging Microsoft Graph, you can trick Microsoft Graph into shifting from reactive monitoring to proactive management. This transition allows for real-time visibility into your tenant's activities and helps detect potential threats before they escalate.

Remember, effective security is not just about having defenses in place; it’s about actively managing and adapting them to emerging threats.

Key Takeaways

Microsoft Graph provides real-time visibility into tenant activities, allowing for proactive threat detection.
Integrate Microsoft Graph with Microsoft 365 to enhance security capabilities and automate compliance processes.
Centralized data access through Microsoft Graph helps manage user roles and monitor access rights effectively.
Set up security alerts in Microsoft Graph to receive immediate notifications about potential threats.
Regularly analyze activity logs to identify unusual user behavior and prevent security incidents.
Implement conditional access policies to control user access based on specific conditions, enhancing security.
Conduct quarterly security assessments to identify vulnerabilities and ensure compliance with security policies.
Automate investigations using Microsoft Graph to improve response times and streamline security operations.

Microsoft Graph Overview

Microsoft Graph serves as a powerful tool for enhancing tenant security. It offers several key features that provide organizations with the ability to monitor and manage their security posture effectively.

Key Features

Real-time Visibility

With Microsoft Graph, you gain real-time visibility into your tenant's activities. This feature allows you to track user sign-ins, permission changes, and application behaviors as they happen. By having access to this continuous flow of information, you can respond to potential threats before they escalate. The Microsoft Graph API provides a unified endpoint for accessing a wide range of data and insights in Microsoft cloud services, including security features that help protect organizations from data loss.

Integration with Microsoft 365

Microsoft Graph seamlessly integrates with Microsoft 365, enhancing your security capabilities. The Microsoft Graph Security API provides a standard interface to integrate security alerts and threat intelligence from multiple sources. This integration enriches alerts with contextual information and automates security operations. For example, you can automate access reviews and integrate compliance workflows, aiding in meeting regulatory requirements like GDPR and HIPAA.

Benefits for Tenant Security

Centralized Data Access

Centralized data access is a significant benefit of using Microsoft Graph. It allows you to manage user roles and access rights programmatically. This capability ensures tight control and continuous monitoring of access to critical systems. You can generate reports through Microsoft Graph Data Connect to identify and remediate oversharing incidents. This proactive approach helps maintain compliance with governance policies and reduces the risk of data breaches.

Proactive Governance

Proactive governance is essential for maintaining a secure environment. Microsoft Graph enables you to automate compliance processes, which is crucial for meeting regulations. By continuously evaluating permissions and automating the removal of unnecessary access, you can significantly reduce your attack surface. Additionally, the ability to track improvements over time aids in policy enforcement and enhances your overall security posture.

Trick Microsoft Graph for Threat Detection

Detecting threats early is vital for maintaining a secure environment. Microsoft Graph provides powerful tools to help you achieve this. By leveraging security alerts and analyzing threat intelligence, you can enhance your threat detection capabilities significantly.

Utilizing Security Alerts

Setting Up Alerts

To effectively use Microsoft Graph for threat detection, start by setting up security alerts. These alerts notify you of potential threats in real-time. Follow these steps to configure alerts:

Access the Microsoft Graph Security API.
Define the types of alerts you want to monitor, such as suspicious sign-ins or unusual application behavior.
Set the severity levels for each alert type. You can choose from low, medium, or high severity based on your organization's risk tolerance.

Here’s a quick overview of common security alerts generated by Microsoft Graph:

Severity Level	Description
Medium	Alerts generated from detections and response post-breach behaviors that might be part of an advanced persistent threat (APT). This includes observed behaviors typical of attack stages, anomalous registry changes, and execution of suspicious files.
High	Alerts commonly associated with advanced persistent threats (APT) indicating a high risk due to potential damage. Examples include credential theft tools activities, ransomware activities, and tampering with security sensors.

Responding to Alerts

Once you set up alerts, you need to respond promptly. Quick action can prevent data exfiltration and mitigate risks. Here are some steps to take when you receive an alert:

Investigate the alert immediately to determine its legitimacy.
Assess the potential impact on your organization.
If the alert indicates a real threat, initiate your incident response plan.
Document your findings and actions taken for future reference.

Recent studies show that Microsoft Graph security alerts redefine how defenders perceive and respond to threats. Attackers exploit vulnerabilities using graph thinking, so you should adopt similar strategies for effective threat detection. This proactive approach enhances your ability to understand complex threat patterns, leading to quicker and more informed security responses.

Analyzing Threat Intelligence

Accessing Threat Data

Analyzing threat intelligence is crucial for understanding the landscape of potential threats. You can access threat data through Microsoft Graph by following these steps:

Review mailbox sign-ins to validate legitimacy.
Investigate unusual activity regarding Microsoft Graph API permissions.
Use tools like Sparrow to check Graph API application permissions.
Analyze MailItemsAccessed for insights into mailbox access.
Utilize Aviary for data collection and analysis.

By systematically reviewing this data, you can identify patterns that may indicate a security breach.

Integrating with Security Tools

Integrating Microsoft Graph with other security tools enhances your threat detection capabilities. This integration allows for a more comprehensive view of your security posture. You can combine data from various sources to create a unified threat detection system.

For example, using Microsoft Graph alongside SIEM solutions can provide deeper insights into security events. This integration allows you to visualize relationships between different data points, making it easier to identify potential threats.

Feature	Microsoft Graph	Other Platforms
Contextual Visibility	Deeper understanding of relationships	Limited visibility
Detection and Response Speed	Faster due to unified telemetry access	Slower response times
Proactive Threat Hunting	Enhanced with hunting graph	Siloed alert analysis
Impact Mitigation Efficiency	Real-time visualization of blast radius	Less targeted mitigation
AI-Assisted Capabilities	Autonomous defense capabilities	Traditional methods

By leveraging these integrations, you can significantly improve your organization's ability to detect and respond to threats.

Activity Logs and Auditing

Activity logs play a vital role in maintaining tenant security. They provide you with insights into user and admin activities, enabling you to detect and prevent security incidents effectively. By monitoring these logs, you can ensure compliance with regulatory requirements and enhance your overall security posture.

Importance of Activity Logs

Tracking User Activities

Tracking user activities through activity logs allows you to gain visibility into various actions within your Microsoft 365 environment. Here are some key aspects of what activity logs can help you monitor:

User sign-ins and authentication attempts
File, folder, and account activity in SharePoint Online and OneDrive
Teams channel activity, including chat edits or deletions
Exchange Online mailbox access by admins or delegates
Role assignments and permission changes

These logs empower your IT team to investigate suspicious actions and respond to potential threats swiftly.

Identifying Anomalies

Identifying anomalies in user behavior is crucial for early threat detection. By analyzing activity logs, you can spot unusual patterns that may indicate a security breach. For example, if a user typically accesses files during business hours but suddenly logs in at odd hours, this could raise a red flag.

Auditing with Microsoft Graph

Auditing is an essential process for maintaining security and compliance. Microsoft Graph provides powerful tools to help you generate detailed audit reports and track activities effectively.

Generating Audit Reports

To generate audit reports using Microsoft Graph, follow these steps:

Step	Description
1	Create the search query by setting the values of the search parameters.
2	Submit a search query (job).
3	Retrieve the search results (audit records) once the query completes.

You can use the following PowerShell command to initiate an audit search:

$Uri = "https://graph.microsoft.com/beta/security/auditLog/queries"
$SearchName = ("Audit Search {0}" -f (Get-Date -format 'dd-MMM-yyyy HH:mm'))
$SearchParameters = @{ "displayName" = $SearchName; "filterStartDateTime" = $StartDateSearch; "filterEndDateTime" = $EndDateSearch; "operationFilters" = $Operations; }
$SearchQuery = Invoke-MgGraphRequest -Method POST -Uri $Uri -Body $SearchParameters
$SearchId = $SearchQuery.Id

This command allows you to create a comprehensive audit report that can help you maintain compliance with security policies.

Best Practices

To maintain comprehensive activity logs using Microsoft Graph, consider the following best practices:

Best Practice	Description
Use $select	Choose only the properties your app needs for performance improvements.
Webhook Notifications	Get notifications for data changes instead of polling regularly for efficiency.
Delta Queries	Use webhooks to trigger delta query calls and implement a backstop polling threshold.
JSON Batching	Combine multiple requests into a single JSON object to save network latency and resources.

Additionally, always log the full HTTP Graph API call, including the URL, headers, and JSON body for both requests and responses. Avoid storing sensitive information like passwords or tokens in auditable resources.

By following these practices, you can enhance your auditing processes and ensure that your tenant remains secure.

Investigation Techniques with Microsoft Graph

Investigating security incidents effectively is crucial for maintaining a secure environment. Microsoft Graph provides various techniques to help you analyze user data and automate investigations. By leveraging these capabilities, you can enhance your organization's security posture.

Querying User Data

Analyzing Access Patterns

You can analyze access patterns using Microsoft Graph to identify potential security breaches. Here are some methods to query user data:

Utilize KQL (Kusto Query Language) to analyze Microsoft Graph Activity Logs.
Access the MicrosoftGraphActivityLogs, which serve as an audit trail of HTTP requests processed by Microsoft Graph.
Key columns for detection include AppId, IPAddress, RequestId, RequestMethod, RequestUri, Roles, Scopes, ServicePrincipalId, UserAgent, and UserId.
Use the parse_url() function to extract parameters from the RequestUri for better analysis.
Summarize request statistics to identify the types of GraphAPI requests made.

These logs provide comprehensive records of API calls within Azure tenants. They are crucial for monitoring suspicious behavior and detecting anomalies that may signal security threats. Establishing a baseline of normal user behavior is essential for identifying unusual activities. Recent interactions with files and folders are logged automatically, aiding in this analysis. This foundational data is critical for spotting potential document exfiltration or other security breaches.

Automating Investigations

Automating investigations can significantly enhance your response time to security incidents. Microsoft Graph allows you to automate security tasks and workflows, improving operational efficiency. Here are some key features:

Feature	Description
Unified Security Threat Submission API	Allows submission of threats and retrieval of submission results, facilitating easier integration across security solutions.
Automation of Security Workflows	Enables automation of security management, monitoring, and investigations to enhance operational efficiency.
Integration with Security Solutions	Provides a unified interface to integrate with various security solutions, streamlining operations and improving defense against cyber threats.

The MgGraph PowerShell module aids in incident response investigations. It allows for flexible and efficient data collection and analysis from Microsoft Graph.

Integrating with SIEM Solutions

Integrating Microsoft Graph with SIEM solutions enhances your ability to respond to threats in real-time. This integration provides several advantages:

Enhanced visibility into application-layer threats, allowing for faster detection and response.
Actionable context for SOC teams, improving their ability to triage and identify root causes of threats.
Collaboration among security teams by offering a shared view of application-layer risks.

By using Microsoft Graph alongside your SIEM solutions, you can create a more comprehensive security strategy. This integration allows you to visualize relationships between different data points, making it easier to identify potential threats and respond effectively.

Best Practices for Tenant Security

Maintaining a secure Microsoft 365 tenant requires implementing best practices that adapt to evolving threats. Two critical areas to focus on are conditional access and regular security assessments.

Implementing Conditional Access

Conditional access is a vital strategy for enhancing tenant security. It allows you to enforce policies that govern how users access resources based on specific conditions.

Setting Policies

To set effective conditional access policies, follow these steps:

Apply Conditional Access policies to every app to ensure comprehensive security coverage.
Minimize the number of policies to enhance manageability and efficiency.
Establish naming conventions for policies to govern and manage them at scale.
Monitor impact with reporting tools to visualize policy effectiveness and identify conflicts.
Troubleshoot efficiently using the What If tool to simulate sign-in scenarios.
Protect policy changes by enabling protected actions for additional verification.
Automate policy management using Microsoft Graph APIs for streamlined operations.

Implementing these practices aligns access controls with least-privilege principles. This approach reduces the attack surface for your organization, minimizing unauthorized access incidents. Regular audits and requiring multifactor authentication (MFA) further strengthen your security posture.

Monitoring Access

Monitoring access is crucial for identifying potential security threats. Use Microsoft Graph to track user sign-ins and access patterns. This data helps you detect anomalies that may indicate unauthorized access attempts. By analyzing these patterns, you can respond quickly to suspicious activities.

Regular Security Assessments

Conducting regular security assessments is essential for maintaining a robust security posture. These assessments help you identify vulnerabilities and ensure compliance with security policies.

Conducting Assessments

You should conduct security assessments at least quarterly. Continuous monitoring for configuration drift is also essential. Regular assessments enhance security effectiveness and operations, providing rich information from integrated partner products. They simplify engineering investments for technology partners, magnifying customer value.

Updating Security Protocols

Updating security protocols is vital to address emerging threats. Here are some recommended updates:

Sign Out Inactive Users Automatically: This practice prevents unauthorized access by signing out users after a period of inactivity.
Block Legacy Authentication: Disabling legacy authentication protocols reduces the risk of password spray and credential stuffing attacks.
Set User Passwords to Never Expire: Following NIST recommendations helps maintain password strength and security.

Review security configurations at least quarterly and whenever Microsoft releases significant updates. This regular review helps identify policy drift and new vulnerabilities, ensuring your tenant remains secure.

By implementing these best practices, you can significantly enhance your Microsoft 365 tenant security. Proactive measures like conditional access and regular assessments will help you stay ahead of potential threats.

In summary, you can significantly enhance your tenant security by leveraging Microsoft Graph. Key strategies include:

Monitoring application activity to identify potential security risks.
Enforcing least privilege principles to minimize your attack surface.
Utilizing modern authentication methods to strengthen your security posture.
Conducting regular reviews of permissions for high-risk applications to prevent unauthorized access.

By implementing these strategies, you can create a robust security framework. Remember, ongoing vigilance is essential. Stay proactive in your security efforts to protect your Microsoft 365 environment effectively.

FAQ

What is Microsoft Graph?

Microsoft Graph is a unified API that connects various Microsoft 365 services. It provides access to data and insights, enabling you to manage security, user activities, and compliance across your organization.

How does Microsoft Graph enhance tenant security?

Microsoft Graph enhances tenant security by providing real-time visibility into user activities and security alerts. It allows you to automate governance processes and proactively manage permissions, reducing potential vulnerabilities.

Can I integrate Microsoft Graph with other security tools?

Yes, you can integrate Microsoft Graph with various security tools, including SIEM solutions. This integration enhances your threat detection capabilities and provides a comprehensive view of your security posture.

How do I set up security alerts in Microsoft Graph?

To set up security alerts, access the Microsoft Graph Security API. Define the alert types you want to monitor, set severity levels, and configure notifications to stay informed about potential threats.

What are activity logs, and why are they important?

Activity logs track user and admin actions within your Microsoft 365 environment. They are crucial for identifying anomalies, ensuring compliance, and investigating security incidents effectively.

How often should I conduct security assessments?

You should conduct security assessments at least quarterly. Regular assessments help identify vulnerabilities and ensure compliance with security policies, keeping your tenant secure against emerging threats.

What is conditional access, and how does it work?

Conditional access is a security strategy that enforces policies governing user access based on specific conditions. It helps ensure that only authorized users can access sensitive resources, enhancing overall security.

How can I automate investigations using Microsoft Graph?

You can automate investigations by leveraging Microsoft Graph's unified Security Threat Submission API. This allows you to submit threats and streamline security workflows, improving your response time to incidents.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:05,320
Your security dashboard is green, everything looks fine, policies are in place, alerts are flowing, you're monitoring.

2
00:00:05,320 --> 00:00:09,240
But in reality, that dashboard is a snapshot of a world that no longer exists.

3
00:00:09,240 --> 00:00:14,120
You have 500 applications, you have 10,000 identities, you have a governance model built for 2010.

4
00:00:14,120 --> 00:00:17,120
Most security teams think they're in control because they can see the portal.

5
00:00:17,120 --> 00:00:21,080
But portals are rear view mirrors, they show you what happened, not what's happening.

6
00:00:21,080 --> 00:00:23,720
And they definitely don't show you what's about to break.

7
00:00:23,720 --> 00:00:25,560
That's where Microsoft Graph changes everything.

8
00:00:25,560 --> 00:00:29,640
Graph isn't another tool, it's the structural layer underneath all of M365.

9
00:00:29,640 --> 00:00:31,280
It's where the actual decisions happen.

10
00:00:31,280 --> 00:00:36,320
Every sign in every permission grant, every policy evaluation, they all happen in Graph first.

11
00:00:36,320 --> 00:00:37,960
The portal just shows you the aftermath.

12
00:00:37,960 --> 00:00:42,120
And if you understand how to use it, you can automate security in a way that portals never will.

13
00:00:42,120 --> 00:00:45,600
Today, we're not looking at dashboards, we're looking at the model behind them.

14
00:00:45,600 --> 00:00:47,640
Why portals are killing your security?

15
00:00:47,640 --> 00:00:50,320
Here's what happens every single day in your tenant.

16
00:00:50,320 --> 00:00:51,720
The portal shows you state.

17
00:00:51,720 --> 00:00:58,200
Not flow, a snapshot at 2pm says your environment looks secure, but by 3pm, 50 new OAuth grants have been created.

18
00:00:58,200 --> 00:01:01,320
By 4pm, someone signed in from an impossible location.

19
00:01:01,320 --> 00:01:04,920
By 5pm, a user has already downloaded 10,000 files.

20
00:01:04,920 --> 00:01:08,640
And your dashboard still shows green, because dashboards don't update in real time.

21
00:01:08,640 --> 00:01:10,080
They update when they update.

22
00:01:10,080 --> 00:01:12,760
Conditional access policies feel like they're protecting you.

23
00:01:12,760 --> 00:01:15,720
You've set them up, you see them in the portal, you think they're working.

24
00:01:15,720 --> 00:01:18,560
But enforcement latency means real time protection is a myth.

25
00:01:18,560 --> 00:01:22,440
A policy you create today might not be enforced on every endpoint until tomorrow.

26
00:01:22,440 --> 00:01:24,760
Full propagation can take 24 hours.

27
00:01:24,760 --> 00:01:30,640
So a risky user signs in while your new policy is still rolling out. By the time the policy is everywhere, the damage is already done.

28
00:01:30,640 --> 00:01:31,920
You're monitoring alerts.

29
00:01:31,920 --> 00:01:33,280
Your SOC team is watching.

30
00:01:33,280 --> 00:01:34,480
Tickets are being created.

31
00:01:34,480 --> 00:01:35,520
But here's the problem.

32
00:01:35,520 --> 00:01:37,760
You're monitoring the alerts that are being triggered.

33
00:01:37,760 --> 00:01:40,800
You're not monitoring the alerts that should be triggered, but aren't.

34
00:01:40,800 --> 00:01:41,800
The gaps are invisible.

35
00:01:41,800 --> 00:01:44,880
A risky sign in that doesn't hit your threshold still happens.

36
00:01:44,880 --> 00:01:46,440
It just never creates an alert.

37
00:01:46,440 --> 00:01:47,920
So it never gets investigated.

38
00:01:47,920 --> 00:01:49,720
Your audit logs tell you what happened.

39
00:01:49,720 --> 00:01:50,320
Great.

40
00:01:50,320 --> 00:01:51,800
A user changed a mail rule.

41
00:01:51,800 --> 00:01:54,280
An admin modified a conditional access policy.

42
00:01:54,280 --> 00:01:56,560
A service principle read 50,000 mailboxes.

43
00:01:56,560 --> 00:01:59,400
The logs recorded, but the logs don't tell you why it happened.

44
00:01:59,400 --> 00:02:01,240
They don't tell you if it was legitimate.

45
00:02:01,240 --> 00:02:04,200
And they definitely don't tell you what you should do about it right now.

46
00:02:04,200 --> 00:02:05,320
You do manual reviews.

47
00:02:05,320 --> 00:02:08,440
Once a quarter, someone sits down and audits app permissions.

48
00:02:08,440 --> 00:02:11,280
You find an app that's been decommissioned, but still has access.

49
00:02:11,280 --> 00:02:12,160
You remove it.

50
00:02:12,160 --> 00:02:14,160
You feel confident that you've tightened your environment.

51
00:02:14,160 --> 00:02:14,920
But here's the trap.

52
00:02:14,920 --> 00:02:16,120
Permissions change daily.

53
00:02:16,120 --> 00:02:17,520
Apps request new scopes.

54
00:02:17,520 --> 00:02:19,560
Users grant consent to new applications.

55
00:02:19,560 --> 00:02:23,800
In the 90 days between your audits, your permission landscape has completely shifted.

56
00:02:23,800 --> 00:02:25,800
Manual reviews create false confidence.

57
00:02:25,800 --> 00:02:28,280
They make you think you have control when you actually don't.

58
00:02:28,280 --> 00:02:30,680
The real security decisions don't happen in the UI layer.

59
00:02:30,680 --> 00:02:32,000
They happen in the API layer.

60
00:02:32,000 --> 00:02:33,880
The portal is just a window into that layer.

61
00:02:33,880 --> 00:02:34,960
And windows are incomplete.

62
00:02:34,960 --> 00:02:37,760
They show you only what the UI developers decided to show you.

63
00:02:37,760 --> 00:02:39,000
They hide complexity.

64
00:02:39,000 --> 00:02:40,480
They smooth over latency.

65
00:02:40,480 --> 00:02:43,600
They make everything look simpler and more controlled than it actually is.

66
00:02:43,600 --> 00:02:46,800
So when you're looking at a green dashboard, you're not looking at your actual security

67
00:02:46,800 --> 00:02:47,320
state.

68
00:02:47,320 --> 00:02:50,600
You're looking at a simplified representation of a moment in time.

69
00:02:50,600 --> 00:02:52,000
The moment has already passed.

70
00:02:52,000 --> 00:02:53,320
The threats have already moved.

71
00:02:53,320 --> 00:02:55,120
Your environment has already changed.

72
00:02:55,120 --> 00:02:57,720
That's the fundamental problem with portal-based security.

73
00:02:57,720 --> 00:02:59,640
You already understand the problem now.

74
00:02:59,640 --> 00:03:01,720
Understanding why portals fail is the first step.

75
00:03:01,720 --> 00:03:03,800
But understanding what graph can do.

76
00:03:03,800 --> 00:03:04,800
That's the leap.

77
00:03:04,800 --> 00:03:07,400
The structural floor in M365 governance.

78
00:03:07,400 --> 00:03:09,760
Here is the core problem underneath all of this.

79
00:03:09,760 --> 00:03:13,720
Your M365 governance model was built around one assumption, state management.

80
00:03:13,720 --> 00:03:14,720
You set a policy.

81
00:03:14,720 --> 00:03:15,720
You check it once in a while.

82
00:03:15,720 --> 00:03:16,720
You assume it holds.

83
00:03:16,720 --> 00:03:19,080
You create a conditional access policy and it stays there.

84
00:03:19,080 --> 00:03:23,280
You grant an app permission and that permission remains until you manually revoke it.

85
00:03:23,280 --> 00:03:26,280
You assign a user to a security group and they stay in that group.

86
00:03:26,280 --> 00:03:29,840
The system is supposed to be stable, predictable, governed.

87
00:03:29,840 --> 00:03:33,080
But modern identity and application security doesn't work that way anymore.

88
00:03:33,080 --> 00:03:34,080
It is not about state.

89
00:03:34,080 --> 00:03:36,880
It is about flow.

90
00:03:36,880 --> 00:03:39,400
Think about what is actually happening in your tenant right now.

91
00:03:39,400 --> 00:03:43,640
There is a continuous stream of sign-ins happening hundreds of times per minute from real users

92
00:03:43,640 --> 00:03:45,360
and automated services.

93
00:03:45,360 --> 00:03:46,880
Tokens are being issued and used.

94
00:03:46,880 --> 00:03:50,760
OOath apps are being granted permissions, sometimes with user consent and sometimes

95
00:03:50,760 --> 00:03:52,080
with admin approval.

96
00:03:52,080 --> 00:03:56,880
Users are being added to groups while mailboxes are being accessed and files are being downloaded.

97
00:03:56,880 --> 00:03:58,480
Policies are changing.

98
00:03:58,480 --> 00:03:59,800
Configurations are drifting.

99
00:03:59,800 --> 00:04:03,360
And all of this is happening simultaneously in a distributed system across multiple data

100
00:04:03,360 --> 00:04:06,240
centers with inconsistent timing and propagation.

101
00:04:06,240 --> 00:04:08,120
Your governance model does not see flow.

102
00:04:08,120 --> 00:04:09,120
It sees snapshots.

103
00:04:09,120 --> 00:04:13,440
It sees endpoints and state transitions but it misses the continuous movement underneath.

104
00:04:13,440 --> 00:04:15,360
Here is what that breakdown looks like in practice.

105
00:04:15,360 --> 00:04:18,560
A user grants consent to an OAuth app right now.

106
00:04:18,560 --> 00:04:21,920
10 seconds ago, you will not know about it until your audit runs.

107
00:04:21,920 --> 00:04:26,440
By audit time, that app might have already read the user's email, downloaded their files,

108
00:04:26,440 --> 00:04:29,400
and started using their identity to access other resources.

109
00:04:29,400 --> 00:04:31,600
The damage is not from the permission grant itself.

110
00:04:31,600 --> 00:04:35,200
The damage is from everything that happened between when the grant was approved and when

111
00:04:35,200 --> 00:04:37,120
you finally discovered it.

112
00:04:37,120 --> 00:04:39,640
Conditional access policies have propagation delays.

113
00:04:39,640 --> 00:04:42,760
You create a policy and it goes into effect immediately in the portal, but it does not

114
00:04:42,760 --> 00:04:44,320
enforce everywhere at once.

115
00:04:44,320 --> 00:04:48,040
The policy has to propagate to every endpoint, every cloud region, and every authentication

116
00:04:48,040 --> 00:04:49,040
flow.

117
00:04:49,040 --> 00:04:50,040
That process takes time.

118
00:04:50,040 --> 00:04:53,840
While users are signing in, some of them are risky, some of them should be blocked, but

119
00:04:53,840 --> 00:04:58,040
the block does not happen because your new policy has not reached their sign-in server yet.

120
00:04:58,040 --> 00:05:02,040
Permission creep happens invisibly, an app requests mail, read right, and you approve it.

121
00:05:02,040 --> 00:05:04,720
Six months later, that same app requests files.

122
00:05:04,720 --> 00:05:07,680
Read right, then directory, DOM, read, and then calendar.

123
00:05:07,680 --> 00:05:08,680
Read right.

124
00:05:08,680 --> 00:05:11,800
Each request seems reasonable in isolation so each one gets approved.

125
00:05:11,800 --> 00:05:15,600
But now that app has accumulated enough permissions to read your entire tenant's email files

126
00:05:15,600 --> 00:05:16,600
in calendar.

127
00:05:16,600 --> 00:05:20,680
You do not know it is over-privileged until an incident happens or a threat hunt discovers

128
00:05:20,680 --> 00:05:21,680
it.

129
00:05:21,680 --> 00:05:22,680
The fundamental mismatch is this.

130
00:05:22,680 --> 00:05:25,120
M365 is a distributed system.

131
00:05:25,120 --> 00:05:26,640
Everything is happening continuously.

132
00:05:26,640 --> 00:05:30,400
Everything is interconnected, but you are trying to govern it, like it is centralized and

133
00:05:30,400 --> 00:05:31,400
static.

134
00:05:31,400 --> 00:05:33,760
You are trying to manage flow with state-based controls.

135
00:05:33,760 --> 00:05:35,080
That is the structural flow.

136
00:05:35,080 --> 00:05:38,520
That is why portals create the illusion of control while the actual system operates beneath

137
00:05:38,520 --> 00:05:39,520
that illusion.

138
00:05:39,520 --> 00:05:41,640
This is where Microsoft Graph becomes the connective tissue.

139
00:05:41,640 --> 00:05:43,040
It is not just another API.

140
00:05:43,040 --> 00:05:45,240
It is the actual governance engine underneath the UI.

141
00:05:45,240 --> 00:05:46,240
It sees the flow.

142
00:05:46,240 --> 00:05:47,400
It can react to the flow.

143
00:05:47,400 --> 00:05:51,840
And if you build your security model around graph instead of around portals, you can finally

144
00:05:51,840 --> 00:05:56,920
govern the system as it actually operates while what Microsoft Graph actually is.

145
00:05:56,920 --> 00:05:59,080
Let's be precise about what we are talking about.

146
00:05:59,080 --> 00:06:03,920
Microsoft Graph is the unified REST API that exposes the entire M365 system.

147
00:06:03,920 --> 00:06:07,480
Users, groups, devices, mail, calendar files, teams, conversations, and SharePoint sites

148
00:06:07,480 --> 00:06:09,560
are all accessible through Graph.

149
00:06:09,560 --> 00:06:14,960
Security alerts, identity events, audit logs, risk detections, policy configurations, application

150
00:06:14,960 --> 00:06:17,920
registrations, and permission grants are there too.

151
00:06:17,920 --> 00:06:21,080
Conditional access policies and device compliance states have endpoints.

152
00:06:21,080 --> 00:06:25,720
Every resource in Microsoft 365 has a place and every operation has a corresponding API

153
00:06:25,720 --> 00:06:26,720
call.

154
00:06:26,720 --> 00:06:29,860
But here is what most people miss about Graph and this is the critical insight.

155
00:06:29,860 --> 00:06:31,200
Graph is not just an API.

156
00:06:31,200 --> 00:06:35,880
It is not a wrapper around M365 that lets you do what you could already do in the portal.

157
00:06:35,880 --> 00:06:37,200
Graph is the control plane.

158
00:06:37,200 --> 00:06:39,160
It is the actual governance engine.

159
00:06:39,160 --> 00:06:43,320
Every decision that happens in Microsoft 365 flows through Graph first.

160
00:06:43,320 --> 00:06:47,920
Every sign-in, every policy evaluation, every permission grant, and every audit event starts

161
00:06:47,920 --> 00:06:48,920
there.

162
00:06:48,920 --> 00:06:52,000
The decision happens in Graph and only then does the UI show you the result.

163
00:06:52,000 --> 00:06:53,680
Think about how sign-in works.

164
00:06:53,680 --> 00:06:56,360
When a user tries to sign in that request does not go to the portal.

165
00:06:56,360 --> 00:06:58,320
The portal is not evaluating anything.

166
00:06:58,320 --> 00:07:03,360
The request goes into the authentication pipeline which calls the Graph APIs under the hood.

167
00:07:03,360 --> 00:07:05,920
Those Graph APIs check the conditional access policies.

168
00:07:05,920 --> 00:07:07,120
They evaluate the risk.

169
00:07:07,120 --> 00:07:08,920
They determine if MFA is required.

170
00:07:08,920 --> 00:07:10,320
The issue or deny tokens.

171
00:07:10,320 --> 00:07:11,480
All of that happens in Graph.

172
00:07:11,480 --> 00:07:13,760
The portal is just a window into that process.

173
00:07:13,760 --> 00:07:15,680
It shows you logs of what already happened.

174
00:07:15,680 --> 00:07:18,920
The portals you use are all just UI layers built on top of Graph.

175
00:07:18,920 --> 00:07:23,080
The Microsoft 365 Admin Center, the EntraID portal, the Defender portal, and the Perview

176
00:07:23,080 --> 00:07:25,360
Compliance Center are just skins.

177
00:07:25,360 --> 00:07:29,080
When you change a conditional access policy in the portal, you are not changing the portal's

178
00:07:29,080 --> 00:07:30,520
copy of the policy.

179
00:07:30,520 --> 00:07:32,640
You are sending a request to Graph to update it.

180
00:07:32,640 --> 00:07:37,040
When you view sign-in logs, you are not querying the portal's local database.

181
00:07:37,040 --> 00:07:38,040
You are calling Graph.

182
00:07:38,040 --> 00:07:39,600
The portal is a visualization layer.

183
00:07:39,600 --> 00:07:40,960
The real system is Graph.

184
00:07:40,960 --> 00:07:44,160
This is the structural shift that most organizations do not recognize.

185
00:07:44,160 --> 00:07:48,200
They treat the portal as the primary interface and Graph as an optional alternative.

186
00:07:48,200 --> 00:07:49,200
But it is backwards.

187
00:07:49,200 --> 00:07:50,400
Graph is the primary system.

188
00:07:50,400 --> 00:07:52,200
The portal is the optional visualization.

189
00:07:52,200 --> 00:07:55,040
Graph exposes the data as it actually happens.

190
00:07:55,040 --> 00:07:58,560
Sign-in logs appear with minutes of latency rather than days.

191
00:07:58,560 --> 00:08:02,000
Risk detection stream in as the ML models identify them.

192
00:08:02,000 --> 00:08:05,360
Security alerts aggregate across Defender products in a unified schema.

193
00:08:05,360 --> 00:08:08,160
Audit events, log configuration changes in real time.

194
00:08:08,160 --> 00:08:12,640
Security logs record every HTTP request made to Graph by every application in your tenant.

195
00:08:12,640 --> 00:08:16,600
This is the raw flowing data of your security model, not snapshots, flow.

196
00:08:16,600 --> 00:08:18,520
And here is the part that matters most.

197
00:08:18,520 --> 00:08:19,520
Graph is programmable.

198
00:08:19,520 --> 00:08:20,760
You can automate decisions.

199
00:08:20,760 --> 00:08:23,600
You do not have to watch the dashboard and manually click buttons.

200
00:08:23,600 --> 00:08:28,040
You can build a system that injects into Graph, pulls the data out, evaluates it, and triggers

201
00:08:28,040 --> 00:08:32,120
responses automatically and continuously without human intervention.

202
00:08:32,120 --> 00:08:34,240
This is a fundamental capability shift.

203
00:08:34,240 --> 00:08:37,520
Most security teams are reactive because they are bound to portal workflows.

204
00:08:37,520 --> 00:08:43,000
A person sees an alert, they investigate manually, they make a decision, and they take an action.

205
00:08:43,000 --> 00:08:45,320
Automation is limited to what the portal's UI can do.

206
00:08:45,320 --> 00:08:48,160
But Graph lets you build systems that are proactive.

207
00:08:48,160 --> 00:08:51,600
Systems that respond to events faster than a human can notice them.

208
00:08:51,600 --> 00:08:54,640
Systems that correlate data that humans would never correlate because the cognitive load

209
00:08:54,640 --> 00:08:55,640
is too high.

210
00:08:55,640 --> 00:08:57,080
Microsoft understands this.

211
00:08:57,080 --> 00:09:00,440
That is why in 2026 they are retiring legacy APIs.

212
00:09:00,440 --> 00:09:04,640
MDE and XDR APIs are being deprecated by February 2027.

213
00:09:04,640 --> 00:09:07,840
The older LERTS API is gone by April 2026.

214
00:09:07,840 --> 00:09:10,240
Reporting web services is retired the same month.

215
00:09:10,240 --> 00:09:14,040
The Pervy-ordered search graph API is now the standard for querying audit data.

216
00:09:14,040 --> 00:09:17,720
Microsoft is consolidating everything onto Graph Security API V2.

217
00:09:17,720 --> 00:09:19,240
This is not an optional migration.

218
00:09:19,240 --> 00:09:20,520
It is structural.

219
00:09:20,520 --> 00:09:22,720
Everything is moving on to the unified control plane.

220
00:09:22,720 --> 00:09:26,440
The organizations that build their security model around Graph now will have a structural

221
00:09:26,440 --> 00:09:27,440
advantage.

222
00:09:27,440 --> 00:09:29,800
They will not be stuck in portals or manual processes.

223
00:09:29,800 --> 00:09:33,400
They will be operating closer to how the system actually works.

224
00:09:33,400 --> 00:09:34,920
The Identity Illusion.

225
00:09:34,920 --> 00:09:38,000
Everyone thinks identity security is about passwords and MFA.

226
00:09:38,000 --> 00:09:42,800
Strong passwords, multi-factor authentication, password resets, locked accounts.

227
00:09:42,800 --> 00:09:44,160
That is where most organizations focus.

228
00:09:44,160 --> 00:09:48,640
You set a complex password policy, you mandate MFA for your admins and you set up password

229
00:09:48,640 --> 00:09:49,640
list sign-in.

230
00:09:49,640 --> 00:09:53,840
You feel like you finally solved identity security, but in reality you haven't.

231
00:09:53,840 --> 00:09:55,880
You have solved maybe 20% of the problem.

232
00:09:55,880 --> 00:09:57,120
The rest is invisible.

233
00:09:57,120 --> 00:09:59,640
Because the real identity layer isn't what you are protecting.

234
00:09:59,640 --> 00:10:00,640
It is the token layer.

235
00:10:00,640 --> 00:10:02,880
Here is what actually happens when a user signs in.

236
00:10:02,880 --> 00:10:06,720
They authenticate with a password, a fingerprint or a passkey, and once that authentication

237
00:10:06,720 --> 00:10:09,240
is successful, the system doesn't grant them access directly.

238
00:10:09,240 --> 00:10:10,760
Instead it creates a token.

239
00:10:10,760 --> 00:10:14,960
That token is a temporary cryptographic key that proves they've authenticated and it's

240
00:10:14,960 --> 00:10:17,720
used for everything they do in the system from that point on.

241
00:10:17,720 --> 00:10:21,040
They use that token to access email, files, teams and sharepoint.

242
00:10:21,040 --> 00:10:23,480
The token is the actual key to the kingdom.

243
00:10:23,480 --> 00:10:26,080
Not the password, the token.

244
00:10:26,080 --> 00:10:29,520
Once the token is issued, the original authentication is irrelevant.

245
00:10:29,520 --> 00:10:32,840
Your fancy password list sign-in created a token, and that token can be used by the

246
00:10:32,840 --> 00:10:33,840
person who possesses it.

247
00:10:33,840 --> 00:10:37,960
It can be stolen, it can be replayed, or it can be exfiltrated to another country and

248
00:10:37,960 --> 00:10:41,640
used to access your tenant while the original user is asleep in their office.

249
00:10:41,640 --> 00:10:45,640
Your strong password policy doesn't protect the token, your MFA requirement doesn't protect

250
00:10:45,640 --> 00:10:46,640
the token.

251
00:10:46,640 --> 00:10:50,760
Once the token is issued, the original authentication controls are out of the loop.

252
00:10:50,760 --> 00:10:52,080
Graph exposes this token layer.

253
00:10:52,080 --> 00:10:56,040
It shows you sign-in logs which reveal who authenticated and when, and it shows you risk

254
00:10:56,040 --> 00:11:00,040
detections where ML models analyze whether that sign-in looked legitimate.

255
00:11:00,040 --> 00:11:04,640
It shows you risky users who have exhibited suspicious behavior and it shows you risky sign-ins

256
00:11:04,640 --> 00:11:06,240
that the system flagged.

257
00:11:06,240 --> 00:11:10,280
It even shows you authentication context which is metadata about the sign-in like location,

258
00:11:10,280 --> 00:11:12,360
device, IP address and browser.

259
00:11:12,360 --> 00:11:15,240
This should give you complete visibility into your identity layer, right?

260
00:11:15,240 --> 00:11:19,200
You can see every sign-in, you can see which ones are risky and you can see which users

261
00:11:19,200 --> 00:11:21,720
are compromised so you can protect yourself.

262
00:11:21,720 --> 00:11:22,720
Except there's a catch.

263
00:11:22,720 --> 00:11:26,240
Latency sign-in logs appear in graph with a 2-5 minute delay.

264
00:11:26,240 --> 00:11:30,000
That's the 95th percentile meaning that by the time you see that a user signed in,

265
00:11:30,000 --> 00:11:31,800
those 2-5 minutes have already passed.

266
00:11:31,800 --> 00:11:35,800
In 2 minutes, an attacker with a stolen token can do serious damage.

267
00:11:35,800 --> 00:11:39,680
They can read a user's email, they can download their files and they can set up forward

268
00:11:39,680 --> 00:11:41,200
mail rules to themselves.

269
00:11:41,200 --> 00:11:44,440
They can even grant themselves permissions while the sign-in log that's supposed to alert

270
00:11:44,440 --> 00:11:47,400
you to the attack shows up after the damage is already done.

271
00:11:47,400 --> 00:11:49,040
Conditional access is your blocking mechanism.

272
00:11:49,040 --> 00:11:52,840
You create a policy that says if a sign-in is risky, you require MFA.

273
00:11:52,840 --> 00:11:57,760
That sounds good, but the policy takes up to 24 hours to fully propagate to every endpoint.

274
00:11:57,760 --> 00:12:01,960
A risky sign-in that happens today might not be blocked by your new policy until tomorrow

275
00:12:01,960 --> 00:12:05,960
and in the meantime if someone hasn't already triggered the policy, they're in.

276
00:12:05,960 --> 00:12:09,640
And then there's the enforcement gap that's being closed in 2026.

277
00:12:09,640 --> 00:12:13,360
Low privilege OAuth flows, which are the kinds that apps use to request basic directory

278
00:12:13,360 --> 00:12:17,200
access could bypass conditional access policies in certain configurations.

279
00:12:17,200 --> 00:12:20,400
This gap exists right now and it reveals how fragile the model is.

280
00:12:20,400 --> 00:12:22,160
Graph gives you visibility into all of this.

281
00:12:22,160 --> 00:12:26,120
You can see which users are flagged as risky, you can see which sign-ins were risky, and

282
00:12:26,120 --> 00:12:29,720
you can see whether your policies were actually applied, you can even see the risk detections

283
00:12:29,720 --> 00:12:31,240
that triggered the flagging.

284
00:12:31,240 --> 00:12:34,600
But seeing isn't controlling, you're still reactive, you're still looking at data that's

285
00:12:34,600 --> 00:12:37,360
minutes old about events that already happened.

286
00:12:37,360 --> 00:12:38,840
That's the identity illusion.

287
00:12:38,840 --> 00:12:40,640
The application permissions crisis.

288
00:12:40,640 --> 00:12:44,240
Your tenant has 500 applications, maybe more enterprise apps that were installed five

289
00:12:44,240 --> 00:12:48,480
years ago, SaaS tools that different departments requested, custom applications built

290
00:12:48,480 --> 00:12:52,880
by your dev team, integrations with business partners, security connectors that feed data

291
00:12:52,880 --> 00:12:53,880
into your CM.

292
00:12:53,880 --> 00:12:55,600
How many of those do you actually know about?

293
00:12:55,600 --> 00:12:58,760
How many have admin consent and how many of them have permissions that they don't actually

294
00:12:58,760 --> 00:12:59,760
use?

295
00:12:59,760 --> 00:13:04,520
Oauth permissions are the new perimeter, not users, not devices, not locations, applications,

296
00:13:04,520 --> 00:13:07,400
and most organizations have completely lost control of them.

297
00:13:07,400 --> 00:13:08,520
Here's the permission model.

298
00:13:08,520 --> 00:13:12,360
An application requests access to your tenant and asks for specific scopes.

299
00:13:12,360 --> 00:13:17,640
Mail.readright.all means the app can read and write every email in your entire tenant,

300
00:13:17,640 --> 00:13:20,360
not just the user's email, every mailbox.

301
00:13:20,360 --> 00:13:24,960
Directory.readright.all means the app can create users, modify user attributes, change

302
00:13:24,960 --> 00:13:27,520
group memberships and delete accounts.

303
00:13:27,520 --> 00:13:31,800
Files.readright.all means it can read and modify every file in SharePoint and OneDrive

304
00:13:31,800 --> 00:13:33,800
across your entire organization.

305
00:13:33,800 --> 00:13:35,120
Graph exposes all of this.

306
00:13:35,120 --> 00:13:38,440
Service principles, app registrations, permission grants, role assignments.

307
00:13:38,440 --> 00:13:42,680
You can see every application and every permission it has, which allows you to audit the entire

308
00:13:42,680 --> 00:13:43,800
landscape.

309
00:13:43,800 --> 00:13:45,320
But most organizations don't.

310
00:13:45,320 --> 00:13:48,880
The visibility exists in the API is there, but the governance doesn't exist.

311
00:13:48,880 --> 00:13:49,960
And that's the real problem.

312
00:13:49,960 --> 00:13:52,120
There's a specific scenario that happens over and over.

313
00:13:52,120 --> 00:13:56,320
We call it the ghost grant.

314
00:13:56,320 --> 00:14:01,000
Then the department that requested it gets reorganized and the app becomes irrelevant,

315
00:14:01,000 --> 00:14:03,360
someone decommissions it or just stops using it.

316
00:14:03,360 --> 00:14:04,960
But the permission grant stays in place.

317
00:14:04,960 --> 00:14:07,120
It's still in your system and still accessible.

318
00:14:07,120 --> 00:14:09,960
Months later, someone else needs a similar capability.

319
00:14:09,960 --> 00:14:13,400
And because they don't know the old app still exists, they request a new one.

320
00:14:13,400 --> 00:14:17,720
You end up with two apps doing the same job, both with full permissions and both potentially

321
00:14:17,720 --> 00:14:18,720
unused.

322
00:14:18,720 --> 00:14:22,000
Now imagine that decommissioned app gets reactivated by someone who shouldn't have access

323
00:14:22,000 --> 00:14:24,400
to it or imagine its credentials get leaked.

324
00:14:24,400 --> 00:14:27,880
Now you have a dormant permission grant that suddenly active again and you have no idea

325
00:14:27,880 --> 00:14:29,280
it exists.

326
00:14:29,280 --> 00:14:31,800
Permission creep is slower but equally dangerous.

327
00:14:31,800 --> 00:14:35,760
An app launches with minimal permissions like mail.read, which is reasonable because it

328
00:14:35,760 --> 00:14:37,720
just needs to read user email.

329
00:14:37,720 --> 00:14:41,040
Six months later, the vendor releases a new feature that requires writing back to the

330
00:14:41,040 --> 00:14:43,720
user's mailbox, so the app requests mail.read write.

331
00:14:43,720 --> 00:14:45,200
It gets approved because it makes sense.

332
00:14:45,200 --> 00:14:49,400
Then another feature comes out and now it needs access to the user's calendar, then files,

333
00:14:49,400 --> 00:14:51,080
then directory information.

334
00:14:51,080 --> 00:14:54,920
Each request seems reasonable in isolation, but now you have an application that started

335
00:14:54,920 --> 00:15:00,520
with read only email access and has accumulated permissions to read and write email, read calendars,

336
00:15:00,520 --> 00:15:03,280
read files and enumerate your entire directory.

337
00:15:03,280 --> 00:15:06,040
Nobody made a single decision to give it all of those permissions.

338
00:15:06,040 --> 00:15:09,920
It just accumulated them over time and there's no clean audit trail of why each permission

339
00:15:09,920 --> 00:15:10,920
was granted.

340
00:15:10,920 --> 00:15:13,680
The most dangerous permission type is application permissions.

341
00:15:13,680 --> 00:15:17,600
With delegated permissions at least, there's a user context where the app acts on behalf of

342
00:15:17,600 --> 00:15:21,480
a user, but application permissions are different because the app acts as itself.

343
00:15:21,480 --> 00:15:24,480
There's no user signing in and no interactive authentication.

344
00:15:24,480 --> 00:15:27,080
The app authenticates with a client, secret or certificate.

345
00:15:27,080 --> 00:15:31,200
It requests a token, the system issues it and now the app has direct access to your tenant

346
00:15:31,200 --> 00:15:32,960
without any user involvement.

347
00:15:32,960 --> 00:15:35,480
A compromised application secret is catastrophic.

348
00:15:35,480 --> 00:15:39,960
An attacker with that secret can authenticate as the app requests a token and access anything

349
00:15:39,960 --> 00:15:44,320
the app has permission to access your entire mailbox directory, your entire file repository

350
00:15:44,320 --> 00:15:46,840
and your entire user directory are all open.

351
00:15:46,840 --> 00:15:50,720
The user who authorised the application never sees a sign in prompt or anything else because

352
00:15:50,720 --> 00:15:53,080
the attack is purely API based.

353
00:15:53,080 --> 00:15:54,840
Graph gives you the ability to prevent this.

354
00:15:54,840 --> 00:15:59,040
You can inventory all your applications, you can identify which ones have high-risk permissions

355
00:15:59,040 --> 00:16:03,000
and you can determine whether those permissions are actually being used by analysing graph

356
00:16:03,000 --> 00:16:04,320
activity logs.

357
00:16:04,320 --> 00:16:08,200
You can see what each app is doing, you can revoke permissions that aren't needed and

358
00:16:08,200 --> 00:16:12,280
you can delete applications that are no longer in use, but you have to actively use it.

359
00:16:12,280 --> 00:16:13,480
Most organizations don't.

360
00:16:13,480 --> 00:16:16,800
They install applications, they grant permissions and then they forget about them.

361
00:16:16,800 --> 00:16:22,000
Those permissions remain accumulating quietly until something breaks.

362
00:16:22,000 --> 00:16:26,880
Signal versus noise, your SOC team is drowning, not in threats, in alerts.

363
00:16:26,880 --> 00:16:28,600
Thousands of them arrive every day.

364
00:16:28,600 --> 00:16:31,720
Tens of thousands on a busy week, most are false positives.

365
00:16:31,720 --> 00:16:35,960
Low severity events that don't need investigation duplicate alerts for the same issue from different

366
00:16:35,960 --> 00:16:36,960
sources.

367
00:16:36,960 --> 00:16:40,400
Old alerts that never got closed, your team's inbox is a fire hose.

368
00:16:40,400 --> 00:16:42,560
This creates a specific psychological problem.

369
00:16:42,560 --> 00:16:45,640
When your environment is screaming at you constantly, you stop listening.

370
00:16:45,640 --> 00:16:48,800
Alert fatigue, it's documented, it's real.

371
00:16:48,800 --> 00:16:52,680
Your analysts see an alert and their first instinct isn't, what does this mean?

372
00:16:52,680 --> 00:16:55,520
It's is this one of the ones I actually need to care about?

373
00:16:55,520 --> 00:16:59,160
By the time they figure out that 80% of them don't matter, they've already stopped paying

374
00:16:59,160 --> 00:17:00,960
attention to the other 20%.

375
00:17:00,960 --> 00:17:02,680
The critical alerts get lost in the noise.

376
00:17:02,680 --> 00:17:05,240
Graph security API pulls alerts from everywhere.

377
00:17:05,240 --> 00:17:07,880
Defender for endpoint sensor alerts about endpoint threats.

378
00:17:07,880 --> 00:17:11,120
Defender for Office 365 sensor alerts about email threats.

379
00:17:11,120 --> 00:17:14,200
Defender for identity sensor alerts about authentication anomalies.

380
00:17:14,200 --> 00:17:16,360
Defender for cloud apps sends alerts about risky behavior.

381
00:17:16,360 --> 00:17:18,880
Third party security vendors can send alerts too.

382
00:17:18,880 --> 00:17:23,080
It's supposed to be a unified view of everything threatening your organization.

383
00:17:23,080 --> 00:17:24,600
Except they're not unified.

384
00:17:24,600 --> 00:17:25,600
Not really.

385
00:17:25,600 --> 00:17:29,880
A defender for endpoint alert has a different structure than a defender for Office 365 alert.

386
00:17:29,880 --> 00:17:33,080
Different fields, different severity mappings, different category schemes.

387
00:17:33,080 --> 00:17:34,720
Your CM has to normalize them all.

388
00:17:34,720 --> 00:17:36,720
Your automation has to handle the variations.

389
00:17:36,720 --> 00:17:39,320
Your alerting rules have to account for the differences.

390
00:17:39,320 --> 00:17:41,920
Its fragmentation hidden inside an aggregation layer.

391
00:17:41,920 --> 00:17:42,920
Microsoft knows this.

392
00:17:42,920 --> 00:17:48,000
But in 2026, they're moving the entire alert system to alerts V2, a single unified schema.

393
00:17:48,000 --> 00:17:51,360
Legacy alerts are being deprecated by April of 2026.

394
00:17:51,360 --> 00:17:53,520
This forced migration isn't about features.

395
00:17:53,520 --> 00:17:57,120
It's about fixing the structural problem that alerts have become ungovernable.

396
00:17:57,120 --> 00:17:58,160
Graph gives you filtering.

397
00:17:58,160 --> 00:18:01,080
You can filter by severity, status, category or time window.

398
00:18:01,080 --> 00:18:05,160
You can pull only alerts that are critical, only alerts that haven't been resolved.

399
00:18:05,160 --> 00:18:06,920
Only alerts from specific sources.

400
00:18:06,920 --> 00:18:08,200
It sounds like a solution.

401
00:18:08,200 --> 00:18:09,880
Titer filters means less noise, right?

402
00:18:09,880 --> 00:18:10,880
Wrong.

403
00:18:10,880 --> 00:18:13,120
Alerting is a band-aid on a structural problem.

404
00:18:13,120 --> 00:18:15,000
The real issue isn't the alerts you're seeing.

405
00:18:15,000 --> 00:18:16,480
It's the alerts you're seeing at all.

406
00:18:16,480 --> 00:18:18,760
You're still ingesting massive volumes of data.

407
00:18:18,760 --> 00:18:21,520
You're just filtering a downstream instead of filtering it upstream.

408
00:18:21,520 --> 00:18:23,360
That's more expensive, it's slower.

409
00:18:23,360 --> 00:18:25,880
And you're still dealing with the alerts that make it through the filter.

410
00:18:25,880 --> 00:18:26,880
But here's the problem.

411
00:18:26,880 --> 00:18:28,480
The solution isn't better filtering.

412
00:18:28,480 --> 00:18:29,760
It's better reasoning.

413
00:18:29,760 --> 00:18:31,520
You need correlation.

414
00:18:31,520 --> 00:18:33,120
One alert might be meaningless.

415
00:18:33,120 --> 00:18:37,080
But one alert, combined with another alert, combined with a user risk detection, combined

416
00:18:37,080 --> 00:18:38,840
with unusual graph activity.

417
00:18:38,840 --> 00:18:41,120
It's a pattern that's something worth investigating.

418
00:18:41,120 --> 00:18:43,320
Graph has the data to build those correlations.

419
00:18:43,320 --> 00:18:44,320
Risk detections.

420
00:18:44,320 --> 00:18:45,920
User behavioral signals.

421
00:18:45,920 --> 00:18:46,920
Activity logs.

422
00:18:46,920 --> 00:18:48,320
Identity context.

423
00:18:48,320 --> 00:18:51,600
But most organizations ingest the alerts separately from that context.

424
00:18:51,600 --> 00:18:54,120
They filter alerts and ignore the underlying signals.

425
00:18:54,120 --> 00:18:56,000
Then there's enrichment.

426
00:18:56,000 --> 00:19:00,360
An alert arrives, saying, "Account accessed from unusual location.

427
00:19:00,360 --> 00:19:01,360
Useful information.

428
00:19:01,360 --> 00:19:05,840
But if you enriched that alert with, this account is part of the CFO's team.

429
00:19:05,840 --> 00:19:08,960
And the unusual location is a known business partner's office.

430
00:19:08,960 --> 00:19:14,000
Suddenly, the alert becomes either critical, investigate immediately, or authorize travel,

431
00:19:14,000 --> 00:19:15,280
close alert."

432
00:19:15,280 --> 00:19:17,160
The real power isn't filtering alerts.

433
00:19:17,160 --> 00:19:21,520
It's reasoning about them in context, correlating them with other signals, and deciding what

434
00:19:21,520 --> 00:19:22,520
actually matters.

435
00:19:22,520 --> 00:19:23,520
That's where automation comes in.

436
00:19:23,520 --> 00:19:25,560
It's not just about removing humans from the loop.

437
00:19:25,560 --> 00:19:29,240
It's about letting humans focus on actual threats instead of burning out on noise.

438
00:19:29,240 --> 00:19:30,640
The automation gap.

439
00:19:30,640 --> 00:19:32,840
Manual security operations are slow by design.

440
00:19:32,840 --> 00:19:33,920
And alert fires.

441
00:19:33,920 --> 00:19:35,200
One on the team gets notified.

442
00:19:35,200 --> 00:19:36,840
They read the alert which takes time.

443
00:19:36,840 --> 00:19:40,240
They check the context, which means opening other tools and running queries.

444
00:19:40,240 --> 00:19:42,000
They investigate the underlying events.

445
00:19:42,000 --> 00:19:43,800
Then they make a decision about what to do.

446
00:19:43,800 --> 00:19:44,920
Then they take the action.

447
00:19:44,920 --> 00:19:46,440
This entire cycle.

448
00:19:46,440 --> 00:19:48,480
From alert to decision to action.

449
00:19:48,480 --> 00:19:49,760
Tates hours.

450
00:19:49,760 --> 00:19:50,960
Sometimes days.

451
00:19:50,960 --> 00:19:55,200
By the time a human has investigated a risky sign in, that sign in is old news.

452
00:19:55,200 --> 00:19:58,560
The attacker is already gone, or already deeper into the system.

453
00:19:58,560 --> 00:20:00,560
Graph enables a fundamentally different model.

454
00:20:00,560 --> 00:20:01,840
You ingest alerts automatically.

455
00:20:01,840 --> 00:20:03,480
You evaluate the risk programmatically.

456
00:20:03,480 --> 00:20:07,040
You trigger remediation actions without waiting for human to review the alert.

457
00:20:07,040 --> 00:20:08,400
The entire cycle.

458
00:20:08,400 --> 00:20:10,440
From event to decision to action.

459
00:20:10,440 --> 00:20:11,520
Happens in seconds.

460
00:20:11,520 --> 00:20:12,520
Not hours.

461
00:20:12,520 --> 00:20:13,600
Seconds.

462
00:20:13,600 --> 00:20:15,960
But here's where most organizations get stuck.

463
00:20:15,960 --> 00:20:17,040
Automation requires governance.

464
00:20:17,040 --> 00:20:19,000
And governance is where the real complexity lives.

465
00:20:19,000 --> 00:20:22,440
If you automate the wrong action, you can cause serious damage.

466
00:20:22,440 --> 00:20:24,880
Disable a user account automatically because of a risky sign in.

467
00:20:24,880 --> 00:20:27,760
Now you've locked out a legitimate user who is just traveling.

468
00:20:27,760 --> 00:20:29,120
They can't access their email.

469
00:20:29,120 --> 00:20:30,120
They can't do their job.

470
00:20:30,120 --> 00:20:33,360
Meanwhile, the attacker is still in the system, just in a different account.

471
00:20:33,360 --> 00:20:35,600
You've heard the business and missed the threat.

472
00:20:35,600 --> 00:20:38,120
Revoque all tokens for an account with a risky activity.

473
00:20:38,120 --> 00:20:39,680
That sounds smart.

474
00:20:39,680 --> 00:20:43,400
But if you do it automatically without any approval gate, you might revoke tokens for

475
00:20:43,400 --> 00:20:46,040
legitimate background services that user relies on.

476
00:20:46,040 --> 00:20:47,960
Those services stop working.

477
00:20:47,960 --> 00:20:48,960
Integrations break.

478
00:20:48,960 --> 00:20:50,360
Data pipelines fail.

479
00:20:50,360 --> 00:20:54,840
The automation that most organizations implement is low risk, triage and enrichment.

480
00:20:54,840 --> 00:20:59,200
An alert comes in, automatically pull the user's risk history, check their role, look up

481
00:20:59,200 --> 00:21:01,960
what team they're on and add that context to the alert.

482
00:21:01,960 --> 00:21:05,360
Now when a human analyst looks at it, they have the background information ready.

483
00:21:05,360 --> 00:21:07,520
This automation is safe, it can't break anything.

484
00:21:07,520 --> 00:21:12,080
It just makes the humans job easier, but low risk automation doesn't solve the speed problem.

485
00:21:12,080 --> 00:21:15,000
You're still waiting for a human to review before anything happens.

486
00:21:15,000 --> 00:21:17,320
Medium risk automation is different.

487
00:21:17,320 --> 00:21:21,080
When an alert fires, automatically disable the user's sign in capability.

488
00:21:21,080 --> 00:21:22,560
Revoque their active sessions.

489
00:21:22,560 --> 00:21:25,160
Forse of password reset, these actions are reversible.

490
00:21:25,160 --> 00:21:27,440
If you did it by mistake, you can undo it.

491
00:21:27,440 --> 00:21:29,160
But they require governance.

492
00:21:29,160 --> 00:21:30,440
You need approval workflows.

493
00:21:30,440 --> 00:21:34,000
You need role-based access control around who can trigger these automations.

494
00:21:34,000 --> 00:21:37,880
You need safety gates that prevent the same account from being disabled twice in an hour,

495
00:21:37,880 --> 00:21:39,640
which might indicate a buggy automation.

496
00:21:39,640 --> 00:21:41,760
High-risk automation is destructive.

497
00:21:41,760 --> 00:21:43,160
Disable an application entirely.

498
00:21:43,160 --> 00:21:44,320
Delete a service principle.

499
00:21:44,320 --> 00:21:46,240
Permanently revoke permissions.

500
00:21:46,240 --> 00:21:48,080
These actions can't be reversed easily.

501
00:21:48,080 --> 00:21:49,600
They require multiple approvals.

502
00:21:49,600 --> 00:21:50,680
They require audit trails.

503
00:21:50,680 --> 00:21:52,880
They require investigation.

504
00:21:52,880 --> 00:21:55,440
Most organizations never implement high-risk automation.

505
00:21:55,440 --> 00:21:58,080
They stick with level one and maybe dabble in level two.

506
00:21:58,080 --> 00:21:59,960
Graph gives you the APIs for all three levels.

507
00:21:59,960 --> 00:22:03,600
The real challenge is the governance infrastructure around levels two and three.

508
00:22:03,600 --> 00:22:07,560
You need to think about safety, reversibility, approval chains and audit trails.

509
00:22:07,560 --> 00:22:10,280
Most organizations don't have that infrastructure built yet.

510
00:22:10,280 --> 00:22:12,040
But here's the actual insight.

511
00:22:12,040 --> 00:22:13,720
Automation isn't about removing humans.

512
00:22:13,720 --> 00:22:15,160
It's about removing delay.

513
00:22:15,160 --> 00:22:16,840
Humans still make the critical decisions.

514
00:22:16,840 --> 00:22:19,440
But they make them faster because the supporting data is ready.

515
00:22:19,440 --> 00:22:21,600
They don't have to spend 30 minutes investigating.

516
00:22:21,600 --> 00:22:24,640
They spend 30 seconds reviewing what's already been enriched.

517
00:22:24,640 --> 00:22:27,680
Then they approve or deny the proposed action.

518
00:22:27,680 --> 00:22:30,520
Data activity logs show you whether your automations are working.

519
00:22:30,520 --> 00:22:32,280
You can see every API call.

520
00:22:32,280 --> 00:22:35,320
You can verify that your remediation workflows are actually triggering.

521
00:22:35,320 --> 00:22:38,720
You can catch bugs or misconfigurations before they cause problems.

522
00:22:38,720 --> 00:22:41,760
And if an attacker is abusing graph, you can see that too.

523
00:22:41,760 --> 00:22:43,240
The latency reality.

524
00:22:43,240 --> 00:22:46,640
You think Microsoft Graph gives you real-time security data.

525
00:22:46,640 --> 00:22:49,560
Real-time alerts, real-time visibility, real-time response.

526
00:22:49,560 --> 00:22:50,560
Real-time is a myth.

527
00:22:50,560 --> 00:22:53,760
Audit logs usually have a two to five-minute latency.

528
00:22:53,760 --> 00:22:54,760
Configuration changes.

529
00:22:54,760 --> 00:22:55,760
Admin actions.

530
00:22:55,760 --> 00:22:56,760
Mailbox access.

531
00:22:56,760 --> 00:22:59,120
Everything gets recorded, but there is always a delay.

532
00:22:59,120 --> 00:23:02,920
Your audit trail is accurate and complete, but it is always looking at the past.

533
00:23:02,920 --> 00:23:03,920
Security alerts are even worse.

534
00:23:03,920 --> 00:23:07,160
The latency isn't consistent because alerts come from different sources.

535
00:23:07,160 --> 00:23:11,840
A defender for endpoint alert might show up within seconds if a device sends it immediately.

536
00:23:11,840 --> 00:23:16,280
But a defender for Office 365 alert might take minutes while the email gets analyzed.

537
00:23:16,280 --> 00:23:20,840
A cloud app security alert might take even longer, as behavioral patterns get evaluated.

538
00:23:20,840 --> 00:23:23,120
You have no idea if an alert is stale when it arrives.

539
00:23:23,120 --> 00:23:27,120
There is a technology called continuous access evaluation that can help with tokens.

540
00:23:27,120 --> 00:23:31,720
If a user's risk level spikes and they get flagged as risky, CIE can revoke their tokens

541
00:23:31,720 --> 00:23:33,480
in near real-time.

542
00:23:33,480 --> 00:23:34,640
Up to 15 minutes.

543
00:23:34,640 --> 00:23:37,160
Not instantly, not even close to instant, but close.

544
00:23:37,160 --> 00:23:40,640
The catch is that most organizations haven't enabled CIE, so they don't get that capability

545
00:23:40,640 --> 00:23:41,640
at all.

546
00:23:41,640 --> 00:23:42,920
Policy changes propagate slowly.

547
00:23:42,920 --> 00:23:45,520
You create a new conditional access policy and enable it.

548
00:23:45,520 --> 00:23:47,920
You think it is now protecting every sign in your tenant.

549
00:23:47,920 --> 00:23:49,080
But that is not how it works.

550
00:23:49,080 --> 00:23:54,400
The policy has to replicate to every authentication server and every cloud region where sign-ins happen.

551
00:23:54,400 --> 00:23:55,800
That replication takes time.

552
00:23:55,800 --> 00:23:57,960
Up to 24 hours for complete propagation.

553
00:23:57,960 --> 00:23:59,960
So here is the actual operational reality.

554
00:23:59,960 --> 00:24:02,480
You cannot design your security around real-time graph data.

555
00:24:02,480 --> 00:24:06,320
You cannot assume that by the time you see an event, you can still prevent it.

556
00:24:06,320 --> 00:24:07,680
The event has already happened.

557
00:24:07,680 --> 00:24:09,360
The tokens have already been issued.

558
00:24:09,360 --> 00:24:11,040
The permissions have already been granted.

559
00:24:11,040 --> 00:24:13,640
You are always responding to something that is already in motion.

560
00:24:13,640 --> 00:24:15,960
This isn't a technical limitation that will be fixed.

561
00:24:15,960 --> 00:24:17,280
This is structural.

562
00:24:17,280 --> 00:24:18,680
Distributed systems have latency.

563
00:24:18,680 --> 00:24:19,800
There is no way around it.

564
00:24:19,800 --> 00:24:23,280
The design principle that actually works is defense in depth.

565
00:24:23,280 --> 00:24:24,880
Not perfect real-time blocking.

566
00:24:24,880 --> 00:24:26,760
Not catching every threat the moment it starts.

567
00:24:26,760 --> 00:24:29,880
But layered controls that limit damage, even if one layer is breached.

568
00:24:29,880 --> 00:24:32,080
A user signs in from an unusual location.

569
00:24:32,080 --> 00:24:33,880
You don't see that sign in for five minutes.

570
00:24:33,880 --> 00:24:37,520
The token is now active and usable for five minutes without any extra controls.

571
00:24:37,520 --> 00:24:39,320
So you need a second layer.

572
00:24:39,320 --> 00:24:42,120
Conditional access policies that evaluate context continuously.

573
00:24:42,120 --> 00:24:45,720
Or CIE that can revoke the token if new risk information emerges.

574
00:24:45,720 --> 00:24:49,200
Your application level checks that re-evaluate whether the user still has access.

575
00:24:49,200 --> 00:24:50,200
An app gets over-privileged.

576
00:24:50,200 --> 00:24:53,080
By the time you audit it, it has been over-privileged for months.

577
00:24:53,080 --> 00:24:55,960
So you need monitoring that catches unexpected behavior.

578
00:24:55,960 --> 00:24:59,160
Graph activity logs that show the app doing something it has never done before.

579
00:24:59,160 --> 00:25:02,400
Alerts that fire when an app makes unusual bulk requests.

580
00:25:02,400 --> 00:25:06,880
These alerts might have minutes of latency, but they catch the behavior while it is happening.

581
00:25:06,880 --> 00:25:10,640
The organizations that use Graph effectively don't build systems that depend on real-time

582
00:25:10,640 --> 00:25:11,640
data.

583
00:25:11,640 --> 00:25:14,880
They build systems that assume latency and design for resilience.

584
00:25:14,880 --> 00:25:16,040
They layer their controls.

585
00:25:16,040 --> 00:25:18,200
They accept that detection will take minutes.

586
00:25:18,200 --> 00:25:21,480
They focus on making sure that even with those minutes of delay, they can still limit

587
00:25:21,480 --> 00:25:23,120
the blast radius.

588
00:25:23,120 --> 00:25:25,640
Risky users as a continuous signal.

589
00:25:25,640 --> 00:25:29,040
Identity protection is running in the background of your Entra ID right now.

590
00:25:29,040 --> 00:25:31,800
Machine learning models are analyzing every sign in.

591
00:25:31,800 --> 00:25:35,040
They are looking for patterns that don't match normal behavior.

592
00:25:35,040 --> 00:25:36,040
Impossible travel.

593
00:25:36,040 --> 00:25:39,560
A user signs in from New York, then from London three minutes later.

594
00:25:39,560 --> 00:25:40,840
Malware linked IPs.

595
00:25:40,840 --> 00:25:45,600
A sign in came from an IP address known to host botnet activity, leaked credentials.

596
00:25:45,600 --> 00:25:49,680
The users password appeared in a breach database on the dark web, atypical behavior.

597
00:25:49,680 --> 00:25:53,520
The user just accessed files they have never touched before at 3am on a Sunday.

598
00:25:53,520 --> 00:25:56,960
These signals flow into Graph through the identity protection APIs.

599
00:25:56,960 --> 00:25:58,320
You can query risky users.

600
00:25:58,320 --> 00:25:59,600
You can look at risky signings.

601
00:25:59,600 --> 00:26:02,400
You can examine the raw risk detections that triggered the flagging.

602
00:26:02,400 --> 00:26:03,400
The data is there.

603
00:26:03,400 --> 00:26:04,400
Continuous.

604
00:26:04,400 --> 00:26:05,400
Streaming.

605
00:26:05,400 --> 00:26:06,400
You see it a few minutes after it happened, but you see it.

606
00:26:06,400 --> 00:26:10,040
Here is the critical insight that most organizations miss.

607
00:26:10,040 --> 00:26:11,240
Risk isn't binary.

608
00:26:11,240 --> 00:26:13,920
A user isn't either safe or compromised.

609
00:26:13,920 --> 00:26:15,920
Risk is probabilistic, continuous.

610
00:26:15,920 --> 00:26:20,440
A user can go from no risk to at risk based on a single event, then they can get remediated

611
00:26:20,440 --> 00:26:22,240
and return to no risk.

612
00:26:22,240 --> 00:26:25,960
Then they can drift back into at risk as more suspicious events accumulate.

613
00:26:25,960 --> 00:26:26,960
It is not a state.

614
00:26:26,960 --> 00:26:27,960
It is a signal.

615
00:26:27,960 --> 00:26:29,240
And that signal changes constantly.

616
00:26:29,240 --> 00:26:34,120
The practical model is treating risk detections as a continuous stream that you are always monitoring.

617
00:26:34,120 --> 00:26:35,920
A user gets flagged as risky.

618
00:26:35,920 --> 00:26:37,760
You have visibility into why.

619
00:26:37,760 --> 00:26:39,160
What detection triggered it?

620
00:26:39,160 --> 00:26:42,480
A possible travel, leaked credentials, a typical file access.

621
00:26:42,480 --> 00:26:43,880
Graph gives you that granularity.

622
00:26:43,880 --> 00:26:45,680
You can list all risky users right now.

623
00:26:45,680 --> 00:26:47,480
You can filter them by risk level.

624
00:26:47,480 --> 00:26:51,720
You can pull the complete history of risk events for a specific user and see how their

625
00:26:51,720 --> 00:26:52,960
risk has evolved.

626
00:26:52,960 --> 00:26:54,640
This is where automation becomes valuable.

627
00:26:54,640 --> 00:26:58,800
When a user's risk level crosses a threshold, you can trigger a response without waiting for

628
00:26:58,800 --> 00:27:00,080
human to notice.

629
00:27:00,080 --> 00:27:01,800
Force them to reauthenticate with MFA.

630
00:27:01,800 --> 00:27:03,200
Require a password reset.

631
00:27:03,200 --> 00:27:05,600
Block their sign in entirely pending investigation.

632
00:27:05,600 --> 00:27:06,600
But here is the catch.

633
00:27:06,600 --> 00:27:07,840
You have to be careful.

634
00:27:07,840 --> 00:27:10,720
Risk detection models are good, but they are not perfect.

635
00:27:10,720 --> 00:27:11,920
False positives happen.

636
00:27:11,920 --> 00:27:15,680
An executive traveling internationally might trip impossible travel detections.

637
00:27:15,680 --> 00:27:19,840
Someone whose password was leaked in a breach they didn't cause might get flagged.

638
00:27:19,840 --> 00:27:23,520
If your automation disables every flagged user immediately without any approval gate,

639
00:27:23,520 --> 00:27:25,120
you will break legitimate users.

640
00:27:25,120 --> 00:27:27,280
The 2026 shift is important here.

641
00:27:27,280 --> 00:27:30,280
Microsoft is improving the ML models that power risk detection.

642
00:27:30,280 --> 00:27:31,920
They are adding new detection types.

643
00:27:31,920 --> 00:27:33,480
The signal is getting richer.

644
00:27:33,480 --> 00:27:36,600
But that also means your automation logic needs to adapt.

645
00:27:36,600 --> 00:27:39,720
A detection type that didn't exist last year might exist next year.

646
00:27:39,720 --> 00:27:42,360
Your automation needs to handle new signals gracefully.

647
00:27:42,360 --> 00:27:44,160
The real inside is something subtle.

648
00:27:44,160 --> 00:27:45,960
Risky users aren't security incidents.

649
00:27:45,960 --> 00:27:49,320
They are signals that warrant investigation and potentially remediation.

650
00:27:49,320 --> 00:27:52,320
A user flagged as risky isn't necessarily compromised.

651
00:27:52,320 --> 00:27:55,880
They are someone who exhibited behavior that the system flagged as unusual.

652
00:27:55,880 --> 00:27:59,800
Your job is to decide whether that unusual behavior is actually malicious or just normal

653
00:27:59,800 --> 00:28:00,800
variance.

654
00:28:00,800 --> 00:28:02,120
That decision requires context.

655
00:28:02,120 --> 00:28:03,280
It requires investigation.

656
00:28:03,280 --> 00:28:05,600
It requires a human applying judgment.

657
00:28:05,600 --> 00:28:08,880
This gives you the visibility and the API is to investigate quickly.

658
00:28:08,880 --> 00:28:12,560
You are not waiting for a security analyst to manually pull logs from five different places

659
00:28:12,560 --> 00:28:13,960
and piece together a timeline.

660
00:28:13,960 --> 00:28:14,960
You have a unified signal.

661
00:28:14,960 --> 00:28:16,680
You can see the risk detection.

662
00:28:16,680 --> 00:28:18,000
You can see the supporting events.

663
00:28:18,000 --> 00:28:19,680
You can make a decision.

664
00:28:19,680 --> 00:28:22,040
Conditional access as programmable policy.

665
00:28:22,040 --> 00:28:24,000
Conditional access is whether rubber meets the road.

666
00:28:24,000 --> 00:28:25,720
It is the actual enforcement mechanism.

667
00:28:25,720 --> 00:28:30,120
When a user tries to sign in or an app requests a token, conditional access is the engine

668
00:28:30,120 --> 00:28:31,680
that decides the outcome.

669
00:28:31,680 --> 00:28:32,680
Allow the request.

670
00:28:32,680 --> 00:28:33,880
Block the request.

671
00:28:33,880 --> 00:28:35,320
Require MFA first.

672
00:28:35,320 --> 00:28:36,480
And here is the problem.

673
00:28:36,480 --> 00:28:38,720
This is where most security thinking breaks down.

674
00:28:38,720 --> 00:28:42,120
Most organizations build their policies in the portal using a point and click approach.

675
00:28:42,120 --> 00:28:47,280
They set rules like requiring MFA for unknown locations or blocking access when sign-in-risk

676
00:28:47,280 --> 00:28:48,360
is high.

677
00:28:48,360 --> 00:28:51,280
Because you can see these policies and modify them manually.

678
00:28:51,280 --> 00:28:53,240
They feel like they are working.

679
00:28:53,240 --> 00:28:56,720
The flaw is that organizations treat these policies as static objects.

680
00:28:56,720 --> 00:29:00,040
You create a rule, enable it and assume it protects you forever.

681
00:29:00,040 --> 00:29:02,640
But in reality, conditional access works differently.

682
00:29:02,640 --> 00:29:06,840
Every time a user signs in, the engine evaluates that request against every single policy you

683
00:29:06,840 --> 00:29:07,840
have created.

684
00:29:07,840 --> 00:29:10,560
This does not happen in your portal or on your own servers.

685
00:29:10,560 --> 00:29:12,880
It happens inside the authentication pipeline.

686
00:29:12,880 --> 00:29:17,320
The engine looks at the context, the person, the app, the location, the device and the

687
00:29:17,320 --> 00:29:20,160
risk level and makes a decision in milliseconds.

688
00:29:20,160 --> 00:29:21,920
That is where graph changes the model.

689
00:29:21,920 --> 00:29:26,960
Graph exposes these policies through the identity endpoint, allowing you to list, create, update

690
00:29:26,960 --> 00:29:28,680
or delete them programmatically.

691
00:29:28,680 --> 00:29:31,680
Anything you can do in the portal, you can now do a scale through code.

692
00:29:31,680 --> 00:29:35,240
This means you can build automations that respond to threats faster than any human admin

693
00:29:35,240 --> 00:29:36,240
could.

694
00:29:36,240 --> 00:29:40,040
And one level deeper, there is a critical architectural gap you need to understand.

695
00:29:40,040 --> 00:29:44,560
While the evaluation of a sign-in happens in milliseconds, policy propagation is slow.

696
00:29:44,560 --> 00:29:49,280
When you update a policy via the API or the portal, it can take up to 24 hours to reach

697
00:29:49,280 --> 00:29:50,920
every authentication endpoint.

698
00:29:50,920 --> 00:29:54,680
This creates a window where a new policy exists, but some sign-ins are not yet being checked

699
00:29:54,680 --> 00:29:55,680
against it.

700
00:29:55,680 --> 00:29:59,800
By 26, Microsoft is closing a specific hole in this enforcement model.

701
00:29:59,800 --> 00:30:03,520
Currently, low-privileged flows that only ask for basic directory access can sometimes

702
00:30:03,520 --> 00:30:05,520
bypass certain configurations.

703
00:30:05,520 --> 00:30:09,640
The new structural fix ensures that every flow, even the smallest ones, must answer to

704
00:30:09,640 --> 00:30:12,240
policies targeting all resources.

705
00:30:12,240 --> 00:30:14,720
Conditional access generally makes one of three decisions.

706
00:30:14,720 --> 00:30:18,000
It blocks the sign-in, it allows the sign-in, it demands more proof.

707
00:30:18,000 --> 00:30:22,080
Those extra controls might be MFA, a compliant device or a password reset.

708
00:30:22,080 --> 00:30:25,880
You can even combine them, like blocking access unless a user has a managed device and

709
00:30:25,880 --> 00:30:27,800
uses passwordless sign-in.

710
00:30:27,800 --> 00:30:31,720
Microsoft also includes the "what if" API, since it is currently in beta, the details might

711
00:30:31,720 --> 00:30:34,200
shift, but the core function is powerful.

712
00:30:34,200 --> 00:30:37,560
It lets you simulate a decision without anyone actually signing in.

713
00:30:37,560 --> 00:30:42,800
You provide a hypothetical scenario, a specific user, device, and app, and the API tells you

714
00:30:42,800 --> 00:30:44,240
exactly what would happen.

715
00:30:44,240 --> 00:30:48,320
This prevents the nightmare scenario where a small mistake in a policy locks out your entire

716
00:30:48,320 --> 00:30:49,320
company.

717
00:30:49,320 --> 00:30:50,800
The automation potential here is massive.

718
00:30:50,800 --> 00:30:54,200
Instead of clicking through the portal, you can update your security posture in response

719
00:30:54,200 --> 00:30:55,360
to real events.

720
00:30:55,360 --> 00:31:00,040
If a user's risk level spikes, your system can automatically trigger a policy that requires

721
00:31:00,040 --> 00:31:02,280
MFA for just that person.

722
00:31:02,280 --> 00:31:06,120
If an insider threat is detected, you can block access to sensitive data instantly.

723
00:31:06,120 --> 00:31:08,400
But here is where governance becomes critical.

724
00:31:08,400 --> 00:31:09,880
Conditional access is a blunt instrument.

725
00:31:09,880 --> 00:31:12,960
If you block the wrong condition, you stop legitimate work.

726
00:31:12,960 --> 00:31:17,120
If you require device compliance before your fleet is ready, you break the business.

727
00:31:17,120 --> 00:31:18,960
These mistakes do not just hurt security.

728
00:31:18,960 --> 00:31:21,040
They paralyze operations.

729
00:31:21,040 --> 00:31:23,000
The real insight is this.

730
00:31:23,000 --> 00:31:25,680
Real access is your structural enforcement layer.

731
00:31:25,680 --> 00:31:27,840
Graph is the programmable interface to that layer.

732
00:31:27,840 --> 00:31:32,760
Together they allow you to move away from static rules and toward a system that evolves

733
00:31:32,760 --> 00:31:34,920
as the threat landscape changes.

734
00:31:34,920 --> 00:31:37,640
The audit log model, audit logs are your forensic records.

735
00:31:37,640 --> 00:31:40,320
They capture the truth of what happened in your tenant.

736
00:31:40,320 --> 00:31:44,880
Every sign-in, every admin action, every configuration drift, from file access to mailbox

737
00:31:44,880 --> 00:31:47,520
forwarding rules, every change is documented.

738
00:31:47,520 --> 00:31:51,680
Graph exposes these logs through specific endpoints for sign-ins and directory audits.

739
00:31:51,680 --> 00:31:55,840
There is also the newer purview audit search API, which is the direction Microsoft is pushing

740
00:31:55,840 --> 00:31:56,840
everyone toward.

741
00:31:56,840 --> 00:32:01,080
By 26, the legacy ways of accessing these logs will be gone and everything will live inside

742
00:32:01,080 --> 00:32:02,320
graph and purview.

743
00:32:02,320 --> 00:32:06,480
What makes audit logs valuable is that they are a complete historical record.

744
00:32:06,480 --> 00:32:10,880
Unlike real-time systems that might drop data to keep up with speed, audit logs keep everything.

745
00:32:10,880 --> 00:32:15,120
When you need to investigate a user six months after an incident, the data is still there.

746
00:32:15,120 --> 00:32:17,560
You can reconstruct every move they made during that window.

747
00:32:17,560 --> 00:32:19,280
But that completeness comes with a trade-off.

748
00:32:19,280 --> 00:32:22,080
The latency we see in other systems exists here too.

749
00:32:22,080 --> 00:32:25,000
Audit logs usually appear in graph with a delay of 2-5 minutes.

750
00:32:25,000 --> 00:32:27,000
This means you are always looking at the past.

751
00:32:27,000 --> 00:32:32,000
For forensics, a 5-minute delay is fine, but for catching an active attack, it is too slow.

752
00:32:32,000 --> 00:32:33,920
You do not use these logs to stop a thief.

753
00:32:33,920 --> 00:32:35,760
You use them to see what they stole.

754
00:32:35,760 --> 00:32:37,720
The volume of data is the next big hurdle.

755
00:32:37,720 --> 00:32:41,280
A large organization can generate millions of events every single day.

756
00:32:41,280 --> 00:32:45,560
Every time someone checks an email or a policy is evaluated, a new line is written.

757
00:32:45,560 --> 00:32:48,440
Ingesting and storing all of that is incredibly expensive.

758
00:32:48,440 --> 00:32:51,200
So what is actually happening is a shift in strategy.

759
00:32:51,200 --> 00:32:54,200
The practical approach is to stop trying to ingest everything.

760
00:32:54,200 --> 00:32:58,200
You have to filter at the source and focus only on the events that actually matter.

761
00:32:58,200 --> 00:33:03,000
Failed sign-ins, role assignments, policy changes, privilege escalations.

762
00:33:03,000 --> 00:33:05,920
These are the signals that indicate a real security impact.

763
00:33:05,920 --> 00:33:09,560
Everything else is just noise that clatters your database and inflates your bill.

764
00:33:09,560 --> 00:33:11,560
Graph uses ODITA filtering to help with this.

765
00:33:11,560 --> 00:33:16,000
You can ask the API for failed sign-ins from high-privileged users over the last hour or

766
00:33:16,000 --> 00:33:20,440
at-min actions from the last 30 days because the filtering happens on Microsoft's side.

767
00:33:20,440 --> 00:33:23,600
You aren't pulling millions of useless rows into your own environment.

768
00:33:23,600 --> 00:33:25,200
You only get what you asked for.

769
00:33:25,200 --> 00:33:28,600
The shift coming in 26 is a hard deadline for your infrastructure.

770
00:33:28,600 --> 00:33:30,400
Microsoft is retiring the old audit APIs.

771
00:33:30,400 --> 00:33:34,320
If your current automation or compliance tools are still relying on those legacy endpoints,

772
00:33:34,320 --> 00:33:35,320
they will stop working.

773
00:33:35,320 --> 00:33:38,480
Moving to the graph-based per view API is no longer a suggestion.

774
00:33:38,480 --> 00:33:39,640
It is a requirement.

775
00:33:39,640 --> 00:33:44,200
The structural reality is that audit logs are a forensic tool, not a detection tool.

776
00:33:44,200 --> 00:33:46,440
They are reliable and essential for compliance.

777
00:33:46,440 --> 00:33:49,680
They tell you how an attacker got in, they show you what data was touched.

778
00:33:49,680 --> 00:33:51,560
They provide the evidence for legal teams.

779
00:33:51,560 --> 00:33:55,400
But because of that two to five-minute delay, they cannot be your first line of defense.

780
00:33:55,400 --> 00:33:57,560
You need other tools for real-time response.

781
00:33:57,560 --> 00:34:01,440
Audit logs are for the moments when you have to look backward and ask what actually happened.

782
00:34:01,440 --> 00:34:04,400
Graph activity logs as your API visibility layer.

783
00:34:04,400 --> 00:34:07,880
There is a layer of visibility that most organizations completely miss.

784
00:34:07,880 --> 00:34:11,120
It isn't because the data doesn't exist, it's because they don't know where to look.

785
00:34:11,120 --> 00:34:13,680
Every time an application calls Microsoft Graph.

786
00:34:13,680 --> 00:34:17,400
Every request, every operation, every attempt to touch your data, it gets logged.

787
00:34:17,400 --> 00:34:21,960
The app identity, the endpoint, the timestamp, the IP address, the specific data it tried

788
00:34:21,960 --> 00:34:25,320
to reach, whether it worked or failed, how long it took, everything.

789
00:34:25,320 --> 00:34:26,480
This is Graph activity logs.

790
00:34:26,480 --> 00:34:30,200
It is the most powerful tool you have to see what applications are actually doing inside

791
00:34:30,200 --> 00:34:31,200
your tenant.

792
00:34:31,200 --> 00:34:32,200
Think about the implications.

793
00:34:32,200 --> 00:34:36,400
You have an app that requested mail, read right all, that is a dangerous scope.

794
00:34:36,400 --> 00:34:39,800
You approved it because the vendor claimed they needed it for the tool to work.

795
00:34:39,800 --> 00:34:41,280
But what if they never use it?

796
00:34:41,280 --> 00:34:44,800
What if they are just hoarding permissions just in case?

797
00:34:44,800 --> 00:34:45,960
Graph activity logs give you the truth.

798
00:34:45,960 --> 00:34:49,840
You can see every single API call that app makes and if it never touches that mail scope,

799
00:34:49,840 --> 00:34:51,040
you can see that clearly.

800
00:34:51,040 --> 00:34:53,440
You can revoke the access, you can reduce the scope.

801
00:34:53,440 --> 00:34:56,760
You can eliminate exposure that never should have been there in the first place.

802
00:34:56,760 --> 00:34:59,400
Now look at the other side, an app gets compromised.

803
00:34:59,400 --> 00:35:01,120
An attacker has the credentials.

804
00:35:01,120 --> 00:35:02,920
They are using that app to steal your data.

805
00:35:02,920 --> 00:35:04,160
What does that look like in the logs?

806
00:35:04,160 --> 00:35:05,800
It looks like a broken pattern.

807
00:35:05,800 --> 00:35:09,720
An app that usually makes 10 calls a day is suddenly making 10,000.

808
00:35:09,720 --> 00:35:12,760
An app that normally reads one mailbox is suddenly scanning 50.

809
00:35:12,760 --> 00:35:16,760
A service that only runs during business hours is suddenly active at 3am.

810
00:35:16,760 --> 00:35:19,320
These patterns show up in the logs almost immediately.

811
00:35:19,320 --> 00:35:22,200
It is near real time visibility into an active attack.

812
00:35:22,200 --> 00:35:23,240
The volume is the challenge.

813
00:35:23,240 --> 00:35:27,680
A large organization with heavy graph usage can generate millions of log entries every single

814
00:35:27,680 --> 00:35:28,680
day.

815
00:35:28,680 --> 00:35:30,160
You cannot process that scale manually.

816
00:35:30,160 --> 00:35:33,840
You need automation to ingest it, filter it, and tell you when something is wrong.

817
00:35:33,840 --> 00:35:36,760
The right approach is to build filtering on top of the raw feed.

818
00:35:36,760 --> 00:35:38,360
Do not try to look at every request.

819
00:35:38,360 --> 00:35:40,640
Instead look for the patterns that actually matter.

820
00:35:40,640 --> 00:35:44,960
High volume spikes from a single app, activity from an ID you don't recognize.

821
00:35:44,960 --> 00:35:47,520
Request to endpoints that the app has no business touching.

822
00:35:47,520 --> 00:35:50,480
These patterns surface the risk without drowning your team in noise.

823
00:35:50,480 --> 00:35:52,400
You should ingest these logs into your CM.

824
00:35:52,400 --> 00:35:56,640
When your CM correlates graph activity logs with other signals, the picture gets clear.

825
00:35:56,640 --> 00:36:01,280
A spike in failed graph calls combined with identity risk detections isn't just a glitch.

826
00:36:01,280 --> 00:36:02,280
It's a story.

827
00:36:02,280 --> 00:36:05,600
The story might be a credential compromise or it might just be a misconfigured app,

828
00:36:05,600 --> 00:36:08,280
but the correlation makes it something you can actually act on.

829
00:36:08,280 --> 00:36:10,440
The data lake approach is for the long term.

830
00:36:10,440 --> 00:36:12,760
You store the raw logs for months or years.

831
00:36:12,760 --> 00:36:16,800
When an incident finally happens and you need to investigate what an attacker did six months

832
00:36:16,800 --> 00:36:18,560
ago, you have the record.

833
00:36:18,560 --> 00:36:22,720
You can pull the history for a specific app and see exactly what it accessed and how much

834
00:36:22,720 --> 00:36:23,720
data it took.

835
00:36:23,720 --> 00:36:25,720
There is a distinction here that matters.

836
00:36:25,720 --> 00:36:28,000
Audit logs tell you what happened in your services.

837
00:36:28,000 --> 00:36:29,000
A user opened a file.

838
00:36:29,000 --> 00:36:30,320
A mailbox was accessed.

839
00:36:30,320 --> 00:36:31,920
A policy changed.

840
00:36:31,920 --> 00:36:35,200
Graph activity logs tell you how it happened, which app made the call.

841
00:36:35,200 --> 00:36:37,240
What it requested, what the response was.

842
00:36:37,240 --> 00:36:40,800
What is the difference between knowing a theft happened and knowing exactly how the thief

843
00:36:40,800 --> 00:36:42,080
moved through the house?

844
00:36:42,080 --> 00:36:43,840
The structural insight is simple.

845
00:36:43,840 --> 00:36:45,840
Portals show you the surface of M365.

846
00:36:45,840 --> 00:36:49,640
They show you users and files, but they don't show you the API layer underneath.

847
00:36:49,640 --> 00:36:51,240
Graph activity logs close that gap.

848
00:36:51,240 --> 00:36:52,960
They are your window into the engine room.

849
00:36:52,960 --> 00:36:56,800
They allow you to govern the entire ecosystem of applications that depend on graph rather

850
00:36:56,800 --> 00:36:58,640
than just the settings in a dashboard.

851
00:36:58,640 --> 00:37:00,920
OAuth permissions as your real perimeter.

852
00:37:00,920 --> 00:37:02,360
Your perimeter isn't a firewall.

853
00:37:02,360 --> 00:37:03,680
It isn't your network boundary.

854
00:37:03,680 --> 00:37:06,040
Your real perimeter is OAuth permissions.

855
00:37:06,040 --> 00:37:09,680
Think about what happens when an app gets permissions in your tenant, Mail Read Write.

856
00:37:09,680 --> 00:37:11,680
All doesn't mean the app can read one person's mail.

857
00:37:11,680 --> 00:37:16,240
It means it can read and write every single email in your entire organization.

858
00:37:16,240 --> 00:37:17,560
Thousands of mailboxes.

859
00:37:17,560 --> 00:37:18,560
Directory.

860
00:37:18,560 --> 00:37:19,560
Read Write.

861
00:37:19,560 --> 00:37:20,840
All is even more dangerous.

862
00:37:20,840 --> 00:37:25,040
That scope lets an app create users, change group memberships and delete accounts.

863
00:37:25,040 --> 00:37:28,440
It is tenant-wide administrative power wrapped in an API scope.

864
00:37:28,440 --> 00:37:32,080
When you grant these permissions, you aren't just giving access to a resource.

865
00:37:32,080 --> 00:37:34,680
You are handing over the keys to the entire system.

866
00:37:34,680 --> 00:37:38,480
If that app is compromised or if the vendor turns malicious, those keys are now in the wrong

867
00:37:38,480 --> 00:37:41,760
hands, your email, your directory, your files.

868
00:37:41,760 --> 00:37:44,840
Whatever the permission covers is now completely exposed.

869
00:37:44,840 --> 00:37:50,160
Graph exposes this entire landscape, service principles, app registrations, role assignments.

870
00:37:50,160 --> 00:37:52,240
You can see every app and every permission it holds.

871
00:37:52,240 --> 00:37:55,320
You can audit the entire list, but most organizations don't do this.

872
00:37:55,320 --> 00:37:58,080
They install the app, grant the consent and then they forget.

873
00:37:58,080 --> 00:38:02,560
The permissions stay active, they stay unused, they create a massive, silent attack surface.

874
00:38:02,560 --> 00:38:06,000
The model has two types of permissions and they work very differently.

875
00:38:06,000 --> 00:38:10,120
Delegated permissions are when an app acts on behalf of a user, the user signs in, they authenticate.

876
00:38:10,120 --> 00:38:12,800
The app can only do what that specific user is allowed to do.

877
00:38:12,800 --> 00:38:16,320
If the user can't see a file, the app can't see it either, there is a human in the loop,

878
00:38:16,320 --> 00:38:18,520
there are sign-in prompts, there is friction.

879
00:38:18,520 --> 00:38:21,080
In this case, friction is a security feature.

880
00:38:21,080 --> 00:38:22,440
Application permissions are the real risk.

881
00:38:22,440 --> 00:38:24,160
The app does not act for a user.

882
00:38:24,160 --> 00:38:27,880
It acts as itself, it authenticates with a secret or a certificate, it gets it token,

883
00:38:27,880 --> 00:38:32,360
it does the work, there is no user involved, no sign-in prompt, no consent visible to anyone.

884
00:38:32,360 --> 00:38:36,440
A compromised app secret is a catastrophe because an attacker can authenticate as the app

885
00:38:36,440 --> 00:38:39,040
and access everything it has permission to touch.

886
00:38:39,040 --> 00:38:43,880
Your mail, your users, your data, and because the user never signs in, the attack is purely

887
00:38:43,880 --> 00:38:45,120
API-based.

888
00:38:45,120 --> 00:38:48,440
It is invisible to anyone who is only watching the sign-in logs.

889
00:38:48,440 --> 00:38:51,600
The governance model for this is straightforward, but it takes discipline.

890
00:38:51,600 --> 00:38:53,320
First, you need an inventory.

891
00:38:53,320 --> 00:38:57,240
List every app, find the ones with admin consent, find the high-risk scopes.

892
00:38:57,240 --> 00:39:00,360
Second, you have to ask if those permissions are actually being used.

893
00:39:00,360 --> 00:39:04,720
If activity logs will show you the truth, if an app has mail, read right, all but only

894
00:39:04,720 --> 00:39:06,960
ever reads messages, it is over-privileged.

895
00:39:06,960 --> 00:39:09,120
The permission is there, but it isn't necessary.

896
00:39:09,120 --> 00:39:13,600
Third, you have to revoke the access, delete the grant, shrink the scope.

897
00:39:13,600 --> 00:39:15,800
Keep only what the app actually needs to function.

898
00:39:15,800 --> 00:39:18,160
This is a massive opportunity for automation.

899
00:39:18,160 --> 00:39:22,440
You can build loops that identify unused permissions and remove them automatically.

900
00:39:22,440 --> 00:39:25,880
You can create workflows that flag high-risk grants for manual review.

901
00:39:25,880 --> 00:39:27,440
This isn't a one-time project.

902
00:39:27,440 --> 00:39:29,160
It is continuous governance.

903
00:39:29,160 --> 00:39:30,160
It is a huge change.

904
00:39:30,160 --> 00:39:31,800
Apps evolve, use it shifts.

905
00:39:31,800 --> 00:39:33,880
Your security posture has to move with them.

906
00:39:33,880 --> 00:39:38,400
In 2026, Microsoft is adding even more specific types like mail advanced.

907
00:39:38,400 --> 00:39:39,400
Read right.

908
00:39:39,400 --> 00:39:42,880
These new scopes require admin consent and are much more tightly controlled.

909
00:39:42,880 --> 00:39:45,800
This is Microsoft acknowledging that the old model was too broad.

910
00:39:45,800 --> 00:39:48,680
Some operations are just too dangerous for basic permissions.

911
00:39:48,680 --> 00:39:50,280
This creates a new challenge for you.

912
00:39:50,280 --> 00:39:53,840
As these types appear, you have to understand what they do and whether your apps actually

913
00:39:53,840 --> 00:39:55,520
need that level of power.

914
00:39:55,520 --> 00:39:57,240
The problem is that permissions are static.

915
00:39:57,240 --> 00:40:01,400
You grant them once and they sit there forever, but the way apps are used is dynamic.

916
00:40:01,400 --> 00:40:02,400
A vendor adds a feature.

917
00:40:02,400 --> 00:40:03,760
A business process changes.

918
00:40:03,760 --> 00:40:07,640
An app that didn't need right access six months ago might need it today.

919
00:40:07,640 --> 00:40:10,800
Or it might not need it at all and the vendor just asked for it to be safe.

920
00:40:10,800 --> 00:40:13,720
Your permissions get out of sync with reality.

921
00:40:13,720 --> 00:40:18,320
You end up over-privileged, which creates risk or under-privileged, which breaks your tools.

922
00:40:18,320 --> 00:40:19,800
The real model is this.

923
00:40:19,800 --> 00:40:21,400
Permissions are your security perimeter.

924
00:40:21,400 --> 00:40:22,400
It isn't about users.

925
00:40:22,400 --> 00:40:23,760
It isn't about devices.

926
00:40:23,760 --> 00:40:25,240
It is about applications.

927
00:40:25,240 --> 00:40:28,860
If an app has dangerous permissions, that app is a danger to your business, no matter how

928
00:40:28,860 --> 00:40:30,520
well you've secured everything else.

929
00:40:30,520 --> 00:40:34,400
If you give ten different apps mail, read right all, you have created ten different paths

930
00:40:34,400 --> 00:40:36,640
for an attacker to steal every email you own.

931
00:40:36,640 --> 00:40:39,200
The permissions are what actually matter.

932
00:40:39,200 --> 00:40:41,000
Programmatic permission, revocation.

933
00:40:41,000 --> 00:40:42,640
You know which permissions are dangerous.

934
00:40:42,640 --> 00:40:44,800
You've identified the applications that have them.

935
00:40:44,800 --> 00:40:47,480
You're ready to fix it, so you delete the permission grant, done.

936
00:40:47,480 --> 00:40:48,880
The app no longer has access.

937
00:40:48,880 --> 00:40:51,200
But in reality, it's more complicated than that.

938
00:40:51,200 --> 00:40:53,080
Revoking permissions sounds straightforward.

939
00:40:53,080 --> 00:40:54,480
It's not.

940
00:40:54,480 --> 00:40:56,120
The challenge isn't technical.

941
00:40:56,120 --> 00:41:00,120
The technical part is easy, because graph exposes two different revocation patterns and

942
00:41:00,120 --> 00:41:01,640
both of them work perfectly.

943
00:41:01,640 --> 00:41:03,360
The challenge is business impact.

944
00:41:03,360 --> 00:41:07,560
If you revoke a permission, an application actually relies on, that application breaks.

945
00:41:07,560 --> 00:41:09,640
Data stops flowing.

946
00:41:09,640 --> 00:41:11,000
Integrations fail.

947
00:41:11,000 --> 00:41:13,960
People call your help desk wondering why their workflow is broken.

948
00:41:13,960 --> 00:41:17,400
The two patterns are worth understanding because they give you optionality.

949
00:41:17,400 --> 00:41:20,400
Full revocation means you delete the entire permission grant.

950
00:41:20,400 --> 00:41:24,760
The application no longer has any access to what it previously could access, cleaned complete,

951
00:41:24,760 --> 00:41:26,720
but destructive if you got it wrong.

952
00:41:26,720 --> 00:41:28,920
Partial revocation means you reduce the scope.

953
00:41:28,920 --> 00:41:32,360
The permission grant still exists, but the app's capabilities shrink.

954
00:41:32,360 --> 00:41:34,760
It keeps mail read instead of mail.

955
00:41:34,760 --> 00:41:36,240
Read right, read only.

956
00:41:36,240 --> 00:41:38,240
Instead of read right, user.

957
00:41:38,240 --> 00:41:39,840
Read instead of directory.

958
00:41:39,840 --> 00:41:41,080
Read right all.

959
00:41:41,080 --> 00:41:43,960
The app still functions, but with less exposure.

960
00:41:43,960 --> 00:41:45,840
The practical workflow goes like this.

961
00:41:45,840 --> 00:41:49,160
First, identify which permissions are high risk or probably unused.

962
00:41:49,160 --> 00:41:51,040
The activity logs show you this.

963
00:41:51,040 --> 00:41:53,520
Second, evaluate the business impact if you remove them.

964
00:41:53,520 --> 00:41:55,320
We'll remove this permission break anything.

965
00:41:55,320 --> 00:41:57,000
Talk to the people who use the app.

966
00:41:57,000 --> 00:41:58,680
Check the vendor documentation.

967
00:41:58,680 --> 00:41:59,800
Do your homework.

968
00:41:59,800 --> 00:42:02,080
Third, execute the revocation carefully.

969
00:42:02,080 --> 00:42:05,360
For high risk permissions, do partial revocation first, if possible.

970
00:42:05,360 --> 00:42:08,000
Reduce scope rather than eliminate access entirely.

971
00:42:08,000 --> 00:42:09,360
Monitor what happens.

972
00:42:09,360 --> 00:42:12,960
Fourth, if nothing breaks after a trial period, you can either leave it at the reduced scope

973
00:42:12,960 --> 00:42:14,600
or go for full revocation.

974
00:42:14,600 --> 00:42:15,880
The safety challenge is real.

975
00:42:15,880 --> 00:42:19,560
You revoke a permission and an hour later the app starts throwing errors.

976
00:42:19,560 --> 00:42:21,320
A critical business process fails.

977
00:42:21,320 --> 00:42:23,280
Now you're rolling it back at 2 in the morning.

978
00:42:23,280 --> 00:42:24,640
This is why testing matters.

979
00:42:24,640 --> 00:42:28,560
This is why you don't revoke permissions from a thousand applications simultaneously.

980
00:42:28,560 --> 00:42:29,880
You do it methodically.

981
00:42:29,880 --> 00:42:31,200
In small batches.

982
00:42:31,200 --> 00:42:32,600
With monitoring.

983
00:42:32,600 --> 00:42:34,800
Graph activity logs are your safety net here.

984
00:42:34,800 --> 00:42:38,080
Before you revoke anything, look at what the application actually does.

985
00:42:38,080 --> 00:42:40,480
If an app requested mail, read right.

986
00:42:40,480 --> 00:42:44,560
All but you can see from the activity logs that it only ever makes read requests to mail.

987
00:42:44,560 --> 00:42:47,480
And mail, read right, all is overprivileged.

988
00:42:47,480 --> 00:42:49,360
You can safely reduce it to mail.

989
00:42:49,360 --> 00:42:50,360
Read all.

990
00:42:50,360 --> 00:42:53,960
The app will still work, but its exposure shrinks.

991
00:42:53,960 --> 00:42:57,280
This reveals an automation opportunity that most organizations never implement.

992
00:42:57,280 --> 00:43:01,320
You can build a continuous loop every quarter or every month if you're aggressive, pull

993
00:43:01,320 --> 00:43:03,320
the complete permission inventory.

994
00:43:03,320 --> 00:43:06,720
Cross-reference it with graph activity logs, identify permissions that haven't been used

995
00:43:06,720 --> 00:43:08,320
in the past 90 days.

996
00:43:08,320 --> 00:43:09,320
Flag them for review.

997
00:43:09,320 --> 00:43:11,320
For permissions, the app definitely doesn't use.

998
00:43:11,320 --> 00:43:13,760
You can even automate the partial revocation.

999
00:43:13,760 --> 00:43:17,640
Revealing the scope without requiring manual approval, but governance matters.

1000
00:43:17,640 --> 00:43:19,560
Permissions should be reviewed at least quarterly.

1001
00:43:19,560 --> 00:43:23,920
High-risk permissions, the ones that give access to sensitive data or to administrative functions

1002
00:43:23,920 --> 00:43:25,640
should be reviewed more frequently.

1003
00:43:25,640 --> 00:43:27,640
Some organizations review them monthly.

1004
00:43:27,640 --> 00:43:30,720
Some review them whenever an app makes a request for a permission bump.

1005
00:43:30,720 --> 00:43:32,600
The real insight is architectural.

1006
00:43:32,600 --> 00:43:34,080
Permission revocation isn't a project.

1007
00:43:34,080 --> 00:43:36,160
It's not something you do once and then forget about.

1008
00:43:36,160 --> 00:43:38,120
It's a continuous process.

1009
00:43:38,120 --> 00:43:40,920
As your organization grows, new applications appear.

1010
00:43:40,920 --> 00:43:43,160
As applications age, their requirements change.

1011
00:43:43,160 --> 00:43:46,840
As vendors update their software, permission requirements shift, your permission landscape

1012
00:43:46,840 --> 00:43:47,840
is always drifting.

1013
00:43:47,840 --> 00:43:51,160
Without continuous review and revocation, it drifts toward over-privileged.

1014
00:43:51,160 --> 00:43:52,720
Graph enables that continuous process.

1015
00:43:52,720 --> 00:43:56,320
You have the visibility, you have the APIs, you have the data to make informed decisions

1016
00:43:56,320 --> 00:43:57,320
at scale.

1017
00:43:57,320 --> 00:43:59,760
Most organizations just don't use it.

1018
00:43:59,760 --> 00:44:01,360
Detecting malicious graph activity.

1019
00:44:01,360 --> 00:44:03,920
An attacker gets into your tenant through one of two paths.

1020
00:44:03,920 --> 00:44:06,200
They compromise in applications credentials.

1021
00:44:06,200 --> 00:44:11,200
Maybe they stole a client secret from a GitHub repo or they broke into the vendor's infrastructure.

1022
00:44:11,200 --> 00:44:12,960
Now they can authenticate as that app.

1023
00:44:12,960 --> 00:44:16,080
Or they trick a user into consenting to a malicious application.

1024
00:44:16,080 --> 00:44:19,320
A phishing email that looks like it's from a vendor, but really it's asking for permission

1025
00:44:19,320 --> 00:44:20,320
to access mail.

1026
00:44:20,320 --> 00:44:21,920
Read right all on behalf of that user.

1027
00:44:21,920 --> 00:44:24,960
Either way, they now have programmatic access to your tenant.

1028
00:44:24,960 --> 00:44:26,520
What comes next is data theft.

1029
00:44:26,520 --> 00:44:27,520
A real attack.

1030
00:44:27,520 --> 00:44:29,640
They're not doing anything that looks like a typical breach.

1031
00:44:29,640 --> 00:44:31,640
They're not moving files around in SharePoint.

1032
00:44:31,640 --> 00:44:33,960
They're not sending emails from compromised mailboxes.

1033
00:44:33,960 --> 00:44:36,720
They're using the graph API to read data at scale.

1034
00:44:36,720 --> 00:44:39,040
One graph call can pull thousands of emails.

1035
00:44:39,040 --> 00:44:42,280
Another call pulls file metadata from across your organization.

1036
00:44:42,280 --> 00:44:44,080
Another call enumerates all your users.

1037
00:44:44,080 --> 00:44:46,840
Another creates a new service principle for persistence.

1038
00:44:46,840 --> 00:44:48,240
All of it through the API layer.

1039
00:44:48,240 --> 00:44:51,200
Here's where graph activity logs become your detection mechanism.

1040
00:44:51,200 --> 00:44:54,160
When a normal application uses graph, there's a patent to it.

1041
00:44:54,160 --> 00:44:57,720
It makes a few calls per day, maybe per hour depending on what it does.

1042
00:44:57,720 --> 00:44:59,640
It accesses specific endpoints.

1043
00:44:59,640 --> 00:45:02,000
It reads data that matches its declared purpose.

1044
00:45:02,000 --> 00:45:03,920
The activity has rhythm and scope.

1045
00:45:03,920 --> 00:45:07,080
When an attacker uses graph, they break that patent immediately.

1046
00:45:07,080 --> 00:45:08,880
The signatures are distinct.

1047
00:45:08,880 --> 00:45:13,080
An app that normally makes 10 API calls per day suddenly makes 10,000.

1048
00:45:13,080 --> 00:45:16,240
An app that normally reads one user's mailbox starts reading 50.

1049
00:45:16,240 --> 00:45:20,040
An app that was installed last week to manage room reservations is suddenly calling the

1050
00:45:20,040 --> 00:45:22,920
directory API to enumerate all users in the tenant.

1051
00:45:22,920 --> 00:45:24,320
These aren't subtle changes.

1052
00:45:24,320 --> 00:45:28,320
Their violations of the established patent, graph activity logs show you all of it.

1053
00:45:28,320 --> 00:45:29,440
Which app made the call?

1054
00:45:29,440 --> 00:45:30,440
What endpoint?

1055
00:45:30,440 --> 00:45:31,440
What time?

1056
00:45:31,440 --> 00:45:32,440
From what IP?

1057
00:45:32,440 --> 00:45:33,440
How many results?

1058
00:45:33,440 --> 00:45:34,440
Whether it's succeeded.

1059
00:45:34,440 --> 00:45:35,440
You build a baseline.

1060
00:45:35,440 --> 00:45:36,680
What is normal for this app?

1061
00:45:36,680 --> 00:45:40,680
You alert when activity deviates from that baseline significantly.

1062
00:45:40,680 --> 00:45:42,200
But here's where it gets more powerful.

1063
00:45:42,200 --> 00:45:45,160
You correlate graph activity logs with identity risk signals.

1064
00:45:45,160 --> 00:45:47,280
A user got fished.

1065
00:45:47,280 --> 00:45:49,960
They entered their credentials on a fake login page.

1066
00:45:49,960 --> 00:45:53,960
EntraID detects the compromise password and flags the account as at risk.

1067
00:45:53,960 --> 00:45:58,200
Now that user tries to sign into a malicious app they just consented to, the app authenticates

1068
00:45:58,200 --> 00:46:00,600
the user and requests tokens.

1069
00:46:00,600 --> 00:46:04,360
EntraID issues the tokens, but the sign in is flagged as risky because the credentials

1070
00:46:04,360 --> 00:46:05,920
are known to be compromised.

1071
00:46:05,920 --> 00:46:09,800
And then immediately afterwards that app starts making unusual graph calls.

1072
00:46:09,800 --> 00:46:10,800
Massive reads.

1073
00:46:10,800 --> 00:46:11,800
Unusual endpoints.

1074
00:46:11,800 --> 00:46:12,800
That's a correlation.

1075
00:46:12,800 --> 00:46:13,800
That's the story.

1076
00:46:13,800 --> 00:46:14,800
Compromise credentials.

1077
00:46:14,800 --> 00:46:17,120
Militious app data theft in progress.

1078
00:46:17,120 --> 00:46:20,360
When you see that patent you don't wait for a human to investigate.

1079
00:46:20,360 --> 00:46:22,040
You automate the response.

1080
00:46:22,040 --> 00:46:23,680
Revoke the app's tokens immediately.

1081
00:46:23,680 --> 00:46:25,480
Disable the service principle.

1082
00:46:25,480 --> 00:46:26,800
Remove the permission grants.

1083
00:46:26,800 --> 00:46:28,760
Force the user to reset their password.

1084
00:46:28,760 --> 00:46:30,600
The entire response happens in seconds.

1085
00:46:30,600 --> 00:46:34,160
By the time the attacker even realizes the tokens are dead, you've already stopped them.

1086
00:46:34,160 --> 00:46:38,040
The investigation workflow is where you really leverage the visibility graph gives you.

1087
00:46:38,040 --> 00:46:40,280
The app was running for four days before you caught it.

1088
00:46:40,280 --> 00:46:41,960
In those four days what did it access?

1089
00:46:41,960 --> 00:46:43,680
Graph activity logs give you the answer.

1090
00:46:43,680 --> 00:46:44,840
Every API call.

1091
00:46:44,840 --> 00:46:45,840
Every operation.

1092
00:46:45,840 --> 00:46:48,000
You can see exactly which mailboxes were read.

1093
00:46:48,000 --> 00:46:49,480
Which files were downloaded.

1094
00:46:49,480 --> 00:46:50,960
Which users were enumerated.

1095
00:46:50,960 --> 00:46:52,480
You can trace the blast radius.

1096
00:46:52,480 --> 00:46:55,600
You can figure out what data was stolen and what didn't get accessed.

1097
00:46:55,600 --> 00:46:58,920
Most critically you can see if the attacker created persistence.

1098
00:46:58,920 --> 00:47:00,560
Did they create new service principles?

1099
00:47:00,560 --> 00:47:02,440
Did they modify conditional access policies?

1100
00:47:02,440 --> 00:47:03,960
Did they create new applications?

1101
00:47:03,960 --> 00:47:05,960
These administrative actions leave traces.

1102
00:47:05,960 --> 00:47:06,960
Graph audits them.

1103
00:47:06,960 --> 00:47:08,520
You can see what was changed and reverted.

1104
00:47:08,520 --> 00:47:10,040
The real model is this.

1105
00:47:10,040 --> 00:47:12,880
Graph is both your visibility layer and your enforcement layer.

1106
00:47:12,880 --> 00:47:13,880
You see attacks happen.

1107
00:47:13,880 --> 00:47:15,480
You respond to them automatically.

1108
00:47:15,480 --> 00:47:19,080
The entire cycle detection to containment takes minutes, not hours.

1109
00:47:19,080 --> 00:47:20,200
That's the structural shift.

1110
00:47:20,200 --> 00:47:23,960
That's what separates organizations that get breached from organizations that get attacked

1111
00:47:23,960 --> 00:47:25,680
and survive.

1112
00:47:25,680 --> 00:47:27,720
Building executive risk posture.

1113
00:47:27,720 --> 00:47:28,920
Executives have one question.

1114
00:47:28,920 --> 00:47:29,920
Not five.

1115
00:47:29,920 --> 00:47:30,920
Not ten.

1116
00:47:30,920 --> 00:47:31,920
Just one.

1117
00:47:31,920 --> 00:47:32,920
Are we secure?

1118
00:47:32,920 --> 00:47:36,640
They ask whether it's about compliance, risk or trends.

1119
00:47:36,640 --> 00:47:38,360
It's just a variation of that same core question.

1120
00:47:38,360 --> 00:47:39,840
But here's the problem.

1121
00:47:39,840 --> 00:47:41,680
Security teams answer in technical language.

1122
00:47:41,680 --> 00:47:45,760
They talk about 427 risky sign-ins or a secure score of 72.

1123
00:47:45,760 --> 00:47:49,720
They mention conditional access policies covering 65% of the user base.

1124
00:47:49,720 --> 00:47:50,720
These numbers are accurate.

1125
00:47:50,720 --> 00:47:51,960
They are real data points.

1126
00:47:51,960 --> 00:47:54,000
But they don't actually answer the executive's question.

1127
00:47:54,000 --> 00:47:55,480
They just create more confusion.

1128
00:47:55,480 --> 00:47:58,320
Graph gives you the raw material to build a real answer.

1129
00:47:58,320 --> 00:48:02,640
You have access to secure scores, risk detections, alert volumes and permission inventories

1130
00:48:02,640 --> 00:48:04,080
across the entire tenant.

1131
00:48:04,080 --> 00:48:05,800
But raw material isn't an answer.

1132
00:48:05,800 --> 00:48:07,400
It just noise without context.

1133
00:48:07,400 --> 00:48:09,920
The translation layer is where your value lives.

1134
00:48:09,920 --> 00:48:14,880
Instead of reporting 427 risky sign-ins, you tell them that 2.3% of sign-ins are flagged

1135
00:48:14,880 --> 00:48:18,680
as risky, which is down from 3.1% last quarter.

1136
00:48:18,680 --> 00:48:20,680
Now the executive understands there is a baseline.

1137
00:48:20,680 --> 00:48:21,880
There is a direction.

1138
00:48:21,880 --> 00:48:25,000
They can finally see if the organization is getting better or worse.

1139
00:48:25,000 --> 00:48:26,680
Secure score is your headline metric.

1140
00:48:26,680 --> 00:48:31,160
It's a simple number from 0 to 100 that represents your posture across identity, devices,

1141
00:48:31,160 --> 00:48:32,520
data and apps.

1142
00:48:32,520 --> 00:48:35,760
Graph exposes this through the security secure scores endpoint.

1143
00:48:35,760 --> 00:48:36,760
You pull it, you track it.

1144
00:48:36,760 --> 00:48:40,840
If the score was 62 last quarter and it's 69 today, you are improving.

1145
00:48:40,840 --> 00:48:44,440
The executive sees that number and understands it immediately because it's quantifiable and

1146
00:48:44,440 --> 00:48:45,440
trackable.

1147
00:48:45,440 --> 00:48:46,760
But secure score alone is incomplete.

1148
00:48:46,760 --> 00:48:49,520
It's like looking at a stock price without knowing what the company does.

1149
00:48:49,520 --> 00:48:51,200
The number doesn't tell the full story.

1150
00:48:51,200 --> 00:48:54,080
You need supporting metrics to explain what's happening underneath.

1151
00:48:54,080 --> 00:48:55,360
Take MFA coverage.

1152
00:48:55,360 --> 00:48:58,600
You need to know what percentage of your users are actually using it, not just who has

1153
00:48:58,600 --> 00:48:59,600
it configured.

1154
00:48:59,600 --> 00:49:02,920
If 40% of users use MFA, you have massive exposure.

1155
00:49:02,920 --> 00:49:05,240
If 95% use it, you're in a strong position.

1156
00:49:05,240 --> 00:49:08,560
This one number tells an executive if your identity layer is hardened.

1157
00:49:08,560 --> 00:49:10,440
Then there's conditional access coverage.

1158
00:49:10,440 --> 00:49:13,200
These policies are your enforcement mechanism.

1159
00:49:13,200 --> 00:49:18,480
If only 30% of the org is covered, then 70% of your users can sign in from anywhere on any

1160
00:49:18,480 --> 00:49:19,920
device without controls.

1161
00:49:19,920 --> 00:49:21,320
That is a clear statement of risk.

1162
00:49:21,320 --> 00:49:24,040
When 95% are covered, you have continuous enforcement.

1163
00:49:24,040 --> 00:49:26,240
You also have to look at application permission risk.

1164
00:49:26,240 --> 00:49:27,920
It's not about how many apps you have.

1165
00:49:27,920 --> 00:49:31,760
It's about how many have dangerous permissions like mail, red write.

1166
00:49:31,760 --> 00:49:33,600
All that could lead to data theft.

1167
00:49:33,600 --> 00:49:38,240
A hundred apps with high risk permissions is a catastrophe, but 10 is manageable.

1168
00:49:38,240 --> 00:49:41,480
This metric tells an executive if the application layer is a threat.

1169
00:49:41,480 --> 00:49:43,040
The dashboard model is simple.

1170
00:49:43,040 --> 00:49:46,120
Three to five metrics, not 20, not 50.

1171
00:49:46,120 --> 00:49:49,840
When you give an executive 20 metrics, they understand zero of them.

1172
00:49:49,840 --> 00:49:51,520
Too much data creates paralysis.

1173
00:49:51,520 --> 00:49:53,120
Pick the metrics that matter.

1174
00:49:53,120 --> 00:49:56,120
Risk trends, response speed and automation coverage.

1175
00:49:56,120 --> 00:49:58,120
These four points tell a story.

1176
00:49:58,120 --> 00:50:00,040
Reporting frequency matters too.

1177
00:50:00,040 --> 00:50:01,840
Executives don't need daily dashboards.

1178
00:50:01,840 --> 00:50:05,680
They need monthly or quarterly reports that show trends rather than snapshots.

1179
00:50:05,680 --> 00:50:10,280
They want to hear that you closed 94% of alerts within four hours this month compared to

1180
00:50:10,280 --> 00:50:11,960
87% last month.

1181
00:50:11,960 --> 00:50:13,360
That positive trend is what they value.

1182
00:50:13,360 --> 00:50:15,320
The real insight is deceptively simple.

1183
00:50:15,320 --> 00:50:19,560
Your job isn't to report data, is to translate data into the language of risk.

1184
00:50:19,560 --> 00:50:23,280
Graph provides the raw ingredients, but your responsibility is to cook them into something

1185
00:50:23,280 --> 00:50:25,560
an executive can actually act on.

1186
00:50:25,560 --> 00:50:27,680
Visual excellence is just the starting point.

1187
00:50:27,680 --> 00:50:30,240
Translation is what makes you valuable.

1188
00:50:30,240 --> 00:50:32,040
The graph driven SOC model.

1189
00:50:32,040 --> 00:50:35,920
A traditional security operation center works like a factory with a backlog problem.

1190
00:50:35,920 --> 00:50:38,040
Alerts arrive, the queue grows.

1191
00:50:38,040 --> 00:50:40,600
An analyst picks one up and starts investigating.

1192
00:50:40,600 --> 00:50:44,080
That investigation means opening multiple tools and running queries across different systems

1193
00:50:44,080 --> 00:50:46,240
to pull logs and check asset inventories.

1194
00:50:46,240 --> 00:50:49,600
30 minutes later, they finally have enough context to make a decision.

1195
00:50:49,600 --> 00:50:52,640
They execute a response, but the next alert is already waiting.

1196
00:50:52,640 --> 00:50:54,200
This is reactive security.

1197
00:50:54,200 --> 00:50:55,360
You're always behind.

1198
00:50:55,360 --> 00:50:57,400
You're always processing yesterday's problems.

1199
00:50:57,400 --> 00:50:59,640
A graph driven SOC flips the model.

1200
00:50:59,640 --> 00:51:01,880
You aren't reacting to alerts after they arrive.

1201
00:51:01,880 --> 00:51:06,480
You are continuously monitoring data streams and enriching them with context automatically.

1202
00:51:06,480 --> 00:51:10,160
You correlate across sources programmatically and trigger responses without waiting for a

1203
00:51:10,160 --> 00:51:11,360
human to catch up.

1204
00:51:11,360 --> 00:51:13,160
The architecture has four distinct layers.

1205
00:51:13,160 --> 00:51:14,760
The first layer is ingestion.

1206
00:51:14,760 --> 00:51:16,520
This is the raw data from graph.

1207
00:51:16,520 --> 00:51:18,360
Alerts, audit logs and risk signals.

1208
00:51:18,360 --> 00:51:19,840
These streams flow constantly.

1209
00:51:19,840 --> 00:51:21,640
The practical piece here is filtering.

1210
00:51:21,640 --> 00:51:22,800
You don't ingest everything.

1211
00:51:22,800 --> 00:51:26,440
You filter at the source for high severity alerts and unusual admin actions.

1212
00:51:26,440 --> 00:51:29,440
This filtering layer determines what actually enters your pipeline.

1213
00:51:29,440 --> 00:51:33,680
Use the graph security API to pull alerts from defender and filter them by severity.

1214
00:51:33,680 --> 00:51:38,000
By sending only high and medium alerts to your CM and moving low severity items to a batch

1215
00:51:38,000 --> 00:51:40,520
queue, you reduce your data volume by half.

1216
00:51:40,520 --> 00:51:42,000
The second layer is enrichment.

1217
00:51:42,000 --> 00:51:44,960
An alert says a user signed in from an unusual location.

1218
00:51:44,960 --> 00:51:48,080
That's risky, but you need to know if that user is high privileged or just traveling for

1219
00:51:48,080 --> 00:51:49,080
business.

1220
00:51:49,080 --> 00:51:52,040
You need to know if their device is compliant or if they are a contractor.

1221
00:51:52,040 --> 00:51:54,520
These context pieces turn a statistic into a signal.

1222
00:51:54,520 --> 00:51:55,520
Graph gives you this data.

1223
00:51:55,520 --> 00:51:56,960
The user object contains roles.

1224
00:51:56,960 --> 00:51:58,880
The device object shows compliance.

1225
00:51:58,880 --> 00:52:01,480
Group membership tells you if the user is critical.

1226
00:52:01,480 --> 00:52:05,680
You cross-reference the sign-in event with the directory and attach that context automatically.

1227
00:52:05,680 --> 00:52:09,600
Now when an analyst sees the alert, they don't have to investigate the user separately because

1228
00:52:09,600 --> 00:52:11,280
the context is already there.

1229
00:52:11,280 --> 00:52:13,520
Layer 3 is correlation.

1230
00:52:13,520 --> 00:52:16,360
This is about multiple signals pointing to the same threat.

1231
00:52:16,360 --> 00:52:17,960
A user is flagged for identity risk.

1232
00:52:17,960 --> 00:52:21,520
They're making unusual graph calls and they're accessing files they never touch.

1233
00:52:21,520 --> 00:52:24,000
In isolation, these might look like false positives.

1234
00:52:24,000 --> 00:52:25,920
Together, they are a story of a compromise.

1235
00:52:25,920 --> 00:52:29,240
Graph enables this because all the data lives in one ecosystem.

1236
00:52:29,240 --> 00:52:32,800
You aren't trying to match events across different platforms using fuzzy logic.

1237
00:52:32,800 --> 00:52:35,280
You are correlating within a unified model.

1238
00:52:35,280 --> 00:52:36,600
The fourth layer is response.

1239
00:52:36,600 --> 00:52:39,120
When signals align, you have to act intelligently.

1240
00:52:39,120 --> 00:52:41,240
The response isn't just a human deciding.

1241
00:52:41,240 --> 00:52:44,640
It's an automated decision based on governance rules you've already defined.

1242
00:52:44,640 --> 00:52:48,080
Triage enrichment can be fully automated with no approval needed.

1243
00:52:48,080 --> 00:52:52,960
But disabling a user account or deleting a service principle requires an approval and an audit trail.

1244
00:52:52,960 --> 00:52:55,160
Here is how layers 3 and 4 work together.

1245
00:52:55,160 --> 00:52:59,440
An alert fires and is automatically enriched with user and device context before the system

1246
00:52:59,440 --> 00:53:01,400
correlates it with identity risk flags.

1247
00:53:01,400 --> 00:53:02,600
The correlation is strong.

1248
00:53:02,600 --> 00:53:06,160
The system evaluates your response rules and determines that the situation warrants disabling

1249
00:53:06,160 --> 00:53:07,160
the sign-in.

1250
00:53:07,160 --> 00:53:08,400
The system doesn't just kill the account.

1251
00:53:08,400 --> 00:53:11,520
It drafts the action, logs it and sends it to an approval queue.

1252
00:53:11,520 --> 00:53:14,560
The analyst reviews it in five seconds and approves it.

1253
00:53:14,560 --> 00:53:18,040
The entire cycle from ingestion to execution takes minutes instead of hours.

1254
00:53:18,040 --> 00:53:20,040
The governance model is critical here.

1255
00:53:20,040 --> 00:53:21,600
Not all automations are equal.

1256
00:53:21,600 --> 00:53:25,560
Some are safe enough to run alone, while others need a human to confirm or even multiple

1257
00:53:25,560 --> 00:53:26,960
people to sign off.

1258
00:53:26,960 --> 00:53:30,880
You have to think about your automation in tears based on how dangerous the action is.

1259
00:53:30,880 --> 00:53:32,400
The real structural insight is this.

1260
00:53:32,400 --> 00:53:34,560
A graph-driven SOC removes delay.

1261
00:53:34,560 --> 00:53:36,000
It doesn't remove humans.

1262
00:53:36,000 --> 00:53:39,080
Humans still make the critical decisions, but they make them faster.

1263
00:53:39,080 --> 00:53:40,680
Because the supporting work is already done.

1264
00:53:40,680 --> 00:53:45,000
The data is gathered, it's enriched, it's correlated, it's just waiting for judgment.

1265
00:53:45,000 --> 00:53:47,920
That is the only model that actually works at scale.

1266
00:53:47,920 --> 00:53:49,920
Designing your graph data architecture.

1267
00:53:49,920 --> 00:53:53,880
When you move to a graph-driven security model, you are signing up for a massive non-stop

1268
00:53:53,880 --> 00:53:54,880
stream of data.

1269
00:53:54,880 --> 00:53:58,400
Alerts flow in, logs stream, risk signals arrive.

1270
00:53:58,400 --> 00:54:02,080
The volume is staggering and a large tenant can easily generate millions of events every

1271
00:54:02,080 --> 00:54:03,080
single day.

1272
00:54:03,080 --> 00:54:06,040
Every event is potentially valuable, but every event is also potentially noise.

1273
00:54:06,040 --> 00:54:09,800
Your data architecture determines if you can actually handle that volume or if you drown

1274
00:54:09,800 --> 00:54:10,800
in it.

1275
00:54:10,800 --> 00:54:13,920
The model that actually works splits your incoming data into three paths.

1276
00:54:13,920 --> 00:54:15,120
It's not about being elegant.

1277
00:54:15,120 --> 00:54:18,120
It's about the fact that different data serves different purposes.

1278
00:54:18,120 --> 00:54:22,920
The hot path is for data that drives immediate decisions, like alerts and risk signals that

1279
00:54:22,920 --> 00:54:24,200
need a response right now.

1280
00:54:24,200 --> 00:54:28,960
You ingest these into your SIM or real-time analytics platform so they are available immediately.

1281
00:54:28,960 --> 00:54:31,080
In this path, query latency is everything.

1282
00:54:31,080 --> 00:54:32,240
You need responses in seconds.

1283
00:54:32,240 --> 00:54:35,640
If an alert takes an hour to show up, it is useless to your team.

1284
00:54:35,640 --> 00:54:40,120
It is better to pay more for faster ingestion than to save a few dollars and lose your ability

1285
00:54:40,120 --> 00:54:41,120
to react.

1286
00:54:41,120 --> 00:54:44,600
Alerts from Defender Endpoints and Risk Detections from Identity Protection belong

1287
00:54:44,600 --> 00:54:45,600
here.

1288
00:54:45,600 --> 00:54:46,600
They are queryable within seconds.

1289
00:54:46,600 --> 00:54:48,480
Your ASOKEA analysts see them immediately.

1290
00:54:48,480 --> 00:54:50,480
Your automations can react immediately.

1291
00:54:50,480 --> 00:54:55,920
The warm path is for data you query frequently, but not necessarily in real-time.

1292
00:54:55,920 --> 00:54:56,920
Audit logs.

1293
00:54:56,920 --> 00:54:57,920
Activity logs.

1294
00:54:57,920 --> 00:54:59,320
Configuration changes.

1295
00:54:59,320 --> 00:55:01,200
These have a higher tolerance for latency.

1296
00:55:01,200 --> 00:55:05,680
If an audit log takes 15 minutes to appear, that is acceptable for a forensic investigation.

1297
00:55:05,680 --> 00:55:09,600
You aren't making split second decisions based on these logs because you are using them

1298
00:55:09,600 --> 00:55:12,000
to investigate and correlate what happened.

1299
00:55:12,000 --> 00:55:15,480
The timeline here is minutes, not seconds.

1300
00:55:15,480 --> 00:55:18,520
Warm path data lives in a data warehouse or a data lake.

1301
00:55:18,520 --> 00:55:19,840
It is indexed and searchable.

1302
00:55:19,840 --> 00:55:23,080
Your analysts can run complex queries across months of data.

1303
00:55:23,080 --> 00:55:27,480
Performance is still good, but the cost is lower because you are accepting that slight delay.

1304
00:55:27,480 --> 00:55:31,560
Microsoft Sentinel's basic logs here costs less than analytics logs for exactly this reason.

1305
00:55:31,560 --> 00:55:35,400
The data is still there, but it isn't optimized for a sub-second response.

1306
00:55:35,400 --> 00:55:38,400
The cold path is for long term retention and archive data.

1307
00:55:38,400 --> 00:55:42,960
You keep this for regulatory reasons or for forensics if a multi-year investigation is ever needed,

1308
00:55:42,960 --> 00:55:43,960
but you don't keep it hot.

1309
00:55:43,960 --> 00:55:46,600
You store it in cheap long term archive storage.

1310
00:55:46,600 --> 00:55:48,720
Retrieval takes time, but the cost is minimal.

1311
00:55:48,720 --> 00:55:49,960
But here is the problem.

1312
00:55:49,960 --> 00:55:52,400
ingesting everything into the hot path is expensive.

1313
00:55:52,400 --> 00:55:56,640
Microsoft Sentinel charges $2.46 per gigabyte for analytics logs.

1314
00:55:56,640 --> 00:56:01,040
A large organization generating millions of events per day will hit hundreds of thousands

1315
00:56:01,040 --> 00:56:02,680
of dollars per month very quickly.

1316
00:56:02,680 --> 00:56:04,040
You cannot ingest everything hot.

1317
00:56:04,040 --> 00:56:05,160
You have to be selective.

1318
00:56:05,160 --> 00:56:07,360
The filtering strategy is simple in concept.

1319
00:56:07,360 --> 00:56:10,000
The brutal in execution do not ingest everything.

1320
00:56:10,000 --> 00:56:11,000
Filter at the source.

1321
00:56:11,000 --> 00:56:13,480
Pull only high severity alerts into your hot path.

1322
00:56:13,480 --> 00:56:16,880
Pull only admin actions and risky sign-ins from your audit logs.

1323
00:56:16,880 --> 00:56:21,360
Filter your activity logs for unusual patterns before you ever pay to ingest them.

1324
00:56:21,360 --> 00:56:25,440
This filtering happens in graph before the data even enters your paid platforms.

1325
00:56:25,440 --> 00:56:28,640
It is free and it reduces your data volume dramatically.

1326
00:56:28,640 --> 00:56:33,400
The practical approach is to use graphs or data filtering to pre-process data before ingestion.

1327
00:56:33,400 --> 00:56:37,280
To create automated pipelines that pull data from graph, apply your rules and then decide

1328
00:56:37,280 --> 00:56:38,840
which path each event takes.

1329
00:56:38,840 --> 00:56:45,800
High severity alert, hot path, low severity, warm path, routine user login from a normal location,

1330
00:56:45,800 --> 00:56:49,360
warm path, impossible travel detection, hot path.

1331
00:56:49,360 --> 00:56:52,120
Your data architecture shapes your entire security operation.

1332
00:56:52,120 --> 00:56:56,640
A well-designed architecture means you detect threats fast and respond fast while keeping

1333
00:56:56,640 --> 00:56:57,920
costs under control.

1334
00:56:57,920 --> 00:57:01,360
A poorly designed architecture means you are paying for massive volumes of data that

1335
00:57:01,360 --> 00:57:02,760
you never actually use.

1336
00:57:02,760 --> 00:57:05,120
Speed is slow because you are drowning in noise.

1337
00:57:05,120 --> 00:57:06,680
The discipline is filtering.

1338
00:57:06,680 --> 00:57:08,920
The outcome is control.

1339
00:57:08,920 --> 00:57:10,480
The critical graph endpoints.

1340
00:57:10,480 --> 00:57:13,800
You don't need to memorize every single endpoint graph exposes.

1341
00:57:13,800 --> 00:57:15,400
There are hundreds.

1342
00:57:15,400 --> 00:57:19,480
But there is a tight set of endpoints that form the backbone of security automation.

1343
00:57:19,480 --> 00:57:22,920
Understanding them matters because this is where theory meets practice.

1344
00:57:22,920 --> 00:57:24,000
Start with the alert endpoints.

1345
00:57:24,000 --> 00:57:30,200
The legacy interface is at/security/alerts, but it is being deprecated by April of 2026.

1346
00:57:30,200 --> 00:57:32,360
Do not build new automation against it.

1347
00:57:32,360 --> 00:57:34,920
Use /security/alerts_v2 instead.

1348
00:57:34,920 --> 00:57:38,560
This is the unified alert schema that Microsoft is standardizing on.

1349
00:57:38,560 --> 00:57:42,120
It pulls alerts from all your defender products into one place with one schema.

1350
00:57:42,120 --> 00:57:44,000
It is much cleaner than the old model.

1351
00:57:44,000 --> 00:57:45,200
Incidents are different from alerts.

1352
00:57:45,200 --> 00:57:48,400
An incident is an aggregated event that groups related alerts together.

1353
00:57:48,400 --> 00:57:52,520
The system recognizes that five separate alerts are actually just one coordinated attack.

1354
00:57:52,520 --> 00:57:57,600
It groups them into an incident and surfaces them through /security/incidents.

1355
00:57:57,600 --> 00:58:01,000
This endpoint is valuable because the correlation is already done for you.

1356
00:58:01,000 --> 00:58:02,560
You aren't looking at five separate alerts.

1357
00:58:02,560 --> 00:58:05,080
You're looking at one incident that tells a story.

1358
00:58:05,080 --> 00:58:12,760
For identity signals, you need /identity/protection/risky_users and /identity/protection/riskdetections.

1359
00:58:12,760 --> 00:58:16,720
These endpoints expose the probabilistic risk that identity protection is calculating.

1360
00:58:16,720 --> 00:58:19,280
A user object tells you their basic attributes.

1361
00:58:19,280 --> 00:58:22,680
A risky user object tells you they are flagged as potentially compromised.

1362
00:58:22,680 --> 00:58:26,960
A risk detection object tells you the specific reason why, like impossible travel or leaked

1363
00:58:26,960 --> 00:58:30,360
credentials, these three endpoints form your identity risk layer.

1364
00:58:30,360 --> 00:58:32,280
Audit logs split into two streams.

1365
00:58:32,280 --> 00:58:37,880
Slash audit logs /sign-ins captures every successful authentication and every failed attempt.

1366
00:58:37,880 --> 00:58:40,800
This is the log of who accessed your tenant and when.

1367
00:58:40,800 --> 00:58:45,200
Slash audit logs / directory audits captures administrative actions like role assignments

1368
00:58:45,200 --> 00:58:46,480
and policy changes.

1369
00:58:46,480 --> 00:58:49,320
Any modification to your directory structure flows through here.

1370
00:58:49,320 --> 00:58:51,760
Together they form your forensic record.

1371
00:58:51,760 --> 00:58:55,760
Conditional access policies live at /identity/conditional access/polices.

1372
00:58:55,760 --> 00:58:57,240
This is where policy as code begins.

1373
00:58:57,240 --> 00:59:01,000
You can query the complete list of policies your tenant has or retrieve individual ones

1374
00:59:01,000 --> 00:59:02,920
to see their exact configuration.

1375
00:59:02,920 --> 00:59:06,080
You can create, update or delete policies programmatically.

1376
00:59:06,080 --> 00:59:09,080
This endpoint is your interface to your enforcement layer.

1377
00:59:09,080 --> 00:59:10,560
Applications show up in two places.

1378
00:59:10,560 --> 00:59:14,040
Slash applications lists the apps you have explicitly registered in Entra.

1379
00:59:14,040 --> 00:59:17,920
Slash service principles lists the objects that represent those apps and manage the identities

1380
00:59:17,920 --> 00:59:19,280
operating in your tenant.

1381
00:59:19,280 --> 00:59:20,640
The distinction matters.

1382
00:59:20,640 --> 00:59:24,520
An app registration is the definition, but a service principle is the actual instance.

1383
00:59:24,520 --> 00:59:28,320
You register an app once, but it might create multiple service principles across different

1384
00:59:28,320 --> 00:59:29,320
tenants.

1385
00:59:29,320 --> 00:59:33,080
Query service principles to see what is actually running in your environment.

1386
00:59:33,080 --> 00:59:36,480
Permission grants live at /oauth2 permission grants.

1387
00:59:36,480 --> 00:59:38,120
This is where the rubber meets the road.

1388
00:59:38,120 --> 00:59:42,680
It is one thing to register an app, but it is another thing to actually granted permissions.

1389
00:59:42,680 --> 00:59:46,720
This endpoint shows you every delegated permission grant in your tenant, query it, to see what

1390
00:59:46,720 --> 00:59:50,640
permissions are granted and cross-reference that with your application inventory.

1391
00:59:50,640 --> 00:59:55,200
This is how you spot over-privileged applications or often grants from deleted apps.

1392
00:59:55,200 --> 01:00:01,280
Finally, /microsoftgraph/activitylogs is your window into the API layer itself.

1393
01:00:01,280 --> 01:00:04,280
Every HTTP request to graph in your tenant gets logged here.

1394
01:00:04,280 --> 01:00:08,240
You can see which app made the call, what endpoint they hit and what time they did it.

1395
01:00:08,240 --> 01:00:11,440
Most organizations don't even know this endpoint exists.

1396
01:00:11,440 --> 01:00:15,160
But it is the most powerful visibility tool you have to see what applications are actually

1397
01:00:15,160 --> 01:00:16,160
doing.

1398
01:00:16,160 --> 01:00:18,600
The practical approach isn't to master all of these at once.

1399
01:00:18,600 --> 01:00:24,700
Type 2, start with /security/alerts, underscore v2 and /auditlogs/signins.

1400
01:00:24,700 --> 01:00:28,360
Learn to query them and process the responses, understand what data they give you and what

1401
01:00:28,360 --> 01:00:29,360
they don't.

1402
01:00:29,360 --> 01:00:32,960
Then add another endpoint, build your knowledge incrementally.

1403
01:00:32,960 --> 01:00:34,680
The real insight is straightforward.

1404
01:00:34,680 --> 01:00:37,920
These endpoints are the interface to your tenant's security model.

1405
01:00:37,920 --> 01:00:42,520
They aren't just data sources, they are the structural layer that defines what is possible.

1406
01:00:42,520 --> 01:00:44,640
Learning them well is an investment that compounds.

1407
01:00:44,640 --> 01:00:48,200
Every endpoint you master makes you more dangerous as a security practitioner.

1408
01:00:48,200 --> 01:00:50,080
Learning at scale without hitting limits.

1409
01:00:50,080 --> 01:00:51,080
Graph has rate limits.

1410
01:00:51,080 --> 01:00:53,840
They exist to protect the infrastructure from being overwhelmed.

1411
01:00:53,840 --> 01:00:56,520
Roughly 10,000 requests per 10 minutes per application.

1412
01:00:56,520 --> 01:01:00,880
That number sounds high until you actually start building continuous security pipelines.

1413
01:01:00,880 --> 01:01:04,840
Then you realize you can burn through that quota in minutes if you're not careful.

1414
01:01:04,840 --> 01:01:09,360
The practical challenge emerges once you start thinking like an operator, not a developer.

1415
01:01:09,360 --> 01:01:12,360
You're not making one query to understand how something works.

1416
01:01:12,360 --> 01:01:14,240
You're making queries continuously.

1417
01:01:14,240 --> 01:01:17,040
Every five minutes, you're pulling new alerts every minute.

1418
01:01:17,040 --> 01:01:19,800
You're checking for risky users every 10 seconds.

1419
01:01:19,800 --> 01:01:21,600
Your monitoring app activity patterns.

1420
01:01:21,600 --> 01:01:25,320
The requests add up, your quota disappears and your stock waiting for the reset.

1421
01:01:25,320 --> 01:01:26,600
But here's the problem.

1422
01:01:26,600 --> 01:01:28,960
Most organizations hitting rate limits are doing it wrong.

1423
01:01:28,960 --> 01:01:32,080
They aren't hitting limits because they're pulling massive amounts of data.

1424
01:01:32,080 --> 01:01:35,400
They're hitting limits because they're pulling the same data over and over in inefficient

1425
01:01:35,400 --> 01:01:36,400
ways.

1426
01:01:36,400 --> 01:01:40,120
Retrieving all alerts and then filtering client side instead of filtering server side,

1427
01:01:40,120 --> 01:01:43,800
making separate requests for each user instead of batching requests together.

1428
01:01:43,800 --> 01:01:46,640
Running the same query multiple times when they could cache results.

1429
01:01:46,640 --> 01:01:48,200
The solution is efficiency.

1430
01:01:48,200 --> 01:01:51,360
And efficiency means understanding the tools Graph gives you.

1431
01:01:51,360 --> 01:01:52,360
Filtering is your first lever.

1432
01:01:52,360 --> 01:01:55,480
Don't retrieve all alerts and then filter client side.

1433
01:01:55,480 --> 01:01:58,560
Use all data filters to tell the API what you actually want.

1434
01:01:58,560 --> 01:02:01,480
Send a filter like severity EQ high as part of your request.

1435
01:02:01,480 --> 01:02:03,160
The API filters on the server.

1436
01:02:03,160 --> 01:02:05,240
You get back only high severity alerts.

1437
01:02:05,240 --> 01:02:08,320
Fewer results, faster query, less data transfer.

1438
01:02:08,320 --> 01:02:11,040
One well-written filter cuts your request volume by half.

1439
01:02:11,040 --> 01:02:12,840
Pagination is the second lever.

1440
01:02:12,840 --> 01:02:14,320
Graph returns results in pages.

1441
01:02:14,320 --> 01:02:17,960
By default it returns 20 items per page if you want the next 20.

1442
01:02:17,960 --> 01:02:19,560
You paginate.

1443
01:02:19,560 --> 01:02:23,800
Using top to specify a larger page size means fewer pagination calls.

1444
01:02:23,800 --> 01:02:28,440
Asking for 50 items per page instead of 20 cuts your pagination overhead by 60% but don't

1445
01:02:28,440 --> 01:02:29,880
just pick a large number blindy.

1446
01:02:29,880 --> 01:02:30,880
There are limits.

1447
01:02:30,880 --> 01:02:33,680
The system has maximum page sizes for different endpoints.

1448
01:02:33,680 --> 01:02:35,480
Respect those.

1449
01:02:35,480 --> 01:02:39,440
Find the balance between fetching enough data to be efficient and not hitting the maximum.

1450
01:02:39,440 --> 01:02:42,280
Batching is more powerful but requires different thinking.

1451
01:02:42,280 --> 01:02:46,680
Instead of making 10 separate requests to get data about 10 different users you can batch

1452
01:02:46,680 --> 01:02:49,960
them into one request that returns all 10 users.

1453
01:02:49,960 --> 01:02:54,600
Graph's batch endpoint lets you pack multiple operations into a single HTTP call, one network

1454
01:02:54,600 --> 01:02:58,280
roundtrip, one rate limit consumption, 10 operations.

1455
01:02:58,280 --> 01:03:00,800
This is powerful when you're dealing with hundreds of items.

1456
01:03:00,800 --> 01:03:05,560
Time windowing changes the model entirely, instead of querying all alerts in my tenant.

1457
01:03:05,560 --> 01:03:08,160
Query alerts created in the last 5 minutes.

1458
01:03:08,160 --> 01:03:10,000
Instead of all audit events.

1459
01:03:10,000 --> 01:03:11,960
Query audit events from the last hour.

1460
01:03:11,960 --> 01:03:15,400
This dramatically reduces the data volume, your query is cheaper.

1461
01:03:15,400 --> 01:03:16,400
It's faster.

1462
01:03:16,400 --> 01:03:19,560
You're only getting new data, not reprocessing all data you already have.

1463
01:03:19,560 --> 01:03:22,840
The practical pattern for continuous ingestion works like this.

1464
01:03:22,840 --> 01:03:25,080
Create a scheduled job that runs every 5 minutes.

1465
01:03:25,080 --> 01:03:26,680
The job remembers when it last ran.

1466
01:03:26,680 --> 01:03:28,800
It queries for alerts created since that time.

1467
01:03:28,800 --> 01:03:30,560
It queries for audit events since that time.

1468
01:03:30,560 --> 01:03:32,600
It queries for risk detection since that time.

1469
01:03:32,600 --> 01:03:34,360
The job process is the data.

1470
01:03:34,360 --> 01:03:36,280
Updates its bookmarks, sleeps.

1471
01:03:36,280 --> 01:03:37,480
5 minutes later.

1472
01:03:37,480 --> 01:03:38,480
It runs again.

1473
01:03:38,480 --> 01:03:41,740
Now it only processes new data that arrived in those 5 minutes.

1474
01:03:41,740 --> 01:03:43,960
The system is efficient the quota lasts.

1475
01:03:43,960 --> 01:03:47,160
The ingestion is continuous without slamming the API.

1476
01:03:47,160 --> 01:03:50,660
Efficiency is what lets you actually run graph driven security at scale.

1477
01:03:50,660 --> 01:03:52,300
You're not trying to retrieve everything.

1478
01:03:52,300 --> 01:03:53,940
You're trying to retrieve what matters.

1479
01:03:53,940 --> 01:03:57,420
In the most efficient way possible, that discipline keeps you within limits and keeps your

1480
01:03:57,420 --> 01:03:59,340
system responsive.

1481
01:03:59,340 --> 01:04:01,140
Handling failures and latency.

1482
01:04:01,140 --> 01:04:02,940
Graph is a distributed system.

1483
01:04:02,940 --> 01:04:04,660
Sometimes, requests fail.

1484
01:04:04,660 --> 01:04:06,700
Sometimes the response takes longer than expected.

1485
01:04:06,700 --> 01:04:09,900
You're building continuous automation on top of an infrastructure that doesn't guarantee

1486
01:04:09,900 --> 01:04:11,500
instantaneous success.

1487
01:04:11,500 --> 01:04:12,700
Just reality.

1488
01:04:12,700 --> 01:04:14,700
The question isn't whether failures will happen.

1489
01:04:14,700 --> 01:04:17,020
The question is whether your pipeline survives them.

1490
01:04:17,020 --> 01:04:19,260
Four types of failures matter in practice.

1491
01:04:19,260 --> 01:04:21,260
Rate limiting returns HTTP 429.

1492
01:04:21,260 --> 01:04:22,700
You've exceeded your quota.

1493
01:04:22,700 --> 01:04:25,300
Temporary service issues return HTTP 503.

1494
01:04:25,300 --> 01:04:27,900
The backend is overloaded or temporarily down.

1495
01:04:27,900 --> 01:04:30,180
Authentication failures return HTTP 401.

1496
01:04:30,180 --> 01:04:33,100
Your token expired or your credentials are invalid.

1497
01:04:33,100 --> 01:04:35,220
Permission issues return HTTP 403.

1498
01:04:35,220 --> 01:04:38,100
Your app doesn't have permission to access what you're asking for.

1499
01:04:38,100 --> 01:04:40,340
Each one requires a different response strategy.

1500
01:04:40,340 --> 01:04:42,700
When you hit rate limiting, you wait and retry.

1501
01:04:42,700 --> 01:04:44,620
The response header tells you how long to wait.

1502
01:04:44,620 --> 01:04:45,620
Respect that.

1503
01:04:45,620 --> 01:04:46,620
Don't be aggressive.

1504
01:04:46,620 --> 01:04:49,140
Don't hammer the API, hoping it recovers faster.

1505
01:04:49,140 --> 01:04:51,460
The system is telling you to back off.

1506
01:04:51,460 --> 01:04:54,180
Once you wait the requested duration, retry the request.

1507
01:04:54,180 --> 01:04:55,740
It'll usually succeed.

1508
01:04:55,740 --> 01:04:57,260
Temporary service issues are similar.

1509
01:04:57,260 --> 01:04:58,500
The backend is having trouble.

1510
01:04:58,500 --> 01:04:59,500
Wait and retry.

1511
01:04:59,500 --> 01:05:02,380
But don't use the same wait duration as rate limiting.

1512
01:05:02,380 --> 01:05:03,980
Service issues might need longer.

1513
01:05:03,980 --> 01:05:05,540
Use exponential back off.

1514
01:05:05,540 --> 01:05:06,620
Start with one second.

1515
01:05:06,620 --> 01:05:09,860
If the retry fails, wait two seconds before the next attempt.

1516
01:05:09,860 --> 01:05:12,620
If you wait for, then wait until you hit a maximum.

1517
01:05:12,620 --> 01:05:13,620
Maybe five minutes.

1518
01:05:13,620 --> 01:05:16,940
Add randomness to the wait duration so you don't have a thousand applications or retrying

1519
01:05:16,940 --> 01:05:18,380
at exactly the same time.

1520
01:05:18,380 --> 01:05:20,020
That randomness is called jitter.

1521
01:05:20,020 --> 01:05:23,500
It prevents thundering herd problems where synchronized retry attempts hammer the service

1522
01:05:23,500 --> 01:05:25,340
and keep it down longer.

1523
01:05:25,340 --> 01:05:27,220
Authentication failures need a different approach.

1524
01:05:27,220 --> 01:05:28,220
Your token expired.

1525
01:05:28,220 --> 01:05:30,620
Don't retry the same request with the same token.

1526
01:05:30,620 --> 01:05:32,220
You'll just get 401 again.

1527
01:05:32,220 --> 01:05:36,020
Instead, refresh your token, get a new one, then retry the original request.

1528
01:05:36,020 --> 01:05:39,020
If refreshing the token fails, something's wrong with your credentials.

1529
01:05:39,020 --> 01:05:40,020
Don't keep retrying.

1530
01:05:40,020 --> 01:05:41,180
You won't fix it by trying harder.

1531
01:05:41,180 --> 01:05:42,900
You need human intervention.

1532
01:05:42,900 --> 01:05:47,100
Permission issues mean your application doesn't have permission to access what you're asking

1533
01:05:47,100 --> 01:05:48,100
for.

1534
01:05:48,100 --> 01:05:49,100
Retrying won't fix that.

1535
01:05:49,100 --> 01:05:50,100
The problem isn't transient.

1536
01:05:50,100 --> 01:05:51,100
It's structural.

1537
01:05:51,100 --> 01:05:52,100
You need higher permissions.

1538
01:05:52,100 --> 01:05:53,100
Log the error.

1539
01:05:53,100 --> 01:05:54,100
Skip this request.

1540
01:05:54,100 --> 01:05:55,100
Move on.

1541
01:05:55,100 --> 01:05:57,100
Don't consume retries on something that will never succeed.

1542
01:05:57,100 --> 01:05:59,100
Identity is where most automation fails.

1543
01:05:59,100 --> 01:06:03,620
Let's say your pipeline pulls an alert, processes it, and stores it in your CM.

1544
01:06:03,620 --> 01:06:07,300
But the network timeouts before you get a success confirmation.

1545
01:06:07,300 --> 01:06:10,900
Did the store succeed?

1546
01:06:10,900 --> 01:06:11,900
You don't know.

1547
01:06:11,900 --> 01:06:13,420
So you retry.

1548
01:06:13,420 --> 01:06:14,820
The alert gets stored again.

1549
01:06:14,820 --> 01:06:17,420
Now you have two copies of the same alert in your system.

1550
01:06:17,420 --> 01:06:18,420
This creates noise.

1551
01:06:18,420 --> 01:06:20,260
It triggers duplicate notifications.

1552
01:06:20,260 --> 01:06:21,660
It messes up your metrics.

1553
01:06:21,660 --> 01:06:23,900
The solution is IDEM potency.

1554
01:06:23,900 --> 01:06:27,820
Design your system so that processing the same alert twice produces the same result as

1555
01:06:27,820 --> 01:06:29,340
processing it once.

1556
01:06:29,340 --> 01:06:30,700
Use the duplication.

1557
01:06:30,700 --> 01:06:33,660
Check if an alert with this ID already exists before storing it.

1558
01:06:33,660 --> 01:06:35,100
If it does, skip it.

1559
01:06:35,100 --> 01:06:37,220
If it doesn't, store it.

1560
01:06:37,220 --> 01:06:39,100
Now duplicates don't create problems.

1561
01:06:39,100 --> 01:06:41,340
Latency handling is about accepting reality.

1562
01:06:41,340 --> 01:06:43,540
Alerts might take five minutes to appear in graph.

1563
01:06:43,540 --> 01:06:45,140
Your automation should tolerate that.

1564
01:06:45,140 --> 01:06:47,380
Don't build systems that expect real time.

1565
01:06:47,380 --> 01:06:50,300
Don't design responses that assume instant feedback.

1566
01:06:50,300 --> 01:06:52,620
Design for eventual consistency.

1567
01:06:52,620 --> 01:06:54,820
Your job isn't to know everything immediately.

1568
01:06:54,820 --> 01:06:58,060
Your job is to know everything correctly within an acceptable time frame.

1569
01:06:58,060 --> 01:07:00,180
Your pipeline should handle failures gracefully.

1570
01:07:00,180 --> 01:07:01,020
Log them.

1571
01:07:01,020 --> 01:07:02,500
Alert on repeated failures.

1572
01:07:02,500 --> 01:07:04,940
If the same query fails three times in a row.

1573
01:07:04,940 --> 01:07:06,980
If you calculate to a human, maybe there's a real problem.

1574
01:07:06,980 --> 01:07:08,260
Maybe permissions changed.

1575
01:07:08,260 --> 01:07:11,420
Maybe the graph service is having broader issues when something breaks repeatedly.

1576
01:07:11,420 --> 01:07:15,660
You need to know the real model is simple reliability beats speed.

1577
01:07:15,660 --> 01:07:20,220
A slow system that always works beats a fast system that occasionally fails.

1578
01:07:20,220 --> 01:07:21,220
Design for that.

1579
01:07:21,220 --> 01:07:22,220
Build.

1580
01:07:22,220 --> 01:07:23,220
Retry logic.

1581
01:07:23,220 --> 01:07:24,740
Design for IDEM potency.

1582
01:07:24,740 --> 01:07:25,740
Accept latency.

1583
01:07:25,740 --> 01:07:26,740
Monitor failures.

1584
01:07:26,740 --> 01:07:27,740
These aren't nice to have.

1585
01:07:27,740 --> 01:07:31,140
They're the foundation of a system that actually works at scale.

1586
01:07:31,140 --> 01:07:32,660
Governing graph access.

1587
01:07:32,660 --> 01:07:33,820
Graph is powerful.

1588
01:07:33,820 --> 01:07:37,980
And application with the wrong permissions can do damage that takes months to fully understand.

1589
01:07:37,980 --> 01:07:39,460
You need governance.

1590
01:07:39,460 --> 01:07:42,020
But not the kind of governance that says no to everything.

1591
01:07:42,020 --> 01:07:44,460
You need a model that says yes, but with controls.

1592
01:07:44,460 --> 01:07:45,620
The difference is simple.

1593
01:07:45,620 --> 01:07:49,700
It determines if your organization innovates safely or if it innovates recklessly.

1594
01:07:49,700 --> 01:07:53,700
The permission model in graph uses Microsoft Entra permissions where every application needs

1595
01:07:53,700 --> 01:07:56,460
explicit permission to call a specific endpoint.

1596
01:07:56,460 --> 01:07:59,420
When you register an app, you specify exactly what it needs.

1597
01:07:59,420 --> 01:08:02,860
When you deploy it, an administrator has to consent to those permissions.

1598
01:08:02,860 --> 01:08:04,540
That consent creates a grant.

1599
01:08:04,540 --> 01:08:08,220
And that grant is what allows the application to finally call those endpoints.

1600
01:08:08,220 --> 01:08:10,780
The practical model starts with one principle.

1601
01:08:10,780 --> 01:08:12,300
Leased privilege.

1602
01:08:12,300 --> 01:08:15,780
Request only the permissions your application actually needs right now.

1603
01:08:15,780 --> 01:08:17,580
Not the permissions it might need someday.

1604
01:08:17,580 --> 01:08:21,620
And definitely not the permissions of vendor through in just to future proof their software.

1605
01:08:21,620 --> 01:08:23,180
This is harder than it sounds.

1606
01:08:23,180 --> 01:08:26,620
Vendors have a habit of requesting broad permissions because mail, read, write.

1607
01:08:26,620 --> 01:08:29,500
All is easier for them to implement than specific scenarios.

1608
01:08:29,500 --> 01:08:32,780
But what is easier for them creates a massive risk for you.

1609
01:08:32,780 --> 01:08:34,660
What categories matter?

1610
01:08:34,660 --> 01:08:37,140
Read only permissions are safer than write permissions.

1611
01:08:37,140 --> 01:08:39,220
And write permissions are safer than administrative ones.

1612
01:08:39,220 --> 01:08:42,780
You can see this in the naming, mail, don't read is safer than mail, read write, which is

1613
01:08:42,780 --> 01:08:46,060
safer than mail, read write, all.

1614
01:08:46,060 --> 01:08:48,940
The scope of each permission shapes the risk.

1615
01:08:48,940 --> 01:08:53,140
A permission that applies only to the signed end user creates much less exposure than one

1616
01:08:53,140 --> 01:08:55,060
that covers the entire tenant.

1617
01:08:55,060 --> 01:08:57,060
Build your strategy around this hierarchy.

1618
01:08:57,060 --> 01:08:59,740
Admin consent is required for high risk permissions.

1619
01:08:59,740 --> 01:09:03,420
And an app wants to access the entire organization or change the directory structure.

1620
01:09:03,420 --> 01:09:04,900
An administrator has to approve it.

1621
01:09:04,900 --> 01:09:06,580
This isn't security theater.

1622
01:09:06,580 --> 01:09:08,100
It is a genuine speed bump.

1623
01:09:08,100 --> 01:09:12,020
Someone has to look at the request and decide if it makes sense or if it is simply too risky.

1624
01:09:12,020 --> 01:09:16,220
That moment of deliberation is what catches mistakes and intentional overreach.

1625
01:09:16,220 --> 01:09:18,420
Conditional access now extends to workload identities.

1626
01:09:18,420 --> 01:09:21,580
These are your service principles and your automated processes.

1627
01:09:21,580 --> 01:09:25,700
You can apply conditional access policies to these apps just like you do for your users.

1628
01:09:25,700 --> 01:09:30,100
To make them to known locations require them to authenticate only from specific IP ranges.

1629
01:09:30,100 --> 01:09:33,700
In force MFA for sensitive operations, if a service principle suddenly starts making

1630
01:09:33,700 --> 01:09:37,100
requests from an unexpected location, conditional access can block it.

1631
01:09:37,100 --> 01:09:39,300
This is how you defend automation against abuse.

1632
01:09:39,300 --> 01:09:40,620
Ordered everything.

1633
01:09:40,620 --> 01:09:43,420
Use graph activity logs to see what applications are actually doing.

1634
01:09:43,420 --> 01:09:46,460
If an app requested mail, read write all six months ago.

1635
01:09:46,460 --> 01:09:48,860
But the logs show it has never made a right request.

1636
01:09:48,860 --> 01:09:50,180
That permission is unnecessary.

1637
01:09:50,180 --> 01:09:51,220
You can revoke it.

1638
01:09:51,220 --> 01:09:53,900
The app still functions, but your exposure shrinks.

1639
01:09:53,900 --> 01:09:55,460
This is governance in motion.

1640
01:09:55,460 --> 01:09:57,740
It isn't a one time policy that sits on a shelf.

1641
01:09:57,740 --> 01:10:01,180
It is a continuous review based on how things are actually used.

1642
01:10:01,180 --> 01:10:03,940
Approval workflows matter for high-risk decisions.

1643
01:10:03,940 --> 01:10:07,460
When someone requests a new application or permission bump, where does that request go?

1644
01:10:07,460 --> 01:10:08,540
Does it sit in an inbox?

1645
01:10:08,540 --> 01:10:10,060
Does it get auto-approved?

1646
01:10:10,060 --> 01:10:12,540
You need to define the workflow and document it.

1647
01:10:12,540 --> 01:10:17,260
Make it clear that high-risk permissions require a visible and auditable approval process.

1648
01:10:17,260 --> 01:10:18,660
This creates accountability.

1649
01:10:18,660 --> 01:10:20,020
Someone's name is on that approval.

1650
01:10:20,020 --> 01:10:23,660
So if something goes wrong, there is a record of why that decision was made.

1651
01:10:23,660 --> 01:10:26,180
Where reviews create discipline.

1652
01:10:26,180 --> 01:10:28,180
Quarterly is a reasonable minimum for this.

1653
01:10:28,180 --> 01:10:31,820
Pull the list of all applications and their permissions and then ask the hard questions.

1654
01:10:31,820 --> 01:10:33,300
Do we still use this app?

1655
01:10:33,300 --> 01:10:34,820
Do we still need these permissions?

1656
01:10:34,820 --> 01:10:36,860
Are there new apps we haven't reviewed yet?

1657
01:10:36,860 --> 01:10:38,180
Remove the ones you don't need.

1658
01:10:38,180 --> 01:10:39,940
And reduce the permissions on the ones you keep.

1659
01:10:39,940 --> 01:10:40,940
This isn't punishment.

1660
01:10:40,940 --> 01:10:42,180
It's housekeeping.

1661
01:10:42,180 --> 01:10:45,380
It is the difference between a tight security posture and one that is slowly eroded

1662
01:10:45,380 --> 01:10:46,380
by inertia.

1663
01:10:46,380 --> 01:10:47,980
The real insight about governance is simple.

1664
01:10:47,980 --> 01:10:49,500
It's not about saying no.

1665
01:10:49,500 --> 01:10:52,740
It's about creating a system where yes is informed and intentional.

1666
01:10:52,740 --> 01:10:54,060
Your permissions are justified.

1667
01:10:54,060 --> 01:10:56,300
Use is visible and removal is easy.

1668
01:10:56,300 --> 01:10:57,700
That system doesn't stop innovation.

1669
01:10:57,700 --> 01:10:58,700
It enables it.

1670
01:10:58,700 --> 01:11:00,340
You aren't blocking applications.

1671
01:11:00,340 --> 01:11:04,140
You are making sure they are deployed with the minimum power necessary to do the job.

1672
01:11:04,140 --> 01:11:05,700
That is the model that scales.

1673
01:11:05,700 --> 01:11:06,980
The title said trick.

1674
01:11:06,980 --> 01:11:10,380
How to trick Microsoft Graph into securing your entire tenant.

1675
01:11:10,380 --> 01:11:11,820
But the trick isn't a trick at all.

1676
01:11:11,820 --> 01:11:15,860
It's understanding something structural that most organizations completely miss.

1677
01:11:15,860 --> 01:11:17,020
Graph isn't just an API.

1678
01:11:17,020 --> 01:11:20,900
It is the actual governance engine underneath everything in Microsoft 365.

1679
01:11:20,900 --> 01:11:23,660
Every security decision in your tenant flows through it.

1680
01:11:23,660 --> 01:11:28,220
Every sign-in, every policy evaluation, every permission grant, it is all graph and when

1681
01:11:28,220 --> 01:11:30,300
you understand that everything changes.

1682
01:11:30,300 --> 01:11:31,820
You stop looking at portals.

1683
01:11:31,820 --> 01:11:34,060
You stop doing manual quarterly permission audits.

1684
01:11:34,060 --> 01:11:36,620
You stop waiting for analysts to investigate alerts.

1685
01:11:36,620 --> 01:11:38,620
Instead, you build a continuous system.

1686
01:11:38,620 --> 01:11:40,220
Data flows in from graph.

1687
01:11:40,220 --> 01:11:41,900
It is enriched automatically.

1688
01:11:41,900 --> 01:11:44,260
And it is correlated across every source you have.

1689
01:11:44,260 --> 01:11:46,340
It triggers responses without human delay.

1690
01:11:46,340 --> 01:11:49,740
Your security starts operating at machine speed, not human speed.

1691
01:11:49,740 --> 01:11:51,540
Microsoft is retiring legacy APIs.

1692
01:11:51,540 --> 01:11:53,540
The 2026 shift is real.

1693
01:11:53,540 --> 01:11:56,780
Everything is consolidating onto the graph security API v2.

1694
01:11:56,780 --> 01:11:58,100
That isn't Microsoft being nice.

1695
01:11:58,100 --> 01:12:01,980
That is Microsoft forcing the industry to make a structural shift that should have happened

1696
01:12:01,980 --> 01:12:02,980
years ago.

1697
01:12:02,980 --> 01:12:05,380
The organizations that understand this now have an advantage.

1698
01:12:05,380 --> 01:12:07,700
They aren't scrambling to migrate when the deadline hits.

1699
01:12:07,700 --> 01:12:09,540
They've already built their security engine.

1700
01:12:09,540 --> 01:12:11,140
They're people understand graph.

1701
01:12:11,140 --> 01:12:13,740
And their automations are already working when the deadline comes.

1702
01:12:13,740 --> 01:12:14,740
They are ready.

1703
01:12:14,740 --> 01:12:15,740
That's the model.

1704
01:12:15,740 --> 01:12:17,300
That's security for 2026.

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.