July 2, 2026

Beyond the Portal: The Strategic Architecture of Microsoft Graph and PowerShell

Microsoft Graph is far more than just another API—it is the operational backbone of Microsoft 365. This episode explains why relying solely on admin portals limits scalability, visibility, and automation, while Microsoft Graph provides a unified interface for managing identities, users, groups, Teams, SharePoint, security, compliance, and business data across the entire Microsoft ecosystem.

The discussion explores how Microsoft Graph PowerShell enables administrators to automate repetitive tasks, manage large environments consistently, and build governance processes that simply cannot be achieved through manual portal administration. Understanding authentication, OAuth, delegated and application permissions, service principals, and least-privilege access is presented as essential for building secure enterprise automation.

The episode also highlights Microsoft's AI strategy, explaining that services such as Microsoft Copilot, Copilot Studio, AI agents, and future intelligent workloads all rely on Microsoft Graph to access organizational knowledge and perform actions securely. Organizations investing in Graph today are therefore laying the architectural foundation for enterprise AI tomorrow.

Finally, the podcast demonstrates how Graph serves as a powerful platform for security operations, governance, and compliance by providing visibility across Microsoft 365 and enabling automated monitoring, reporting, and policy enforcement. The key takeaway is clear: organizations that treat Microsoft Graph as strategic infrastructure rather than just an API will be better positioned to automate operations, strengthen security, and prepare for the next generation of AI-powered enterprise solutions.

You can transform your Microsoft 365 environment by shifting from manual portal tasks to unified, automated management. With Microsoft Graph and PowerShell, you gain consistent control over identity and resource management across the Microsoft ecosystem. Automation through these tools lets you respond faster to security and governance needs in the cloud and simplifies compliance.

Automation frees up your team from repetitive tasks and enables scalable policy enforcement.
Microsoft Graph ensures that changes apply consistently, even across Azure Active Directory and DevOps environments.
Integration with Microsoft Purview supports audit trails and data residency, strengthening compliance.

By embracing automation, you prepare your organization for future innovations and AI-driven workflows.

Key Takeaways

Automation with Microsoft Graph and PowerShell saves time by handling repetitive tasks, allowing your team to focus on important projects.
Using Microsoft Graph ensures consistent management across Microsoft 365 services, reducing errors and improving efficiency.
Automating user onboarding and offboarding processes helps maintain security and compliance while speeding up access for new employees.
Microsoft Graph provides a unified interface for managing resources across various Microsoft services, simplifying your workflow.
Implementing automated policies helps enforce security measures consistently, protecting your organization from risks.
Regularly reviewing permissions and using least privilege principles minimizes the risk of unauthorized access to sensitive data.
Testing and documenting your automation workflows ensures reliability and helps prevent errors during deployment.
Embracing automation prepares your organization for future innovations, making it more agile and ready for change.

Portal Limitations in Microsoft 365

Manual Management Challenges

Inefficiency and Errors

You may notice that managing Microsoft 365 through portals can slow down your work. Manual tasks, like updating user information or assigning licenses, often take much longer than you expect. Studies show that you can lose up to 15 hours each week on repetitive tasks that automation could handle. This time adds up quickly, taking away from more important projects.

Manual data entry also increases the risk of mistakes. For every 10,000 fields you enter, you might see anywhere from 4 to 650 errors. These errors can lead to problems such as incorrect payments or compliance failures. If you manage a large organization, these mistakes can multiply and cause even bigger issues.

Manual processes create operational drag.
Human error becomes a real risk as your team grows.
Repetitive tasks drain valuable time and energy.

Scalability Issues

As your organization grows, portal-based management becomes harder to scale. You may need to manage thousands of users, devices, and groups. The portal interface was not designed for this level of complexity. You might find yourself clicking through endless menus and screens just to complete simple tasks.

Here is a table that highlights some common limitations you may face:

Limitation Description	Details
Permissions Scope	Permissions granted by delegated admin are too broad, lacking fine-grained access control and clear auditing capabilities.
Role Customization	Default roles cannot be customized to meet specific organizational needs, limiting flexibility.
Regional Management	No option to set up regional management rights for local business unit administrators, complicating management in large enterprises.
Overly Powerful Roles	Admins often have global credentials or are assigned overly powerful roles, leading to security concerns.

Security and Compliance Gaps

Policy Enforcement Limits

You may struggle to enforce consistent policies across your environment when using portals. The default roles often give too much power to administrators. You cannot always customize these roles to fit your needs. This lack of control can create gaps in your security posture.

Some common gaps include:

Multi-factor authentication is not enforced for all users.
Legacy authentication methods remain active.
Too many users have permanent admin rights.
Guest users and OAuth apps are not reviewed regularly.

Audit and Reporting Shortfalls

Portals often make it difficult to track changes and generate detailed reports. You may not have the tools you need to review audit logs or respond to incidents quickly. This can leave your organization exposed to risks.

The table below shows some of the most common gaps:

Category	Specific Gaps
Identity Gaps	MFA is not enforced for all users or administrators, Legacy authentication remains allowed, Too many privileged roles or permanent admins, Guest users and OAuth apps are not reviewed
Email and Defender Gaps	External forwarding is not restricted, Mail flow rules bypass security controls, DMARC is not enforced, Safe Links or Safe Attachments are incomplete
Data and Evidence Gaps	SharePoint anonymous links are allowed, DLP policies are missing or only in test mode, Audit logs are not reviewed, No Microsoft 365 incident response procedure exists

Tip: Automating these processes with Microsoft Graph and PowerShell can help you close these gaps and strengthen your security and compliance efforts.

Microsoft Graph Architecture for Unified Access

Microsoft Graph API Overview

Unified Data Layer

You need a single place to manage your Microsoft 365 environment. Microsoft Graph serves as the operational backbone for Microsoft 365. It brings together data from many Microsoft services into one unified data layer. You can access information about users, groups, devices, and applications without switching between different tools.

You can use Microsoft Graph to connect with Microsoft 365 core services like Teams, SharePoint, and Outlook.
You can manage enterprise mobility and security through services such as Microsoft Entra and Intune.
You can reach Windows services, including device management and notifications.
You can access Dynamics 365 Business Central and Microsoft Partner Center data.

Microsoft Graph API gives you a single endpoint at https://graph.microsoft.com. This endpoint lets you work with people-centric data and insights across the Microsoft cloud. You can improve productivity, collaboration, and security with this unified approach.

Integration with PowerShell

You can use PowerShell to automate tasks with Microsoft Graph. This integration allows you to script complex operations and manage resources at scale. You do not need to rely on manual steps in the portal. PowerShell and Microsoft Graph together help you enforce policies, manage user lifecycles, and respond quickly to changes.

You can also use Microsoft Graph SDKs to simplify your scripts. These SDKs provide ready-made functions for common tasks. You can write less code and reduce errors. The SDKs support many programming languages, so you can choose the tools that fit your workflow.

Extensibility and Interoperability

Custom Automation

You can extend Microsoft Graph to fit your unique business needs. Microsoft Graph lets you add custom data to resources. You can use extension attributes, directory extensions, schema extensions, or open extensions. Each type supports different automation scenarios. You can choose the right extension for your application and integrate it with your existing systems.

Extension attributes help you store extra information about users or groups.
Directory extensions let you add custom properties to Azure Active Directory objects.
Schema extensions allow you to define new types of data for your organization.
Open extensions give you a flexible way to attach data to any resource.

This flexibility means you can automate processes that match your business rules. You can build solutions that grow with your organization.

Cross-Service Management

You can manage resources across many Microsoft services with Microsoft Graph. You do not need to learn different APIs for each service. Microsoft Graph API connects you to Teams, SharePoint, Outlook, and more. You can automate workflows that span multiple services.

Here is a table that shows the architectural advantages of Microsoft Graph compared to traditional Microsoft 365 management APIs:

Advantage	Description
Unified Access Layer	Microsoft Graph connects various Microsoft services through a single platform, simplifying access to multiple resources.
Centralized Nature	Reduces the need for managing separate access tokens, streamlining the development process for applications.
Enhanced Automation Capabilities	Facilitates smoother workflows and decreases latency by consolidating multiple API calls into a single endpoint.

You can use a single API endpoint for many Microsoft services. This reduces complexity and makes your automation more reliable. Consistent authentication flows and unified permission scopes help you manage security and compliance. The unified model improves scalability and consistency across your applications.

Note: By using Microsoft Graph and Microsoft Graph SDKs, you can create powerful automation that supports your cloud, devops, and identity strategies. You prepare your organization for future growth and innovation.

Automating User Lifecycle with Microsoft Graph API

Provisioning and Deprovisioning

Onboarding Automation

You can streamline onboarding by using automation tools like Microsoft Graph and PowerShell. When you hire new employees, you want their accounts, permissions, and resources ready on day one. Microsoft Graph lets you automate provisioning tasks, so you do not need to create accounts or assign licenses manually. You can use group-based dynamic provisioning to manage user access based on roles or attributes. This approach ensures that new hires receive the correct permissions and resources without delay.

You can leverage PowerShell automation to connect with Microsoft Graph and Azure. You can write a PowerShell script that creates users, assigns licenses, and adds them to the right groups. You can also set up monitoring and auditing to detect anomalies and ensure compliance. By automating these steps, you reduce errors and save time.

Here is a table showing how automation improves onboarding and offboarding speed:

Improvement Aspect	Before Automation	After Automation	Time Reduction
Time to full provisioning	Days	Hours	Significant
Manual follow-up required	Yes	No	Complete removal
License deallocation timing	Variable	On-time	Exact timing
Tech team involvement	High	Low	Drastic reduction
HR tracking overhead	High	None	Eliminated
New hire infrastructure readiness	Later in week	Day 1	Immediate
Compliance risk with orphaned accounts	High	Low	Reduced risk

Tip: Automating onboarding with Microsoft Graph helps you deliver a smooth experience for new employees and reduces compliance risks.

Secure Offboarding

You need to protect your organization when employees leave. Secure offboarding is critical for maintaining security and compliance. Microsoft Graph and PowerShell automation let you remove user access quickly and accurately. You can use CMD commands and Group Policy settings to control local account access after deprovisioning. You can modify Windows Registry settings to manage cached credentials and track user activity.

You can automate license removal and group membership changes. You can also set up monitoring and auditing to detect any anomalies during deprovisioning. This process ensures that former employees cannot access sensitive data or cloud resources. Automation reduces the risk of orphaned accounts and improves your security posture.

Note: By automating secure offboarding, you protect your identity infrastructure and reduce manual workload for your tech and HR teams.

Managing Collaboration at Scale

Teams and SharePoint Automation

You can manage collaboration across Microsoft Teams and SharePoint at scale with Microsoft Graph. The API provides a unified interface for accessing data across Microsoft 365 services. You can automate workflows and trigger alerts based on specific events. This approach improves productivity and supports proactive management strategies.

You can build custom aggregation tools that collect data from SharePoint, Outlook, Teams, and OneDrive. These tools synthesize information into actionable insights. Integrated applications can link Teams meetings to relevant SharePoint documents, improving context and accessibility. Custom applications can generate calendar events from SharePoint list items, creating seamless workflows across services.

Real-time data access allows SharePoint portals to display live notifications from Teams or Outlook. This feature keeps users informed and enhances collaboration. You can use automation to streamline these processes and reduce manual effort.

Callout: Successful implementation requires careful planning. You should optimize for scalability and performance. Developers should cache tokens securely and use efficient query batching. Continuous monitoring and logging help you resolve issues quickly and maintain system health.

Dynamic Groups and Permissions

You can use Microsoft Graph to automate dynamic group management and permissions. Group-based provisioning lets you assign access based on user attributes or roles. When a user changes departments or job roles, automation updates their group memberships and permissions. This process ensures that users always have the correct access.

You can leverage PowerShell automation to manage group policies and permissions across Microsoft 365 and Azure. Automation helps you enforce least privilege principles and maintain compliance. You can monitor and audit group changes to detect anomalies and prevent unauthorized access.

Tip: Automating dynamic groups and permissions with Microsoft Graph supports your devops and cloud strategies. You gain better control over your identity infrastructure and reduce manual workload.

Security, Permissions, and Idempotency

Modern Authentication

OAuth and Certificates

You need strong authentication to protect your Microsoft 365 environment. Modern authentication methods, such as OAuth and certificates, help you secure access to resources. These methods use tokens that expire quickly, so attackers have less time to misuse them. You can also enforce multi-factor authentication, which adds another layer of protection. Continuous Access Evaluation lets you revoke tokens if you detect risky activity. The table below shows how these features improve security:

Feature	Benefit
Token expiration	Access tokens have a limited usable lifetime, reducing the risk of unauthorized access.
Multi-factor authentication (MFA)	Simplifies the enforcement of MFA, enhancing security by requiring additional verification.
Continuous Access Evaluation (CAE)	Allows for proactive token revocation based on specific risks, improving overall security.

App Registrations

You register applications in Azure to control how they access Microsoft Graph. App registrations let you define permissions and manage secrets or certificates. This process gives you clear visibility into which apps have access to your data. You can monitor and update permissions as your needs change. By using app registrations, you keep your environment secure and organized.

Permission Debt and Least Privilege

Identifying Excess

You should always follow the least privilege principle. This means giving users and apps only the permissions they need. If you grant too many permissions, you increase the risk of unauthorized access. Attackers can do more damage if they compromise an account with broad access. Microsoft Graph supports fine-grained permission management, which helps you protect sensitive data and meet compliance requirements. The table below highlights why least privilege matters:

Practice	Security Impact
Excessive permissions	Increases risk if credentials are compromised.
Fine-grained permission control	Protects sensitive data and supports compliance.
Least privilege for automation	Minimizes unauthorized access and prevents privilege escalation.

Remediation Steps

You can reduce permission debt by following these strategies:

Assign clear ownership for every resource to improve accountability.
Review permissions regularly and link them to governance roles.
Audit external users and remove unnecessary access.
Send attestation requests to group owners to confirm user access.
Monitor inactive accounts and remove them.
Enforce multi-factor authentication for privileged accounts.

These steps help you maintain a secure and well-governed Microsoft 365 environment.

Idempotent Automation

Reliable Workflows

You want your automation to run smoothly every time. Idempotent automation ensures that running a script multiple times does not cause problems or duplicate actions. When you use PowerShell with Microsoft Graph, you can automate tasks like user onboarding, license management, and report generation. This approach streamlines your processes, improves reliability, and reduces manual errors. You save time and keep your workflows consistent.

Automation leads to faster execution.
It reduces the likelihood of errors.
Consistency in operations is improved.
Significant time savings are achieved.

Error Handling

You need to handle errors effectively in your automation. Structured logging helps you track what happens during each run. You can separate critical failures from minor issues. This practice allows you to recover quickly and keep your operations running. By building reliable error handling into your scripts, you support your devops and security goals.

Best Practices for Microsoft Graph Automation

Workflow Design

You need a clear plan to build scalable and maintainable automation workflows. Microsoft Graph and PowerShell help you manage complex tasks, but you must design your workflows carefully. Start by mapping out each step. Identify who owns each process and set up approval paths. You should always include rollback procedures in case something goes wrong.

Document every automated identity workflow. Include ownership, approval paths, and rollback procedures.
Test changes in a limited scope before scaling them across your tenant.
Enforce separation of duties. This reduces security risks and keeps your environment safe.
Use configuration-driven, parameterized scripts. This approach maintains flexibility and supports collaboration across teams.

Tip: Configuration-driven scripts make it easier to adapt your automation for different departments or business units.

Testing and Validation

You must test your automation before deploying it. Create a test environment that matches your production setup. Run your scripts and check for errors. Validate that each workflow produces the expected results. Testing helps you catch mistakes early and prevents disruptions.

Testing Step	Purpose	Outcome
Limited Scope Test	Identify issues in small scale	Safe rollout
Validation Checks	Confirm expected results	Reliable automation
Error Simulation	Prepare for failures	Robust workflows

Staging and Deployment

Staging is a key step in your deployment process. Move your tested workflows to a staging environment. Monitor their performance and gather feedback. Once you confirm stability, deploy your automation to production. Use Azure DevOps to track changes and manage releases. This process ensures smooth transitions and minimizes risks.

Documentation and Change Control

You must keep comprehensive documentation for every automation project. Good documentation streamlines processes and reduces errors. Centralized data improves consistency across your outputs. Automation saves time and costs while enhancing quality.

Document every script and workflow.
Store information in a central location.
Update documentation when you make changes.

Note: Effective change management helps you address errors and adapt to new requirements efficiently.

Versioning

Version control is essential for managing your scripts and workflows. Track changes and keep records of previous versions. This practice helps you roll back to earlier states if needed. Use tools like Git to manage your code and documentation.

Stakeholder Communication

You must communicate with stakeholders throughout your automation projects. Share updates and gather feedback. Clear communication helps you align goals and expectations. It also ensures that everyone understands the impact of new workflows.

Callout: Regular meetings and status reports keep your team informed and engaged.

Governance, Compliance, and Insights

Policy Enforcement

Automated Policies

You can enforce policies automatically across your Microsoft 365 environment using Microsoft Graph. Automation helps you apply consistent rules for authentication, access, and group management. You can use specific API endpoints to retrieve and update authentication requirements, manage multi-factor authentication, and control conditional access. The table below shows some useful endpoints for policy automation:

API Endpoint	Description
GET https://graph.microsoft.com/beta/users/user@domain.com/authentication/requirements	Retrieve current authentication requirements for a user.
PATCH https://graph.microsoft.com/beta/users/user@domain.com/authentication/requirements	Update the user's MFA state to enabled for granular control.
GET https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/microsoftAuthenticator	Retrieve Microsoft Authenticator settings to prevent MFA fatigue.
Conditional access policies	Automate controls for access management.
Admin consent policy resource	Manage admin consent settings.
Directory settings	Manage password protection and group-related settings.

Automated policies reduce manual work and help you meet compliance standards. You can integrate these controls with your devops workflows for faster response to changes.

Real-Time Compliance

You can achieve real-time compliance by monitoring and enforcing policies as events happen. Microsoft Graph lets you automate the detection of risky activities and apply corrective actions immediately. You can use conditional access and directory settings to block unauthorized access and enforce security requirements. This approach helps you respond quickly to threats and maintain a strong security posture.

Data Security and Privacy

Sensitive Data Protection

You need to protect sensitive information in your organization. Microsoft Purview APIs help you enforce data security policies across all your applications. Data Loss Prevention (DLP) policies stop the accidental sharing of confidential data. Collection policies monitor and classify events, so you can detect and govern sensitive activities. These tools help you keep your data safe and meet privacy requirements.

Consistent policy enforcement across apps
DLP to control data movement
Event monitoring for sensitive activities

Regulatory Support

You must follow industry regulations and legal standards. Microsoft Purview eDiscovery helps you manage compliance with automated workflows and retention labels. Many organizations have reduced costs by eliminating third-party tools and simplifying their architecture. A three-year analysis showed a 37% cost savings with Purview eDiscovery compared to traditional solutions. You can also reduce software licensing and implementation costs. Automated preservation ensures you meet legal requirements without manual effort.

Note: Automated compliance workflows improve risk mitigation and operational efficiency.

Audit and Reporting

Automated Trails

You can track all administrative actions and compliance events using Microsoft Graph APIs. The unified audit log captures thousands of operations across Microsoft 365 services. You can search and retrieve audit logs programmatically, which helps you meet compliance obligations and investigate security incidents. Integration with SIEM tools allows you to automate exports and correlate activities across services.

Unified audit log for all workloads
Programmatic access to audit records
Integration with compliance and reporting tools

Custom Reports

You can create custom reports to gain insights into user activities and administrative actions. Microsoft Graph APIs let you filter and export audit data based on your needs. You can automate scheduled reports and share them with stakeholders. This visibility supports your governance strategy and helps you make informed decisions.

Tip: Automating audit and reporting tasks ensures you always have the data you need for compliance and security investigations.

Microsoft Strategy and Future Outlook

AI-Driven Automation

Preparing for AI Workflows

You stand at the edge of a new era in enterprise automation. Microsoft is integrating AI-driven automation into its platforms, including graph and PowerShell, to help you work smarter. When you use these tools, you can automate onboarding, manage permissions, and remove stale accounts without manual effort. This approach improves security and supports Zero Trust principles. You also boost productivity by giving employees access to the right systems as soon as they join.

You can connect your HR management system to workflow tools like Power Automate. When employee data changes, automation triggers provisioning, license assignments, and access updates. You can also automate offboarding to keep your environment secure. PowerShell and graph let you handle IT operations, manage licenses, and generate reports with speed and accuracy. You reduce repetitive tasks and free up time for strategic projects.

Automate user onboarding and offboarding
Manage licenses, groups, and Teams
Generate reports and audits
Integrate APIs and automate workflows
Download and process files automatically

Evolving Capabilities

You will see more advanced features in the future. Microsoft is building new capabilities into graph to support your evolving needs. The table below highlights some features you can expect:

Feature	Description
Custom Connectors	Create connectors to different services for better integration.
Contextual Insights	Use data from emails, calendars, and Teams for smarter responses.
Copilot Ecosystem	Build custom AI solutions for your unique workflows.
Universal Interface	Integrate with any REST-compliant service for flexible automation.
Automation Triggers	Start workflows when files are uploaded or changed.
Integration with Power Automate	Orchestrate automation without writing code.

You can automate document library creation, manage site permissions, and even book resources through conversational interfaces. These features will help you keep up with the fast pace of digital transformation.

Enterprise Readiness

Skills and Training

You need the right skills to succeed with automation. Start by learning how to use PowerShell and the Microsoft Graph PowerShell SDK. Focus on writing reliable scripts with the v1.0 modules. This will help you avoid problems and ensure your automation works as expected. Practice bulk updates and quick reports to manage your environment at scale. You can also explore azure and devops tools to expand your automation skills.

Organizational Change

You must prepare your organization for change. Communicate with your team about the benefits of automation. Provide training and support as you roll out new workflows. Encourage feedback and adjust your processes as needed. When you manage change well, you help your organization become more agile and ready for the future.

Tip: Start small, test your automation, and scale up as your team gains confidence. This approach builds trust and ensures long-term success.

You can unlock a new era of Microsoft 365 administration by using Microsoft Graph and PowerShell. These tools give you unified access, automation, and security for your cloud, devops, and azure environments. To get started, follow these steps:

Define your automation goals and map your workflows.
Start small, focus on data quality, and scale up.
Use the Microsoft Maturity Model to assess your progress.

Explore resources like Graph Explorer, PowerShell scripts, and AI assistants to stay ahead as Microsoft continues to advance automation.

Level	Description
300	Defined: Standardize, gather feedback, and build resilience.
400	Capable: Optimize with technology and strategic benchmarking.
500	Efficient: Foster collaboration and address gaps for excellence.

FAQ

What is Microsoft Graph?

Microsoft Graph is a unified API endpoint. You use it to access data and services across Microsoft 365. It connects users, groups, devices, and applications in one place.

How does PowerShell work with Microsoft Graph?

You use PowerShell scripts to automate tasks with Microsoft Graph. The Microsoft Graph PowerShell SDK lets you manage users, groups, and resources quickly. You save time and reduce errors.

Why should you automate Microsoft 365 administration?

Automation helps you avoid manual mistakes. You enforce policies, manage users, and generate reports faster. You improve security and compliance. Your team spends less time on repetitive tasks.

Is Microsoft Graph secure?

Microsoft Graph uses modern authentication methods like OAuth and certificates. You control permissions and monitor access. Multi-factor authentication adds extra protection. You keep your environment safe.

Can you manage Teams and SharePoint with Microsoft Graph?

You automate Teams and SharePoint tasks using Microsoft Graph. You create channels, manage permissions, and update sites. You build workflows that connect collaboration tools.

What is idempotent automation?

Idempotent automation means your scripts run safely every time. You avoid duplicate actions or errors. You get reliable results and consistent workflows.

How do you start learning Microsoft Graph and PowerShell?

Step	Action
1	Explore Microsoft Graph Explorer
2	Practice PowerShell scripts
3	Review official documentation
4	Join Microsoft learning communities

🚀 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:02,760
You spend your day in the Microsoft 365 admin portal,

2
00:00:02,760 --> 00:00:06,780
clicking through dashboards, managing users, adjusting policies,

3
00:00:06,780 --> 00:00:09,400
and it feels like you are in control, but you are not.

4
00:00:09,400 --> 00:00:11,280
The portal is just a convenience layer.

5
00:00:11,280 --> 00:00:14,840
It was built for administrators who manage dozens of users, not thousands.

6
00:00:14,840 --> 00:00:19,240
It was designed so someone could configure one setting, one time, for one person.

7
00:00:19,240 --> 00:00:22,400
It is perfect for that, but in reality, it is a bottleneck

8
00:00:22,400 --> 00:00:24,280
masquerading as a control center.

9
00:00:24,280 --> 00:00:28,720
Most organizations operate at about 10% of their actual automation capacity.

10
00:00:28,720 --> 00:00:32,440
They have the capability to scale across thousands of users, devices,

11
00:00:32,440 --> 00:00:33,920
and workloads automatically.

12
00:00:33,920 --> 00:00:36,720
Instead, they are clicking, waiting, clicking again,

13
00:00:36,720 --> 00:00:39,680
and they are calling that administration, but here is the problem.

14
00:00:39,680 --> 00:00:43,400
Azure AD Graph is retiring June 30th, 2025.

15
00:00:43,400 --> 00:00:46,840
The Graph CLI is retiring August 28th, 2026.

16
00:00:46,840 --> 00:00:48,520
Microsoft is not giving you a choice.

17
00:00:48,520 --> 00:00:51,800
They are consolidating every control surface onto Microsoft Graph,

18
00:00:51,800 --> 00:00:55,000
and PowerShell is becoming the only viable interface at scale.

19
00:00:55,000 --> 00:00:57,040
This episode is not about learning in API.

20
00:00:57,040 --> 00:00:59,160
It is about understanding enterprise throughput.

21
00:00:59,160 --> 00:01:01,120
It is about seeing what the portal hides.

22
00:01:01,120 --> 00:01:04,760
By the time we are done, you will understand why the future of Microsoft 365

23
00:01:04,760 --> 00:01:09,040
administration belongs to those who think in systems, not clicks.

24
00:01:09,040 --> 00:01:10,280
The scaling floor.

25
00:01:10,280 --> 00:01:12,480
Why portals fail at enterprise scale?

26
00:01:12,480 --> 00:01:15,920
The portal was designed for individual configuration, create a user,

27
00:01:15,920 --> 00:01:18,000
assign a license, add them to a group,

28
00:01:18,000 --> 00:01:20,360
done one action at a time, one person at a time.

29
00:01:20,360 --> 00:01:23,880
That model works until it does not, the moment you need to do something at scale.

30
00:01:23,880 --> 00:01:27,000
Across hundreds or thousands of resources, the portal breaks.

31
00:01:27,000 --> 00:01:30,880
Not technically, it keeps working, but operationally it falls apart.

32
00:01:30,880 --> 00:01:33,680
Because in reality, manual clicks do not scale.

33
00:01:33,680 --> 00:01:38,080
They compound every decision you make in the portal cascades into operational debt you cannot see.

34
00:01:38,080 --> 00:01:40,280
A user added manually to the wrong group.

35
00:01:40,280 --> 00:01:43,280
A team site provisioned without proper retention settings.

36
00:01:43,280 --> 00:01:45,280
A permission granted that should have been restricted.

37
00:01:45,280 --> 00:01:46,800
These are not one-time fixes.

38
00:01:46,800 --> 00:01:48,280
They are problems that snowball.

39
00:01:48,280 --> 00:01:50,080
Let me show you what scale actually looks like.

40
00:01:50,080 --> 00:01:54,400
A global manufacturer needed to manage 20,000 tablets across factory floors.

41
00:01:54,400 --> 00:01:55,360
They had two parts.

42
00:01:55,360 --> 00:01:58,840
Path 1 was to provision each device manually through the Intune portal.

43
00:01:58,840 --> 00:02:01,400
That is 20,000 clicks, thousands of hours.

44
00:02:01,400 --> 00:02:02,400
Errors everywhere.

45
00:02:02,400 --> 00:02:06,320
Path 2 was to automate via graph APIs, zero touch enrollment,

46
00:02:06,320 --> 00:02:10,320
automatic policy assignment, configuration validation, the same outcome.

47
00:02:10,320 --> 00:02:12,960
20,000 fully provisioned compliant devices.

48
00:02:12,960 --> 00:02:15,720
But in a fraction of the time, with zero human error.

49
00:02:15,720 --> 00:02:19,760
But here is what matters more than the time, context.

50
00:02:19,760 --> 00:02:22,760
When you work through the portal, you see one user.

51
00:02:22,760 --> 00:02:24,360
One device, one setting at a time.

52
00:02:24,360 --> 00:02:25,840
You get no view of patterns.

53
00:02:25,840 --> 00:02:29,680
No visibility into what is misconfigured across the entire organization.

54
00:02:29,680 --> 00:02:31,080
You cannot answer questions like,

55
00:02:31,080 --> 00:02:33,840
"How many sites do we have that are oversharing content?"

56
00:02:33,840 --> 00:02:36,680
Or, "Which applications have excessive permissions?"

57
00:02:36,680 --> 00:02:38,800
Or, "What is our true license utilization?"

58
00:02:38,800 --> 00:02:40,280
The portal hides these questions.

59
00:02:40,280 --> 00:02:43,200
It forces you to manually audit, manually investigate,

60
00:02:43,200 --> 00:02:45,080
and manually check each resource.

61
00:02:45,080 --> 00:02:46,280
Permission audits?

62
00:02:46,280 --> 00:02:47,840
That should take two days.

63
00:02:47,840 --> 00:02:51,680
Take three weeks because you are clicking through the interface one item at a time.

64
00:02:51,680 --> 00:02:53,840
With graph, those same audits run in hours.

65
00:02:53,840 --> 00:02:55,520
Automated, continuous, visible.

66
00:02:55,520 --> 00:02:57,360
And then there is the skill gap.

67
00:02:57,360 --> 00:02:58,640
By 2027.

68
00:02:58,640 --> 00:02:59,840
And this is already happening.

69
00:02:59,840 --> 00:03:02,360
Portal only administrators will not be able to compete.

70
00:03:02,360 --> 00:03:03,840
They cannot architect solutions.

71
00:03:03,840 --> 00:03:04,640
They cannot scale.

72
00:03:04,640 --> 00:03:06,880
They cannot see the data their systems actually contain.

73
00:03:06,880 --> 00:03:09,280
They are operators of a GUI, not architects of systems.

74
00:03:09,280 --> 00:03:11,160
Organizations are already recognizing this.

75
00:03:11,160 --> 00:03:12,680
They are forming automation teams.

76
00:03:12,680 --> 00:03:15,400
They are treating graph and power shell as core competencies.

77
00:03:15,400 --> 00:03:18,120
The gap between portal clickers and graph thinking architects

78
00:03:18,120 --> 00:03:19,680
is widening every quarter.

79
00:03:19,680 --> 00:03:21,440
The real cost of the portal is not time.

80
00:03:21,440 --> 00:03:23,280
It is the decisions you cannot make.

81
00:03:23,280 --> 00:03:25,840
The risks you cannot see, the optimization you cannot do

82
00:03:25,840 --> 00:03:29,360
because you lack visibility into the actual state of your organization.

83
00:03:29,360 --> 00:03:31,480
Understanding this flow is the first step.

84
00:03:31,480 --> 00:03:33,720
Now let us talk about what actually works.

85
00:03:33,720 --> 00:03:36,320
What Microsoft Graph actually is beyond the definition.

86
00:03:36,320 --> 00:03:38,440
Stop thinking of Microsoft Graph as an API.

87
00:03:38,440 --> 00:03:42,480
That framing is technically accurate, but strategically useless.

88
00:03:42,480 --> 00:03:46,160
Calling graph an API is like calling the internet a bunch of cables.

89
00:03:46,160 --> 00:03:48,320
It's true, but it completely misses the point.

90
00:03:48,320 --> 00:03:51,320
Graph is the operating system for Microsoft 365.

91
00:03:51,320 --> 00:03:54,520
It is the single layer through which every user, file, meeting,

92
00:03:54,520 --> 00:03:57,120
and security alert in your organization is managed.

93
00:03:57,120 --> 00:04:00,240
It consolidates over 700 endpoints across identity,

94
00:04:00,240 --> 00:04:03,320
collaboration, and security into one consistent interface.

95
00:04:03,320 --> 00:04:05,320
One data model, one permission system, one place

96
00:04:05,320 --> 00:04:07,560
where your entire organizational graph lives.

97
00:04:07,560 --> 00:04:09,760
And here is the thing most admins don't realize.

98
00:04:09,760 --> 00:04:10,960
You are already using graph.

99
00:04:10,960 --> 00:04:13,440
Every time you open the Microsoft 365 Admin Center

100
00:04:13,440 --> 00:04:16,920
and click a button, the portal makes a graph call in the background.

101
00:04:16,920 --> 00:04:18,960
The Admin Center is just a wrapper around graph.

102
00:04:18,960 --> 00:04:21,320
The Intune portal is a wrapper around graph.

103
00:04:21,320 --> 00:04:23,920
Teams, Exchange, SharePoint.

104
00:04:23,920 --> 00:04:28,120
All of them are just user interfaces built on top of the same underlying system

105
00:04:28,120 --> 00:04:29,520
you could be calling directly.

106
00:04:29,520 --> 00:04:33,120
When you click a button to assign a license, graph executes that action.

107
00:04:33,120 --> 00:04:35,960
When you search for a user and their details appear on screen,

108
00:04:35,960 --> 00:04:37,400
graph fetches that data.

109
00:04:37,400 --> 00:04:38,680
You are already in the system.

110
00:04:38,680 --> 00:04:41,200
The portal is just putting a slower, less powerful interface

111
00:04:41,200 --> 00:04:42,600
between you and the actual work.

112
00:04:42,600 --> 00:04:44,200
The question isn't whether you use graph.

113
00:04:44,200 --> 00:04:45,360
You already do.

114
00:04:45,360 --> 00:04:47,640
The question is whether you use it intentionally

115
00:04:47,640 --> 00:04:52,240
at scale with full control or accidentally one click at a time

116
00:04:52,240 --> 00:04:54,840
through a GUI designed for single operations.

117
00:04:54,840 --> 00:04:57,320
Now you can interact with graph directly in two ways.

118
00:04:57,320 --> 00:04:59,440
Rest endpoints and the PowerShell SDK.

119
00:04:59,440 --> 00:05:00,520
They call the same service.

120
00:05:00,520 --> 00:05:01,840
They hit the same endpoints.

121
00:05:01,840 --> 00:05:04,120
They authenticate through the same identity model.

122
00:05:04,120 --> 00:05:07,760
The SDK just wraps those rest calls in PowerShell CMDlets

123
00:05:07,760 --> 00:05:10,560
so you don't have to build HTTP requests by hand.

124
00:05:10,560 --> 00:05:12,760
The SDK is faster for common operations,

125
00:05:12,760 --> 00:05:14,360
but raw rest gives you more control

126
00:05:14,360 --> 00:05:16,680
when the SDK hasn't caught up with a new feature.

127
00:05:16,680 --> 00:05:19,440
That leads to the beta versus V1.0 distinction.

128
00:05:19,440 --> 00:05:20,760
Graph runs two tracks.

129
00:05:20,760 --> 00:05:23,480
The V1.0 endpoint is stable and production ready.

130
00:05:23,480 --> 00:05:26,120
The beta endpoint is where new capabilities appear first.

131
00:05:26,120 --> 00:05:28,240
Often months before they reach V1.0,

132
00:05:28,240 --> 00:05:30,600
the Intune and Teams product groups build against beta

133
00:05:30,600 --> 00:05:33,200
because that is where the full feature set lives.

134
00:05:33,200 --> 00:05:35,360
Most serious automation work happens in beta.

135
00:05:35,360 --> 00:05:37,760
You just have to understand that beta endpoints can change

136
00:05:37,760 --> 00:05:38,760
without notice.

137
00:05:38,760 --> 00:05:41,440
Why is Microsoft forcing everything through graph?

138
00:05:41,440 --> 00:05:43,600
Because they are building their entire future on it,

139
00:05:43,600 --> 00:05:46,600
Copilot uses graph to retrieve your documents and emails.

140
00:05:46,600 --> 00:05:49,760
AI agents use graph to take actions in your tenant,

141
00:05:49,760 --> 00:05:51,720
the entire agent automation stack.

142
00:05:51,720 --> 00:05:54,680
Agent 365 Copilot Studio autonomous workflows.

143
00:05:54,680 --> 00:05:56,800
All of it runs on graph as the foundational layer.

144
00:05:56,800 --> 00:05:58,960
Every capability Microsoft ships going forward

145
00:05:58,960 --> 00:06:00,520
will land in graph first.

146
00:06:00,520 --> 00:06:02,920
Legacy APIs are being retired because they cannot support

147
00:06:02,920 --> 00:06:03,680
this future.

148
00:06:03,680 --> 00:06:06,160
EWS is going as your AD graph went.

149
00:06:06,160 --> 00:06:07,760
The MS-09 module is gone.

150
00:06:07,760 --> 00:06:09,160
The consolidation isn't optional.

151
00:06:09,160 --> 00:06:11,000
Graph is the only viable path forward.

152
00:06:11,000 --> 00:06:12,640
Now that you understand what graph is,

153
00:06:12,640 --> 00:06:15,680
we need to talk about the permission model that makes it work.

154
00:06:15,680 --> 00:06:19,240
Authentication, permissions, and the principle of least privilege.

155
00:06:19,240 --> 00:06:21,360
Every graph call starts with identity.

156
00:06:21,360 --> 00:06:23,840
Before graph reads a user or modifies a policy,

157
00:06:23,840 --> 00:06:26,760
it needs to know who is asking and what they are allowed to do.

158
00:06:26,760 --> 00:06:29,520
If you get this wrong, you either cannot automate anything.

159
00:06:29,520 --> 00:06:31,840
Or you create a security hole large enough to compromise

160
00:06:31,840 --> 00:06:32,960
the entire tenant.

161
00:06:32,960 --> 00:06:35,280
There are two permission models, delegated permissions

162
00:06:35,280 --> 00:06:36,520
and application permissions.

163
00:06:36,520 --> 00:06:37,440
They sound similar.

164
00:06:37,440 --> 00:06:38,880
They are fundamentally different.

165
00:06:38,880 --> 00:06:41,280
Delegated permissions mean the application acts on behalf

166
00:06:41,280 --> 00:06:42,680
of a signed-in user.

167
00:06:42,680 --> 00:06:44,200
The user logs in, consents to the app,

168
00:06:44,200 --> 00:06:46,320
and the app can do whatever that user is allowed to do.

169
00:06:46,320 --> 00:06:47,120
Nothing more.

170
00:06:47,120 --> 00:06:48,760
If the user cannot read a certain mailbox,

171
00:06:48,760 --> 00:06:49,520
neither can the app.

172
00:06:49,520 --> 00:06:51,440
The user's existing rights form a ceiling.

173
00:06:51,440 --> 00:06:53,760
This model makes sense for interactive tools.

174
00:06:53,760 --> 00:06:56,120
Something a help desk admin runs while authenticated

175
00:06:56,120 --> 00:06:57,240
as themselves.

176
00:06:57,240 --> 00:06:59,200
Application permissions work differently.

177
00:06:59,200 --> 00:07:00,480
There is no signed-in user.

178
00:07:00,480 --> 00:07:02,880
The application authenticates as a service principle.

179
00:07:02,880 --> 00:07:05,080
A non-human identity registered in EnterID,

180
00:07:05,080 --> 00:07:06,680
and it acts on its own authority.

181
00:07:06,680 --> 00:07:08,920
Application permissions are tenant-wide by default

182
00:07:08,920 --> 00:07:10,280
if you grant an app mail.

183
00:07:10,280 --> 00:07:11,560
Read as an application permission,

184
00:07:11,560 --> 00:07:13,880
it can read every mailbox in the organization.

185
00:07:13,880 --> 00:07:14,920
Every single one.

186
00:07:14,920 --> 00:07:17,320
Without any user context, limiting it.

187
00:07:17,320 --> 00:07:19,720
This is the model you use for background automation.

188
00:07:19,720 --> 00:07:21,440
Schedule jobs, runbooks, and anything

189
00:07:21,440 --> 00:07:23,160
that runs without a human present.

190
00:07:23,160 --> 00:07:25,760
That distinction matters because application permissions

191
00:07:25,760 --> 00:07:28,040
are where most organizations get into trouble.

192
00:07:28,040 --> 00:07:30,960
They grant broad scopes during initial setup, forget about them,

193
00:07:30,960 --> 00:07:33,320
and then wonder why a compromised service principle

194
00:07:33,320 --> 00:07:34,680
can access everything.

195
00:07:34,680 --> 00:07:36,280
The Microsoft Graph permissions reference

196
00:07:36,280 --> 00:07:39,280
is the document that maps every action to every required scope.

197
00:07:39,280 --> 00:07:40,760
Most admins have never opened it.

198
00:07:40,760 --> 00:07:41,920
That is a problem.

199
00:07:41,920 --> 00:07:43,920
The permissions reference isn't just documentation.

200
00:07:43,920 --> 00:07:45,600
It is your security architecture.

201
00:07:45,600 --> 00:07:48,360
It tells you exactly which scope grants, which access,

202
00:07:48,360 --> 00:07:50,520
and whether admin consent is required.

203
00:07:50,520 --> 00:07:53,320
Read it, book market, use it every time you build something new.

204
00:07:53,320 --> 00:07:54,800
Least privilege isn't optional.

205
00:07:54,800 --> 00:07:57,000
It is the structural difference between a secure tenant

206
00:07:57,000 --> 00:07:58,000
and a compromised one.

207
00:07:58,000 --> 00:08:01,080
A service principle with directory, read, write, all, and mail.

208
00:08:01,080 --> 00:08:03,480
Read, write is effectively a super admin robot

209
00:08:03,480 --> 00:08:05,080
if its credentials are stolen.

210
00:08:05,080 --> 00:08:07,840
Through a leaked client secret or a misconfigured pipeline,

211
00:08:07,840 --> 00:08:10,560
the attacker inherits everything that principal can do.

212
00:08:10,560 --> 00:08:12,680
And if you have been generous with permissions,

213
00:08:12,680 --> 00:08:13,480
that is everything.

214
00:08:13,480 --> 00:08:15,400
The environment is getting more restrictive.

215
00:08:15,400 --> 00:08:18,640
Starting in mid-2026, Microsoft is changing default consent

216
00:08:18,640 --> 00:08:21,120
behavior for exchange-related graph scopes.

217
00:08:21,120 --> 00:08:22,840
New apps requesting exchange permissions

218
00:08:22,840 --> 00:08:25,600
will require explicit admin consent by default.

219
00:08:25,600 --> 00:08:28,000
Apps that previously relied on user-self consent

220
00:08:28,000 --> 00:08:30,720
will start failing unless they have been explicitly approved.

221
00:08:30,720 --> 00:08:33,000
Organizations that haven't reviewed their app registrations

222
00:08:33,000 --> 00:08:35,080
will start seeing 4103 errors in production.

223
00:08:35,080 --> 00:08:36,080
So when do you audit?

224
00:08:36,080 --> 00:08:38,480
You should audit monthly for high-risk applications.

225
00:08:38,480 --> 00:08:40,760
Anything with directory-write access or mail access,

226
00:08:40,760 --> 00:08:42,880
you should audit quarterly for lower-privileged apps

227
00:08:42,880 --> 00:08:44,120
and routine reviews.

228
00:08:44,120 --> 00:08:46,680
And you must audit on an event-driven basis whenever

229
00:08:46,680 --> 00:08:48,160
a new app is registered.

230
00:08:48,160 --> 00:08:50,240
New app registrations and consent events

231
00:08:50,240 --> 00:08:51,880
should trigger an immediate review,

232
00:08:51,880 --> 00:08:53,840
not get buried in a quarterly batch.

233
00:08:53,840 --> 00:08:55,680
And here is the connection most organizations

234
00:08:55,680 --> 00:08:57,200
miss until it is too late.

235
00:08:57,200 --> 00:08:58,640
Copilot cannot be deployed safely

236
00:08:58,640 --> 00:09:00,520
until permission hygiene is restored.

237
00:09:00,520 --> 00:09:03,280
Copilot inherits the permissions of the signed-in user.

238
00:09:03,280 --> 00:09:06,040
If users have access to content, they should not see.

239
00:09:06,040 --> 00:09:08,960
Because permissions were granted broadly and never reviewed.

240
00:09:08,960 --> 00:09:11,040
Copilot will surface that content instantly.

241
00:09:11,040 --> 00:09:13,320
The permission debt you have been accumulating for years

242
00:09:13,320 --> 00:09:15,160
becomes an active AI exposure risk

243
00:09:15,160 --> 00:09:16,600
the moment you deploy copilot.

244
00:09:16,600 --> 00:09:17,720
That is not hypothetical.

245
00:09:17,720 --> 00:09:20,240
That is the reality organizations are discovering right now

246
00:09:20,240 --> 00:09:21,720
during readiness assessments.

247
00:09:21,720 --> 00:09:23,720
The permission model is where your security architecture

248
00:09:23,720 --> 00:09:25,480
either holds or breaks.

249
00:09:25,480 --> 00:09:27,120
Build it with least privilege from the start.

250
00:09:27,120 --> 00:09:28,480
Review it on a cadence.

251
00:09:28,480 --> 00:09:30,200
And treat every broad permission grant

252
00:09:30,200 --> 00:09:32,320
as a risk you have consciously accepted.

253
00:09:32,320 --> 00:09:34,160
Not a convenience you have forgotten about.

254
00:09:34,160 --> 00:09:36,280
With authentication and permissions understood,

255
00:09:36,280 --> 00:09:37,880
we can move to the real work.

256
00:09:37,880 --> 00:09:39,680
What you actually do with GraphEat.

257
00:09:39,680 --> 00:09:42,080
The user lifecycle from Joyner to Leaver.

258
00:09:42,080 --> 00:09:45,440
Identity lifecycle is where most organizations bleed time.

259
00:09:45,440 --> 00:09:46,880
They don't even know they're losing it.

260
00:09:46,880 --> 00:09:48,640
Someone gets hired, it gets a ticket,

261
00:09:48,640 --> 00:09:51,520
a human opens the admin center, they create the account,

262
00:09:51,520 --> 00:09:53,880
they assign a license, they add the person to groups,

263
00:09:53,880 --> 00:09:56,840
they set up the mailbox, they provision the team's workspace,

264
00:09:56,840 --> 00:09:58,120
they grant SharePoint access.

265
00:09:58,120 --> 00:10:00,000
If it goes smoothly, it takes 30 minutes.

266
00:10:00,000 --> 00:10:01,560
If it doesn't, it takes an hour.

267
00:10:01,560 --> 00:10:04,320
Now multiply that by 50 hrs a month or a hundred.

268
00:10:04,320 --> 00:10:05,840
You aren't running an IT team anymore.

269
00:10:05,840 --> 00:10:08,080
You're running a manual data entry operation.

270
00:10:08,080 --> 00:10:10,560
Graph PowerShell eliminates that entirely.

271
00:10:10,560 --> 00:10:12,720
A single script can create a user in EntraID

272
00:10:12,720 --> 00:10:14,000
and assign the right license based

273
00:10:14,000 --> 00:10:15,400
on their department in seconds.

274
00:10:15,400 --> 00:10:17,760
That same script adds them to security groups,

275
00:10:17,760 --> 00:10:19,720
provisions their team's workspace

276
00:10:19,720 --> 00:10:21,760
and configures their mailbox without a human

277
00:10:21,760 --> 00:10:23,160
ever clicking a button.

278
00:10:23,160 --> 00:10:24,240
One execution.

279
00:10:24,240 --> 00:10:26,560
Consistent output every time.

280
00:10:26,560 --> 00:10:28,400
The script that runs for hire number one

281
00:10:28,400 --> 00:10:30,880
runs exactly the same for hire number 10,000.

282
00:10:30,880 --> 00:10:32,400
But the script has to be built right

283
00:10:32,400 --> 00:10:33,960
and that means you need to understand

284
00:10:33,960 --> 00:10:36,680
the idempotent principle before you write a single line.

285
00:10:36,680 --> 00:10:39,800
idempotency means the script checks before it creates.

286
00:10:39,800 --> 00:10:41,120
Before it adds someone to a group,

287
00:10:41,120 --> 00:10:43,160
it verifies they aren't already a member.

288
00:10:43,160 --> 00:10:46,320
Before it assigns a license, it confirms one isn't already there.

289
00:10:46,320 --> 00:10:48,680
Before it creates a mailbox, it checks if one exists,

290
00:10:48,680 --> 00:10:50,080
the pattern is always the same.

291
00:10:50,080 --> 00:10:52,040
You use gitmjfirst to verify the state,

292
00:10:52,040 --> 00:10:53,880
then you use new mink or update mj

293
00:10:53,880 --> 00:10:55,800
only if the action is actually needed.

294
00:10:55,800 --> 00:10:56,640
Why does this matter?

295
00:10:56,640 --> 00:10:58,680
Because automation runs repeatedly,

296
00:10:58,680 --> 00:11:00,320
scheduled jobs fire nightly.

297
00:11:00,320 --> 00:11:03,280
Pipeline's trigger on events without idempotency.

298
00:11:03,280 --> 00:11:05,280
A script that runs twice creates two accounts,

299
00:11:05,280 --> 00:11:06,840
it assigns two licenses,

300
00:11:06,840 --> 00:11:09,360
it adds the user to the same group multiple times.

301
00:11:09,360 --> 00:11:12,000
What was meant to be automation becomes a cleanup project.

302
00:11:12,000 --> 00:11:14,960
idempotent scripts are safe to run as many times as you need.

303
00:11:14,960 --> 00:11:17,200
That's what makes scheduled automation viable.

304
00:11:17,200 --> 00:11:18,520
Then there's the move a scenario.

305
00:11:18,520 --> 00:11:20,680
Someone transfers between departments.

306
00:11:20,680 --> 00:11:22,200
Their access needs to change.

307
00:11:22,200 --> 00:11:24,400
Old groups get removed, new ones get added,

308
00:11:24,400 --> 00:11:26,720
the manager field needs an update in the directory.

309
00:11:26,720 --> 00:11:29,920
In the portal, someone has to do all of this manually.

310
00:11:29,920 --> 00:11:31,600
They have to hope they don't miss a step.

311
00:11:31,600 --> 00:11:33,400
They have to hope the ticket is accurate.

312
00:11:33,400 --> 00:11:36,400
With graph, you read the change from your HR system.

313
00:11:36,400 --> 00:11:38,360
You validate it against the current state.

314
00:11:38,360 --> 00:11:41,040
You execute the delta, only what change gets touched.

315
00:11:41,040 --> 00:11:42,720
Everything else stays exactly as it is.

316
00:11:42,720 --> 00:11:45,000
The lever scenario is where most organizations

317
00:11:45,000 --> 00:11:46,480
have their biggest exposure.

318
00:11:46,480 --> 00:11:48,520
Employee termination is not a suggestion.

319
00:11:48,520 --> 00:11:50,160
Access needs to be revoked immediately,

320
00:11:50,160 --> 00:11:51,400
not at the end of the day,

321
00:11:51,400 --> 00:11:53,760
not when id gets around to the ticket immediately.

322
00:11:53,760 --> 00:11:55,320
Graph automation closes that gap.

323
00:11:55,320 --> 00:11:57,440
A termination trigger from HR fires a runbook.

324
00:11:57,440 --> 00:11:58,880
It disables the account.

325
00:11:58,880 --> 00:12:02,080
It revokes active sessions using revoke sign in sessions.

326
00:12:02,080 --> 00:12:04,600
It strips licenses and preserves mailbox content

327
00:12:04,600 --> 00:12:05,680
under litigation hold.

328
00:12:05,680 --> 00:12:07,200
All of this happens before the person

329
00:12:07,200 --> 00:12:08,440
has even left the building.

330
00:12:08,440 --> 00:12:10,480
There is one technical detail you need to know.

331
00:12:10,480 --> 00:12:13,400
Teams creation is asynchronous when you call new MG team.

332
00:12:13,400 --> 00:12:15,840
Graph returns a 202 accepted response.

333
00:12:15,840 --> 00:12:17,480
It does not return a 200 OK.

334
00:12:17,480 --> 00:12:18,640
The team isn't ready yet.

335
00:12:18,640 --> 00:12:20,080
Your script has to capture the operation

336
00:12:20,080 --> 00:12:21,840
you are from that response.

337
00:12:21,840 --> 00:12:24,920
Then it has to pull the teams I think operation endpoint

338
00:12:24,920 --> 00:12:26,640
until the status says succeeded.

339
00:12:26,640 --> 00:12:28,680
If you skip this, you'll try to add members

340
00:12:28,680 --> 00:12:30,840
or channels to a team that doesn't exist yet,

341
00:12:30,840 --> 00:12:31,960
the script will fail.

342
00:12:31,960 --> 00:12:33,120
Handle it correctly.

343
00:12:33,120 --> 00:12:36,360
And your provisioning flow becomes fully automated and reliable.

344
00:12:36,360 --> 00:12:38,120
EntraID governance takes this further

345
00:12:38,120 --> 00:12:39,480
with life cycle workflows.

346
00:12:39,480 --> 00:12:42,400
These are pre-built templates that trigger on identity events.

347
00:12:42,400 --> 00:12:44,480
They use graph as their execution backbone.

348
00:12:44,480 --> 00:12:47,960
Joyner, mover, lever, pre-configured, auditable, consistent.

349
00:12:47,960 --> 00:12:50,200
User life cycle is foundational, but the real power

350
00:12:50,200 --> 00:12:53,320
emerges when you scale across the entire tenant.

351
00:12:53,320 --> 00:12:56,080
Teams, SharePoint, and OneDrive at scale.

352
00:12:56,080 --> 00:12:57,480
The collaboration layer.

353
00:12:57,480 --> 00:12:59,640
Teams and SharePoint aren't separate products

354
00:12:59,640 --> 00:13:01,080
that graph happens to touch.

355
00:13:01,080 --> 00:13:02,600
They are fully exposed through graph,

356
00:13:02,600 --> 00:13:04,080
just like users and licenses.

357
00:13:04,080 --> 00:13:06,960
Every site, every document library, every permission

358
00:13:06,960 --> 00:13:09,280
assignment, it's all reachable, it's all readable,

359
00:13:09,280 --> 00:13:11,280
it's all modifiable through the same API.

360
00:13:11,280 --> 00:13:13,560
That means the same automation discipline applies.

361
00:13:13,560 --> 00:13:15,080
And it means the same sprawl problems

362
00:13:15,080 --> 00:13:16,920
exist usually at a much larger scale.

363
00:13:16,920 --> 00:13:18,720
Here is what happens in most organizations

364
00:13:18,720 --> 00:13:19,960
without governance.

365
00:13:19,960 --> 00:13:21,600
A team is created for a project.

366
00:13:21,600 --> 00:13:22,600
The project ends.

367
00:13:22,600 --> 00:13:24,160
The team stays.

368
00:13:24,160 --> 00:13:26,720
Another site is provisioned for a department initiative.

369
00:13:26,720 --> 00:13:27,720
The initiative wraps up.

370
00:13:27,720 --> 00:13:28,720
The site stays.

371
00:13:28,720 --> 00:13:30,880
Multiply this across three years and 1,000 employees.

372
00:13:30,880 --> 00:13:33,040
Now you have thousands of abandoned team's workspaces.

373
00:13:33,040 --> 00:13:34,480
You have often SharePoint sites.

374
00:13:34,480 --> 00:13:36,200
You have OneDrive libraries full of content.

375
00:13:36,200 --> 00:13:37,240
Nobody is managing.

376
00:13:37,240 --> 00:13:39,840
Microsoft Research suggests automated site cleanup

377
00:13:39,840 --> 00:13:42,680
typically removes 20 to 30% of inactive sites

378
00:13:42,680 --> 00:13:43,880
in unmanaged tenants.

379
00:13:43,880 --> 00:13:45,280
That isn't a rounding error.

380
00:13:45,280 --> 00:13:47,520
That's a governance failure hiding in plain site.

381
00:13:47,520 --> 00:13:49,200
Graph lets you fix this systematically.

382
00:13:49,200 --> 00:13:50,920
You can query every site in the tenant.

383
00:13:50,920 --> 00:13:52,360
You can pull activity metrics.

384
00:13:52,360 --> 00:13:54,880
You can identify when each site was last used.

385
00:13:54,880 --> 00:13:57,120
You flag anything inactive beyond your threshold.

386
00:13:57,120 --> 00:13:58,840
Then you notify owners automatically.

387
00:13:58,840 --> 00:13:59,920
You wait for a response.

388
00:13:59,920 --> 00:14:02,320
You archive or delete based on policy.

389
00:14:02,320 --> 00:14:05,760
The entire lifecycle runs without a human ever touching the portal.

390
00:14:05,760 --> 00:14:08,720
Site provisioning automation solves the other side of the problem.

391
00:14:08,720 --> 00:14:11,600
Instead of letting anyone create a team's workspace with any name,

392
00:14:11,600 --> 00:14:12,760
you root it through a script.

393
00:14:12,760 --> 00:14:14,520
Naming conventions are enforced.

394
00:14:14,520 --> 00:14:16,800
Retention policies are applied at creation.

395
00:14:16,800 --> 00:14:19,600
Sensitivity labels are assigned based on the department.

396
00:14:19,600 --> 00:14:22,960
External sharing is either enabled or blocked based on the classification.

397
00:14:22,960 --> 00:14:26,400
Every site that gets created is compliant from the first second it exists.

398
00:14:26,400 --> 00:14:29,640
Now, SharePoints structure is something most admins underestimate.

399
00:14:29,640 --> 00:14:31,600
Everything in SharePoint is ID based.

400
00:14:31,600 --> 00:14:32,560
It isn't name based.

401
00:14:32,560 --> 00:14:33,640
It isn't path based.

402
00:14:33,640 --> 00:14:34,800
It is ID based.

403
00:14:34,800 --> 00:14:37,680
If you want to interact with a document library, you need the site ID.

404
00:14:37,680 --> 00:14:39,040
Then you need the drive ID.

405
00:14:39,040 --> 00:14:41,560
Then you need item IDs for folders and files.

406
00:14:41,560 --> 00:14:44,720
The display names you see in the browser don't exist at the API layer.

407
00:14:44,720 --> 00:14:47,360
Those are just labels over a hierarchy of guide ease.

408
00:14:47,360 --> 00:14:51,040
This trips up administrators who try to write automation using folder paths.

409
00:14:51,040 --> 00:14:53,200
When the path changes, the script breaks.

410
00:14:53,200 --> 00:14:55,440
When you use IDs, the script is stable.

411
00:14:55,440 --> 00:14:58,960
It doesn't matter if the site gets renamed or reorganized.

412
00:14:58,960 --> 00:15:01,640
The good news is that Graph makes ID discovery straightforward.

413
00:15:01,640 --> 00:15:04,720
You query a site by the URL fragment to get its site ID.

414
00:15:04,720 --> 00:15:06,560
Then you traverse the drives and items from there.

415
00:15:06,560 --> 00:15:09,840
Once you have that ID hierarchy, automation is reliable and fast.

416
00:15:09,840 --> 00:15:12,240
External sharing audits deserve their own focus.

417
00:15:12,240 --> 00:15:14,600
The portal shows you sharing settings in aggregate.

418
00:15:14,600 --> 00:15:15,920
Graph shows you the actual links.

419
00:15:15,920 --> 00:15:18,360
It shows you which documents have public links.

420
00:15:18,360 --> 00:15:21,480
It shows you which sites have anonymous access enabled.

421
00:15:21,480 --> 00:15:24,480
It shows you which users have granted access to external parties

422
00:15:24,480 --> 00:15:26,120
that the organization didn't intend.

423
00:15:26,120 --> 00:15:27,120
This data is there.

424
00:15:27,120 --> 00:15:30,120
The portal just doesn't surface it in a way you can use it scale.

425
00:15:30,120 --> 00:15:31,440
A graph query across the tenant

426
00:15:31,440 --> 00:15:34,720
exposes every external sharing configuration in a single export.

427
00:15:34,720 --> 00:15:38,520
It turns a review that would take weeks of manual checking into a single task.

428
00:15:38,520 --> 00:15:41,680
There is one critical constraint if you're building co-pilot connectors.

429
00:15:41,680 --> 00:15:43,680
It's the 500kb response limit.

430
00:15:43,680 --> 00:15:48,280
Co-pilot studio connectors will fail if a single graph response exceeds about 500kb.

431
00:15:48,280 --> 00:15:49,760
This isn't negotiable.

432
00:15:49,760 --> 00:15:53,720
If you're pulling file metadata or document lists and your result set is large,

433
00:15:53,720 --> 00:15:56,160
you need pagination, you need server-side filtering,

434
00:15:56,160 --> 00:15:57,760
you need selective field retrieval,

435
00:15:57,760 --> 00:16:00,600
you select to return only the properties you actually need,

436
00:16:00,600 --> 00:16:03,520
use filter to narrow the result set before it reaches you.

437
00:16:03,520 --> 00:16:04,840
For anything high volume,

438
00:16:04,840 --> 00:16:07,680
consider a middleware layer that aggregates and compresses the data

439
00:16:07,680 --> 00:16:09,320
before handing it to co-pilot.

440
00:16:09,320 --> 00:16:12,960
Sensitivity labels and DLP policies are also enforced through graph.

441
00:16:12,960 --> 00:16:14,080
They aren't just visible.

442
00:16:14,080 --> 00:16:15,720
You aren't just reading configurations.

443
00:16:15,720 --> 00:16:16,520
You can apply them.

444
00:16:16,520 --> 00:16:17,800
You can modify them.

445
00:16:17,800 --> 00:16:20,720
You can verify coverage across the tenant programmatically.

446
00:16:20,720 --> 00:16:24,680
That is the difference between governance as a report and governance as an enforcement mechanism.

447
00:16:24,680 --> 00:16:27,520
Collaboration is where most of the organizational data lives.

448
00:16:27,520 --> 00:16:30,560
Now let's talk about the security layer that protects it.

449
00:16:30,560 --> 00:16:31,960
The security imperative.

450
00:16:31,960 --> 00:16:33,920
Graph as your threat detection layer.

451
00:16:33,920 --> 00:16:35,720
Security teams have a visibility problem.

452
00:16:35,720 --> 00:16:38,280
They're watching firewalls, monitoring endpoint alerts,

453
00:16:38,280 --> 00:16:39,760
reviewing defender dashboards,

454
00:16:39,760 --> 00:16:45,240
and they're completely missing what's happening at the application layer inside their Microsoft 365 tenant.

455
00:16:45,240 --> 00:16:47,800
Service principles authenticating at three in the morning.

456
00:16:47,800 --> 00:16:51,200
Apps with mail read permissions querying hundreds of mailboxes.

457
00:16:51,200 --> 00:16:54,440
Configuration change is happening through automation that nobody documented.

458
00:16:54,440 --> 00:16:56,600
All of it is invisible unless you know where to look.

459
00:16:56,600 --> 00:16:57,720
Graph is where you look.

460
00:16:57,720 --> 00:17:02,120
The Microsoft Graph Security API consolidates alerts from defender for endpoint,

461
00:17:02,120 --> 00:17:03,080
defender for cloud apps,

462
00:17:03,080 --> 00:17:06,000
and defender for identity into a single normalized endpoint.

463
00:17:06,000 --> 00:17:08,960
It pulls in signals from Sentinel and third party providers too.

464
00:17:08,960 --> 00:17:11,760
One query, unified alert schema.

465
00:17:11,760 --> 00:17:15,240
Every security signal your tenant generates is accessible programmatically.

466
00:17:15,240 --> 00:17:18,720
You don't have to jump between five separate dashboards that don't talk to each other.

467
00:17:18,720 --> 00:17:22,720
Security teams running graph driven playbooks can correlate a risky sign in alert

468
00:17:22,720 --> 00:17:24,760
with the app permissions that principal holds,

469
00:17:24,760 --> 00:17:26,520
the resources it recently accessed,

470
00:17:26,520 --> 00:17:29,400
and the conditional access policies that should have blocked it.

471
00:17:29,400 --> 00:17:31,720
This happens in a single automated investigation,

472
00:17:31,720 --> 00:17:33,400
not a manual cross tool chase.

473
00:17:33,400 --> 00:17:36,760
Service principle activity logging is where the real hidden risk lives.

474
00:17:36,760 --> 00:17:39,320
Most organizations have dozens, sometimes hundreds,

475
00:17:39,320 --> 00:17:41,720
of registered applications in their enter ID tenant.

476
00:17:41,720 --> 00:17:43,720
Some were created by developers years ago.

477
00:17:43,720 --> 00:17:48,040
Others came in with third party integrations and many have owners who have since left the organization.

478
00:17:48,040 --> 00:17:50,720
Every one of these principles authenticates against graph.

479
00:17:50,720 --> 00:17:51,840
They query data.

480
00:17:51,840 --> 00:17:53,080
They take actions.

481
00:17:53,080 --> 00:17:56,200
And most security teams have no visibility into what they're actually doing.

482
00:17:56,200 --> 00:17:57,800
Graph activity logs change that.

483
00:17:57,800 --> 00:18:00,800
They reached general availability in April of 2024

484
00:18:00,800 --> 00:18:03,160
and they provide something Azure AD graph never could.

485
00:18:03,160 --> 00:18:08,000
They give you HTTP level visibility into what applications are doing inside the tenant.

486
00:18:08,000 --> 00:18:09,880
You see which endpoints they're calling.

487
00:18:09,880 --> 00:18:12,040
You see how often you see what data they're reading.

488
00:18:12,040 --> 00:18:17,120
If a service principle suddenly starts querying the user's endpoint for every account in the directory,

489
00:18:17,120 --> 00:18:17,840
that shows up.

490
00:18:17,840 --> 00:18:21,000
If an app that normally reads calendar data starts accessing mail,

491
00:18:21,000 --> 00:18:22,640
that pattern is visible.

492
00:18:22,640 --> 00:18:25,840
This is the kind of behavioral baseline that makes anomaly detection possible.

493
00:18:25,840 --> 00:18:29,240
Because without it, you're flying blind on application activity.

494
00:18:29,240 --> 00:18:33,360
Conditional access deserves more attention than it typically gets in automation discussions.

495
00:18:33,360 --> 00:18:35,480
These policies aren't just security configurations.

496
00:18:35,480 --> 00:18:39,360
They are the enforcement layer that determines whether an authentication succeeds or fails.

497
00:18:39,360 --> 00:18:42,920
Understanding that means understanding the actual security posture of the tenant.

498
00:18:42,920 --> 00:18:44,440
Not just the stated policy.

499
00:18:44,440 --> 00:18:47,000
Graph exposes every conditional access policy,

500
00:18:47,000 --> 00:18:50,840
every name location, every compliance requirement, and every exclusion.

501
00:18:50,840 --> 00:18:55,520
A systematic review via graph often surfaces configurations that haven't been touched in years.

502
00:18:55,520 --> 00:18:58,720
You find exclusions granted for a pilot that never got cleaned up.

503
00:18:58,720 --> 00:19:01,960
Legacy authentication still permitted for an app that supports modern auth.

504
00:19:01,960 --> 00:19:05,040
Compliant device requirements not applied to privileged accounts.

505
00:19:05,040 --> 00:19:09,120
MFA coverage audits and risky sign-in detection are also graph driven operations.

506
00:19:09,120 --> 00:19:12,400
You can query authentication methods across every user in the tenant

507
00:19:12,400 --> 00:19:16,120
to identify who has MFA registered and what methods they're using.

508
00:19:16,120 --> 00:19:19,680
This allows you to flag accounts with no strong authentication at all.

509
00:19:19,680 --> 00:19:23,400
When you cross reference that against risky sign-in data from identity protection,

510
00:19:23,400 --> 00:19:25,280
you have a prioritized remediation list.

511
00:19:25,280 --> 00:19:28,440
It's an actual data set, not a gut feeling about where the exposure is.

512
00:19:28,440 --> 00:19:30,560
But here's the thing about the attack as perspective.

513
00:19:30,560 --> 00:19:34,640
Adversaries actively prefer deprecated APIs because they lack modern logging.

514
00:19:34,640 --> 00:19:39,960
Before its retirement, Azure AD graph generated sign-in events but not API level activity records.

515
00:19:39,960 --> 00:19:43,240
Security teams could see that a token was issued for Azure AD graph,

516
00:19:43,240 --> 00:19:45,880
but they couldn't see what operations were performed with it.

517
00:19:45,880 --> 00:19:47,600
Microsoft has been explicit about this.

518
00:19:47,600 --> 00:19:51,360
They expected attackers to keep using Azure AD graph with compromised credentials

519
00:19:51,360 --> 00:19:53,720
precisely because the activity was hard to detect.

520
00:19:53,720 --> 00:19:56,040
Moving to graph isn't just a technical migration.

521
00:19:56,040 --> 00:20:00,840
It improves your detection posture because you gain logs that simply didn't exist before.

522
00:20:00,840 --> 00:20:05,160
Monthly permission reviews for high-risk applications aren't a best practice recommendation.

523
00:20:05,160 --> 00:20:06,960
They are a non-negotiable control.

524
00:20:06,960 --> 00:20:11,080
An over-privileged app with a leaked credential is an attacker with tenant-wide access.

525
00:20:11,080 --> 00:20:13,200
Review cadence is your last structural defense.

526
00:20:13,200 --> 00:20:16,640
Security is foundational, but it's not the only reason to master graph.

527
00:20:16,640 --> 00:20:18,840
Governance, compliance, and the audit trail.

528
00:20:18,840 --> 00:20:20,480
Governance has a reputation problem.

529
00:20:20,480 --> 00:20:22,560
Most organizations treated as a restriction layer.

530
00:20:22,560 --> 00:20:27,000
They see it as a set of policies designed to slow people down and generate compliance paperwork.

531
00:20:27,000 --> 00:20:28,760
That framing is exactly backwards.

532
00:20:28,760 --> 00:20:30,400
Governance isn't about restrictions.

533
00:20:30,400 --> 00:20:32,960
It's about visibility and consistent enforcement.

534
00:20:32,960 --> 00:20:36,240
It's the difference between knowing the state of your tenant and hoping it's fine.

535
00:20:36,240 --> 00:20:40,480
The organizations that get governance right aren't the ones with the longest policy documents.

536
00:20:40,480 --> 00:20:43,160
They are the ones where the policies are actually enforced.

537
00:20:43,160 --> 00:20:44,880
Automatically, continuously.

538
00:20:44,880 --> 00:20:48,440
And with an audit trail that proves it, sensitivity labels and retention policies

539
00:20:48,440 --> 00:20:50,200
are where that enforcement starts.

540
00:20:50,200 --> 00:20:53,240
A sensitivity label isn't just a color coded badge on a document.

541
00:20:53,240 --> 00:20:54,520
It's a control mechanism.

542
00:20:54,520 --> 00:20:58,840
Label a file as confidential and graph enforces that classification downstream.

543
00:20:58,840 --> 00:21:01,760
DLP policies restrict where that content can be shared,

544
00:21:01,760 --> 00:21:05,400
while retention policies determine how long it stays and when it gets deleted.

545
00:21:05,400 --> 00:21:07,040
If legal proceedings require it,

546
00:21:07,040 --> 00:21:09,320
eDiscovery holds will override that deletion.

547
00:21:09,320 --> 00:21:11,040
All of these controls are connected.

548
00:21:11,040 --> 00:21:14,000
All of them are configurable and auditable through graph.

549
00:21:14,000 --> 00:21:15,320
Without that programmatic layer,

550
00:21:15,320 --> 00:21:18,200
you're applying policies manually and inconsistently.

551
00:21:18,200 --> 00:21:22,600
You have no reliable way to verify coverage across thousands of documents and sites.

552
00:21:22,600 --> 00:21:25,720
EDiscovery is where governance failures become expensive.

553
00:21:25,720 --> 00:21:27,760
A legal hold placed on the wrong mailbox.

554
00:21:27,760 --> 00:21:31,240
A retention policy that expired before an investigation began.

555
00:21:31,240 --> 00:21:34,640
Content deleted because lifecycle management wasn't configured correctly.

556
00:21:34,640 --> 00:21:36,000
These aren't hypothetical failures.

557
00:21:36,000 --> 00:21:39,920
They are the kind of events that result in sanctions and misdiscovery obligations.

558
00:21:39,920 --> 00:21:42,960
They lead to settlements that dwarf any IT budget.

559
00:21:42,960 --> 00:21:48,160
Graph integration with Microsoft Perview means you can verify legal hold coverage programmatically.

560
00:21:48,160 --> 00:21:51,320
You can confirm retention policy application across workloads

561
00:21:51,320 --> 00:21:54,360
and generate evidence that your information architecture is defensible.

562
00:21:54,360 --> 00:21:55,840
That's not a compliance checkbox.

563
00:21:55,840 --> 00:21:57,040
That's litigation readiness.

564
00:21:58,000 --> 00:22:01,680
Audit preparation is where graphs ROI becomes financially concrete.

565
00:22:01,680 --> 00:22:03,560
Manual audit prepped typically takes weeks.

566
00:22:03,560 --> 00:22:06,240
You have to pull access logs, document permission states,

567
00:22:06,240 --> 00:22:08,960
and export configuration records across different workloads.

568
00:22:08,960 --> 00:22:11,560
Teams are assigned to gather evidence and cross-reference records

569
00:22:11,560 --> 00:22:13,920
to produce reports that are already partially out of date

570
00:22:13,920 --> 00:22:15,560
by the time the auditor arrives.

571
00:22:15,560 --> 00:22:18,280
Graph automation compresses that timeline significantly.

572
00:22:18,280 --> 00:22:20,440
The same data collection that takes a team three weeks

573
00:22:20,440 --> 00:22:23,200
manually runs in hours via scripted queries.

574
00:22:23,200 --> 00:22:24,360
The evidence is current.

575
00:22:24,360 --> 00:22:28,760
The reports are generated programmatically and the audit package exists as a repeatable artifact.

576
00:22:28,760 --> 00:22:30,120
Not a one-time scramble.

577
00:22:30,120 --> 00:22:32,520
Perview integration extends this further.

578
00:22:32,520 --> 00:22:35,600
Graph exposes compliance policies, communication configurations,

579
00:22:35,600 --> 00:22:38,040
insider risk signals, and data lifecycle policies

580
00:22:38,040 --> 00:22:40,360
through the same consistent API surface.

581
00:22:40,360 --> 00:22:43,520
You aren't managing compliance across five separate admin portals.

582
00:22:43,520 --> 00:22:45,120
You're managing it through one data model

583
00:22:45,120 --> 00:22:48,080
with consistent authentication and consistent programmatic control,

584
00:22:48,080 --> 00:22:51,160
data residency, and cross-border transfer controls matter more

585
00:22:51,160 --> 00:22:52,760
than most organizations realize,

586
00:22:52,760 --> 00:22:55,320
until they're in the middle of a regulatory inquiry,

587
00:22:55,320 --> 00:22:56,960
where data is stored, how it moves,

588
00:22:56,960 --> 00:22:58,400
and what controls govern that movement

589
00:22:58,400 --> 00:23:00,680
or all graph accessible configurations.

590
00:23:00,680 --> 00:23:03,200
For multinational organizations operating under GDPR

591
00:23:03,200 --> 00:23:05,240
or contractual data residency requirements,

592
00:23:05,240 --> 00:23:06,760
programmatic verification is essential.

593
00:23:06,760 --> 00:23:10,200
It is the difference between demonstrable compliance and assumed compliance.

594
00:23:10,200 --> 00:23:12,680
Continuous access evaluation adds a real-time dimension

595
00:23:12,680 --> 00:23:14,600
that audit trails alone can't provide,

596
00:23:14,600 --> 00:23:16,400
when a user's risk level changes,

597
00:23:16,400 --> 00:23:19,200
like a password reset or a location anomaly.

598
00:23:19,200 --> 00:23:22,280
CIE allows graph to revoke active tokens immediately.

599
00:23:22,280 --> 00:23:24,200
You don't have to wait for the next natural expiry.

600
00:23:24,200 --> 00:23:26,920
Access doesn't just get logged as inappropriate after the fact.

601
00:23:26,920 --> 00:23:29,240
It gets terminated in the moment the risk is detected.

602
00:23:29,240 --> 00:23:31,240
Governance creates the foundation.

603
00:23:31,240 --> 00:23:32,880
Now let's talk about the operational insights

604
00:23:32,880 --> 00:23:34,640
that drive business decisions.

605
00:23:34,640 --> 00:23:37,040
Reporting analytics and the ROI dashboard,

606
00:23:37,040 --> 00:23:40,400
most organizations measure their Microsoft 365 environment

607
00:23:40,400 --> 00:23:43,600
the same way they manage it, manually, inconsistently,

608
00:23:43,600 --> 00:23:46,440
and only when a leader asks a question that needs an answer.

609
00:23:46,440 --> 00:23:48,720
A director wants to know how many active teams exist,

610
00:23:48,720 --> 00:23:51,040
an auditor needs license numbers, a CFO asks

611
00:23:51,040 --> 00:23:53,320
if the E5 investment is actually paying off.

612
00:23:53,320 --> 00:23:55,840
What happens next isn't a process, it's a scramble.

613
00:23:55,840 --> 00:24:00,000
Someone opens a portal, clicks around, exports a spreadsheet,

614
00:24:00,000 --> 00:24:02,000
and sends over a number that was already wrong

615
00:24:02,000 --> 00:24:03,400
before it even hit the inbox.

616
00:24:03,400 --> 00:24:06,000
That isn't reporting, that's archaeology.

617
00:24:06,000 --> 00:24:08,320
Graph-powered reporting changes the model.

618
00:24:08,320 --> 00:24:09,880
Instead of reactive data pools,

619
00:24:09,880 --> 00:24:11,960
you build a continuous measurement infrastructure

620
00:24:11,960 --> 00:24:14,000
where scheduled queries run automatically

621
00:24:14,000 --> 00:24:17,880
and data flows into dashboards that refresh without you touching them.

622
00:24:17,880 --> 00:24:20,880
The state of your tenant isn't something you reconstruct on demand,

623
00:24:20,880 --> 00:24:22,400
it's something you observe in real time.

624
00:24:22,400 --> 00:24:25,000
License utilization is where this pays off the fastest

625
00:24:25,000 --> 00:24:27,560
because graph exposes assigned licenses,

626
00:24:27,560 --> 00:24:29,400
active service plans and usage signals

627
00:24:29,400 --> 00:24:31,320
across every single workload.

628
00:24:31,320 --> 00:24:33,120
When you cross reference assigned licenses

629
00:24:33,120 --> 00:24:36,560
against actual product activity, a familiar pattern emerges.

630
00:24:36,560 --> 00:24:40,480
Somewhere between five and 15% of licenses in a typical tenant

631
00:24:40,480 --> 00:24:43,240
are assigned to accounts that show no meaningful usage at all.

632
00:24:43,240 --> 00:24:44,120
Share the accounts.

633
00:24:44,120 --> 00:24:46,080
Service accounts assigned E5 licenses

634
00:24:46,080 --> 00:24:47,600
for reasons nobody remembers.

635
00:24:47,600 --> 00:24:50,080
Former employees whose accounts were disabled

636
00:24:50,080 --> 00:24:51,760
but never actually deprovisioned.

637
00:24:51,760 --> 00:24:54,200
Each one represents a cost with zero value.

638
00:24:54,200 --> 00:24:56,960
Automated graph reporting surfaces this continuously,

639
00:24:56,960 --> 00:24:58,320
not as a one-time project,

640
00:24:58,320 --> 00:25:00,200
but as an ongoing operational signal.

641
00:25:00,200 --> 00:25:02,200
Adoption metrics add the strategic layer.

642
00:25:02,200 --> 00:25:05,000
License utilization tells you if a seat is occupied,

643
00:25:05,000 --> 00:25:08,040
but adoption metrics tell you if that seat is actually productive.

644
00:25:08,040 --> 00:25:10,160
You can see which workloads people are using

645
00:25:10,160 --> 00:25:12,880
and which teams have stopped using teams to revert back to email.

646
00:25:12,880 --> 00:25:14,440
You can identify SharePoint sites

647
00:25:14,440 --> 00:25:16,960
that see active collaboration versus the ones

648
00:25:16,960 --> 00:25:19,520
that exist only as document graveyards.

649
00:25:19,520 --> 00:25:22,480
The usage reports API provides this data across exchange,

650
00:25:22,480 --> 00:25:25,640
teams SharePoint, OneDrive and Viva workloads.

651
00:25:25,640 --> 00:25:29,160
Feeding that data into Power BI gives you executive grade visibility.

652
00:25:29,160 --> 00:25:31,760
You can finally see if your Microsoft 365 investment

653
00:25:31,760 --> 00:25:33,640
is changing how the organization works

654
00:25:33,640 --> 00:25:35,480
or if it's just generating invoices.

655
00:25:35,480 --> 00:25:38,680
The distinction between operational and strategic metrics matters here.

656
00:25:38,680 --> 00:25:41,880
Operational metrics like tickets resolved or provisioning time

657
00:25:41,880 --> 00:25:45,160
tell you how efficiently the IT team is running, strategic metrics

658
00:25:45,160 --> 00:25:47,240
like license ROI and governance coverage.

659
00:25:47,240 --> 00:25:50,120
Tell you what value the business is extracting from the technology,

660
00:25:50,120 --> 00:25:51,120
both matter.

661
00:25:51,120 --> 00:25:53,320
But most reporting stops at the operational level

662
00:25:53,320 --> 00:25:55,520
because that's what IT teams know how to measure.

663
00:25:55,520 --> 00:25:57,920
The strategic layer requires graph-powered reporting

664
00:25:57,920 --> 00:26:00,400
that the standard portal was never designed to provide.

665
00:26:00,400 --> 00:26:02,760
Baseline measurement is the prerequisite for all of it.

666
00:26:02,760 --> 00:26:05,840
You can't demonstrate improvement if you don't know where you started.

667
00:26:05,840 --> 00:26:07,520
Before you deploy a new automation,

668
00:26:07,520 --> 00:26:09,600
you have to measure the current state,

669
00:26:09,600 --> 00:26:12,440
the time per task, the error rate and the license waste.

670
00:26:12,440 --> 00:26:14,880
After you deploy, you measure those same things again

671
00:26:14,880 --> 00:26:16,360
that delta is your ROI case.

672
00:26:16,360 --> 00:26:18,040
Without the baseline, you just have a story.

673
00:26:18,040 --> 00:26:19,400
But with it, you have evidence.

674
00:26:19,400 --> 00:26:21,640
Quarterly business reviews driven by graph data

675
00:26:21,640 --> 00:26:23,600
do more than just justify a budget.

676
00:26:23,600 --> 00:26:24,960
They shift the conversation.

677
00:26:24,960 --> 00:26:26,960
Instead of reporting what IT did,

678
00:26:26,960 --> 00:26:28,880
you're reporting what the organization accomplished

679
00:26:28,880 --> 00:26:30,360
and where the risks still live.

680
00:26:30,360 --> 00:26:31,720
That's a different kind of meeting.

681
00:26:31,720 --> 00:26:34,440
It's the meeting where IT leaders become strategic partners

682
00:26:34,440 --> 00:26:36,000
instead of ticket processes.

683
00:26:36,000 --> 00:26:38,040
Reporting shows you what's happening.

684
00:26:38,040 --> 00:26:40,240
Now, we need to talk about the automation patterns

685
00:26:40,240 --> 00:26:42,280
that actually make change happen.

686
00:26:42,280 --> 00:26:44,640
Polling versus delta queries versus webhooks,

687
00:26:44,640 --> 00:26:45,920
the performance frontier.

688
00:26:45,920 --> 00:26:48,840
Most automation breaks down, not because the logic is wrong,

689
00:26:48,840 --> 00:26:51,040
but because the data retrieval pattern is wrong.

690
00:26:51,040 --> 00:26:53,000
You can write a technically correct script

691
00:26:53,000 --> 00:26:54,920
that destroys tenant performance at scale

692
00:26:54,920 --> 00:26:57,440
just by choosing the wrong synchronization model.

693
00:26:57,440 --> 00:26:59,160
This is the gap between automation

694
00:26:59,160 --> 00:27:00,920
that works in a test environment

695
00:27:00,920 --> 00:27:03,160
and automation that survives a production tenant

696
00:27:03,160 --> 00:27:04,560
with 50,000 users.

697
00:27:04,560 --> 00:27:05,520
Start with polling.

698
00:27:05,520 --> 00:27:07,360
Because that's what most people build first.

699
00:27:07,360 --> 00:27:10,480
Polling means your script checks an endpoint on a schedule.

700
00:27:10,480 --> 00:27:13,520
Every hour the script wakes up, calls the graph endpoint,

701
00:27:13,520 --> 00:27:16,920
retrieves the full result set, and compares it against the old state.

702
00:27:16,920 --> 00:27:18,120
It's simple to understand.

703
00:27:18,120 --> 00:27:19,160
It's simple to implement.

704
00:27:19,160 --> 00:27:20,960
And it's completely wrong at scale.

705
00:27:20,960 --> 00:27:22,840
But here's the problem when nothing has changed,

706
00:27:22,840 --> 00:27:23,840
polling still runs.

707
00:27:23,840 --> 00:27:25,440
It still consumes your request quota

708
00:27:25,440 --> 00:27:28,200
and generates API traffic against the same endpoints.

709
00:27:28,200 --> 00:27:30,400
In a large tenant, polling scales linearly

710
00:27:30,400 --> 00:27:32,360
with the size of the organization.

711
00:27:32,360 --> 00:27:34,080
The more users and devices you have,

712
00:27:34,080 --> 00:27:36,080
the heavier every single poll becomes.

713
00:27:36,080 --> 00:27:38,120
Because polling generates constant traffic

714
00:27:38,120 --> 00:27:39,640
regardless of actual change,

715
00:27:39,640 --> 00:27:42,160
it's one of the primary triggers for graph throttling.

716
00:27:42,160 --> 00:27:44,120
Microsoft is very direct on this point.

717
00:27:44,120 --> 00:27:46,320
Continuous polling and repeated full scans

718
00:27:46,320 --> 00:27:47,800
are more likely to cause throttling

719
00:27:47,800 --> 00:27:49,240
than any other access pattern.

720
00:27:49,240 --> 00:27:51,280
That 429 response your automation is hitting,

721
00:27:51,280 --> 00:27:52,640
polling is probably the reason.

722
00:27:52,640 --> 00:27:54,600
Delta queries solve this inefficiency.

723
00:27:54,600 --> 00:27:56,760
Instead of retrieving everything every time,

724
00:27:56,760 --> 00:27:59,800
a Delta query returns only what changed since the last sync.

725
00:27:59,800 --> 00:28:01,200
The first call establishes a baseline

726
00:28:01,200 --> 00:28:02,520
and returns a Delta token.

727
00:28:02,520 --> 00:28:04,120
Every call after that uses the token

728
00:28:04,120 --> 00:28:07,200
to get back only the additions, modifications, and deletions.

729
00:28:07,200 --> 00:28:10,240
A tenant where three users change departments overnight

730
00:28:10,240 --> 00:28:11,720
will return three records.

731
00:28:11,720 --> 00:28:14,560
Not 50,000, the request is smaller, it's faster,

732
00:28:14,560 --> 00:28:16,800
and it's far less likely to trigger throttling.

733
00:28:16,800 --> 00:28:19,320
Delta queries are available across users, groups, devices,

734
00:28:19,320 --> 00:28:20,160
and teams.

735
00:28:20,160 --> 00:28:22,240
If you're building any change tracking automation,

736
00:28:22,240 --> 00:28:24,440
Delta queries aren't an optimization.

737
00:28:24,440 --> 00:28:26,080
They are the correct architecture.

738
00:28:26,080 --> 00:28:28,920
We're pokes and change notifications go one step further.

739
00:28:28,920 --> 00:28:31,160
Instead of your system asking graph what changed,

740
00:28:31,160 --> 00:28:33,400
graph tells your system the moment something happens.

741
00:28:33,400 --> 00:28:36,080
An event fires, your endpoint receives a notification,

742
00:28:36,080 --> 00:28:38,200
and your automation runs only when there's actually

743
00:28:38,200 --> 00:28:39,440
something to process.

744
00:28:39,440 --> 00:28:41,320
This is event-driven architecture.

745
00:28:41,320 --> 00:28:43,120
It eliminates empty work.

746
00:28:43,120 --> 00:28:45,440
Those requests that consume quota and generate load

747
00:28:45,440 --> 00:28:46,560
while returning no data.

748
00:28:46,560 --> 00:28:49,840
In reality, webhooks require more upfront engineering.

749
00:28:49,840 --> 00:28:51,760
Your notification endpoint needs to be public.

750
00:28:51,760 --> 00:28:53,800
It needs to handle validation challenges,

751
00:28:53,800 --> 00:28:56,680
and it must manage retry logic for missed deliveries.

752
00:28:56,680 --> 00:28:58,920
Subscription renewals are a common failure point

753
00:28:58,920 --> 00:29:01,840
that causes these systems to silently go dark.

754
00:29:01,840 --> 00:29:04,720
If your webhook subscription expires and you don't renew it,

755
00:29:04,720 --> 00:29:06,280
graph stops sending notifications,

756
00:29:06,280 --> 00:29:08,080
and your automation stops responding.

757
00:29:08,080 --> 00:29:09,520
There is no error and no alert.

758
00:29:09,520 --> 00:29:11,040
You have to build subscription renewal

759
00:29:11,040 --> 00:29:14,200
into your monitoring from day one when you do hit throttling.

760
00:29:14,200 --> 00:29:15,520
And you will at some point,

761
00:29:15,520 --> 00:29:17,440
the only response is exponential back off.

762
00:29:17,440 --> 00:29:19,240
You must respect the retry after header.

763
00:29:19,240 --> 00:29:21,840
Graph returns that header to tell you exactly how long

764
00:29:21,840 --> 00:29:23,640
to wait before you try again.

765
00:29:23,640 --> 00:29:25,520
If you ignore it and retry immediately,

766
00:29:25,520 --> 00:29:27,600
your next request counts against the same quota

767
00:29:27,600 --> 00:29:28,600
that just ran out.

768
00:29:28,600 --> 00:29:29,800
Immediate retries don't help.

769
00:29:29,800 --> 00:29:30,960
They make it worse.

770
00:29:30,960 --> 00:29:33,560
They can also create a noisy neighbor effect.

771
00:29:33,560 --> 00:29:36,160
This is where one team's aggressive retry behavior raises

772
00:29:36,160 --> 00:29:37,600
throttling pressure for everyone else

773
00:29:37,600 --> 00:29:39,120
sharing those service limits.

774
00:29:39,120 --> 00:29:41,880
Pagination discipline rounds out the performance picture.

775
00:29:41,880 --> 00:29:44,800
Chunking large results sets into smaller pages,

776
00:29:44,800 --> 00:29:46,880
reduces individual response sizes,

777
00:29:46,880 --> 00:29:49,000
and keeps each request within the limits.

778
00:29:49,000 --> 00:29:50,600
Small chunks might feel safer,

779
00:29:50,600 --> 00:29:52,720
but they actually hurt throughput at scale

780
00:29:52,720 --> 00:29:55,320
because they create more round trips and more overhead.

781
00:29:55,320 --> 00:29:57,920
You have to match your page size to your actual data

782
00:29:57,920 --> 00:30:00,680
and measure the results before you make any assumptions.

783
00:30:00,680 --> 00:30:02,080
The permission debt problem,

784
00:30:02,080 --> 00:30:04,240
why co-pilot deployments fail.

785
00:30:04,240 --> 00:30:06,680
Here is the conversation happening in boardrooms right now.

786
00:30:06,680 --> 00:30:10,120
An executive approves co-pilot IT spins up the licenses,

787
00:30:10,120 --> 00:30:11,760
uses start prompting.

788
00:30:11,760 --> 00:30:13,440
And then, something breaks.

789
00:30:13,440 --> 00:30:16,280
Co-pilot surfaces a confidential salary spreadsheet

790
00:30:16,280 --> 00:30:18,440
to an employee who should never have seen it.

791
00:30:18,440 --> 00:30:21,240
It summarizes a document from a discontinued acquisition

792
00:30:21,240 --> 00:30:22,600
that was never restricted.

793
00:30:22,600 --> 00:30:24,560
It finds content sitting in a sharepoint site

794
00:30:24,560 --> 00:30:27,000
from three years ago that still has default permissions.

795
00:30:27,000 --> 00:30:30,200
The deployment gets paused, the incident gets escalated.

796
00:30:30,200 --> 00:30:32,440
And everyone asks the same wrong question.

797
00:30:32,440 --> 00:30:33,920
What did co-pilot do?

798
00:30:33,920 --> 00:30:35,080
Co-pilot didn't do anything.

799
00:30:35,080 --> 00:30:37,080
It worked exactly as it was designed to work.

800
00:30:37,080 --> 00:30:39,320
The problem existed long before the AI arrived.

801
00:30:39,320 --> 00:30:41,440
Permission debt is the accumulation of access

802
00:30:41,440 --> 00:30:44,760
that was granted broadly, never reviewed, and never cleaned up.

803
00:30:44,760 --> 00:30:46,320
It builds silently over years.

804
00:30:46,320 --> 00:30:49,000
Maybe a sharepoint site was created with everyone membership

805
00:30:49,000 --> 00:30:51,520
because it was faster than defining a proper audience.

806
00:30:51,520 --> 00:30:54,040
Or a team's channel was made visible to the whole organization

807
00:30:54,040 --> 00:30:56,240
because the owner didn't understand the settings.

808
00:30:56,240 --> 00:30:58,400
Sharing links are generated and forgotten.

809
00:30:58,400 --> 00:31:00,240
Groups keep stale memberships from projects

810
00:31:00,240 --> 00:31:01,480
that ended two years ago.

811
00:31:01,480 --> 00:31:03,440
None of these felt like problems before.

812
00:31:03,440 --> 00:31:05,120
Because humans had to know where to look.

813
00:31:05,120 --> 00:31:08,240
Content that was technically accessible was practically obscure.

814
00:31:08,240 --> 00:31:10,760
Co-pilot removes that obscurity.

815
00:31:10,760 --> 00:31:13,680
Natural language queries don't care about organizational

816
00:31:13,680 --> 00:31:16,000
conventions or where things are supposed to be.

817
00:31:16,000 --> 00:31:18,360
A user asking for a summary of executive communications

818
00:31:18,360 --> 00:31:20,760
doesn't need to know which library holds those files.

819
00:31:20,760 --> 00:31:21,880
Co-pilot finds them.

820
00:31:21,880 --> 00:31:24,960
If permissions allow it, co-pilot surfaces them.

821
00:31:24,960 --> 00:31:27,320
The content that was technically accessible,

822
00:31:27,320 --> 00:31:29,640
but nobody knew about it, becomes instantly

823
00:31:29,640 --> 00:31:33,720
discoverable by anyone with a license and enough curiosity to ask.

824
00:31:33,720 --> 00:31:36,120
Microsoft's own security guidance is clear on this.

825
00:31:36,120 --> 00:31:38,200
Co-pilot isn't a tool that breaks security.

826
00:31:38,200 --> 00:31:41,280
It's a tool that reveals where your security was already broken.

827
00:31:41,280 --> 00:31:42,880
The oversharing was always there.

828
00:31:42,880 --> 00:31:44,600
Co-pilot just made it consequential.

829
00:31:44,600 --> 00:31:47,200
To fix this, you need the data access governance reports

830
00:31:47,200 --> 00:31:48,960
in SharePoint Advanced Management.

831
00:31:48,960 --> 00:31:51,200
These are the diagnostic tools for the problem.

832
00:31:51,200 --> 00:31:53,400
They identify sites shared with everyone,

833
00:31:53,400 --> 00:31:56,000
sites with broad anonymous links, and areas

834
00:31:56,000 --> 00:31:58,280
where permissions have drifted from your policy.

835
00:31:58,280 --> 00:32:01,320
Running these reports before you deploy Co-pilot isn't optional.

836
00:32:01,320 --> 00:32:02,600
It is the prerequisite.

837
00:32:02,600 --> 00:32:05,760
The output tells you exactly where the exposure is concentrated

838
00:32:05,760 --> 00:32:07,560
and where your effort should go first.

839
00:32:07,560 --> 00:32:10,720
For large enterprises, that cleanup usually takes four to eight weeks.

840
00:32:10,720 --> 00:32:13,480
The technical fixes are simple, but the scope is massive

841
00:32:13,480 --> 00:32:14,840
and ownership is spread out.

842
00:32:14,840 --> 00:32:16,400
Data owners have to be found.

843
00:32:16,400 --> 00:32:18,120
Content needs to be reclassified.

844
00:32:18,120 --> 00:32:20,600
Access structures have to be rebuilt from a least privileged

845
00:32:20,600 --> 00:32:23,320
baseline rather than just patched at the edges.

846
00:32:23,320 --> 00:32:25,480
Graph-driven permission audits make this manageable

847
00:32:25,480 --> 00:32:27,280
by automating the discovery phase.

848
00:32:27,280 --> 00:32:29,200
They identify membership configurations

849
00:32:29,200 --> 00:32:32,200
and active links so your team can focus on making decisions

850
00:32:32,200 --> 00:32:33,840
instead of just gathering data.

851
00:32:33,840 --> 00:32:35,760
The contrast between organizations that do this work

852
00:32:35,760 --> 00:32:37,320
and those that skip it is stark.

853
00:32:37,320 --> 00:32:40,520
Companies with tight permissions report immediate productivity gains,

854
00:32:40,520 --> 00:32:41,920
email drafting time drops.

855
00:32:41,920 --> 00:32:44,000
Meeting summaries arrive without prompting.

856
00:32:44,000 --> 00:32:46,000
Document search becomes conversational.

857
00:32:46,000 --> 00:32:49,040
The tool works because the data underneath it is governed.

858
00:32:49,040 --> 00:32:52,640
Organizations that skip the audit find themselves managing incidents

859
00:32:52,640 --> 00:32:54,400
instead of capturing value.

860
00:32:54,400 --> 00:32:56,360
And the cost of that delay compounds every week

861
00:32:56,360 --> 00:32:58,480
that permission debt stays on the books is another week

862
00:32:58,480 --> 00:33:01,320
where the deployment is blocked and the ROI stays hypothetical.

863
00:33:01,320 --> 00:33:02,880
Permission debt is a structural problem.

864
00:33:02,880 --> 00:33:06,440
Let's talk about the architectural patterns that prevent it.

865
00:33:06,440 --> 00:33:09,920
Policy as code, the operating system for enterprise governance.

866
00:33:09,920 --> 00:33:12,680
There is a telling difference between two types of organizations.

867
00:33:12,680 --> 00:33:14,560
The first has a governance policy document.

868
00:33:14,560 --> 00:33:15,680
It's 50 pages long.

869
00:33:15,680 --> 00:33:18,720
It was reviewed by legal and approved by the CISO.

870
00:33:18,720 --> 00:33:21,880
It sits on a share point site where it gets updated once a year

871
00:33:21,880 --> 00:33:24,120
and read by almost nobody.

872
00:33:24,120 --> 00:33:27,200
The second organization has governance policies that run as code.

873
00:33:27,200 --> 00:33:28,600
They are versioned in a repository.

874
00:33:28,600 --> 00:33:30,440
They are tested in a staging environment.

875
00:33:30,440 --> 00:33:32,200
They are deployed through a pipeline

876
00:33:32,200 --> 00:33:35,200
and they are automatically enforced from the moment they go live.

877
00:33:35,200 --> 00:33:37,400
Only one of those organizations actually has governance.

878
00:33:37,400 --> 00:33:39,080
The first has documentation.

879
00:33:39,080 --> 00:33:40,600
The second has infrastructure.

880
00:33:40,600 --> 00:33:43,280
Policy as code applies software engineering principles

881
00:33:43,280 --> 00:33:45,720
to your Microsoft 365 setup.

882
00:33:45,720 --> 00:33:48,480
Naming conventions, retention schedules and DLP rules

883
00:33:48,480 --> 00:33:50,920
are no longer just setting someone clicked in a portal.

884
00:33:50,920 --> 00:33:54,040
They exist as scripts that declare exactly how the tenant should look

885
00:33:54,040 --> 00:33:56,400
the script runs, the configuration exists,

886
00:33:56,400 --> 00:33:59,240
the script runs again, the configuration is validated.

887
00:33:59,240 --> 00:34:01,080
If someone changes a setting manually

888
00:34:01,080 --> 00:34:02,840
and bypasses the standard process,

889
00:34:02,840 --> 00:34:05,160
the next pipeline execution detects that drift.

890
00:34:05,160 --> 00:34:08,520
It either alerts the team or fixes the setting automatically.

891
00:34:08,520 --> 00:34:11,160
That drift detection is what separates policy as code

892
00:34:11,160 --> 00:34:12,920
from just having a few scripts.

893
00:34:12,920 --> 00:34:15,040
Configuration drift is one of the most ignored risks

894
00:34:15,040 --> 00:34:16,360
in enterprise tenants.

895
00:34:16,360 --> 00:34:19,360
A setting gets changed for a quick fix and never changed back.

896
00:34:19,360 --> 00:34:21,360
An exception is granted during an incident

897
00:34:21,360 --> 00:34:23,040
and becomes permanent by default.

898
00:34:23,040 --> 00:34:25,000
Manual drift builds up silently.

899
00:34:25,000 --> 00:34:27,920
The only way to find it without code is a full manual audit

900
00:34:27,920 --> 00:34:29,720
which we already know takes weeks.

901
00:34:29,720 --> 00:34:32,640
With coded policies, drift is detected every single day.

902
00:34:32,640 --> 00:34:35,840
Your pipeline runs nightly and compares the actual state

903
00:34:35,840 --> 00:34:37,960
of the tenant against your desired state.

904
00:34:37,960 --> 00:34:41,160
Every deviation generates a report or an automatic correction.

905
00:34:41,160 --> 00:34:43,920
The tenant doesn't drift for months before someone notices.

906
00:34:43,920 --> 00:34:46,800
It drifts for hours before the automation catches it.

907
00:34:46,800 --> 00:34:51,640
CICD pipelines also bring something governance has always lacked, testing.

908
00:34:51,640 --> 00:34:55,240
When you propose a new DLP rule or a change to conditional access,

909
00:34:55,240 --> 00:34:56,920
the pipeline validates it in a lab

910
00:34:56,920 --> 00:34:59,120
before it touches your production environment.

911
00:34:59,120 --> 00:35:01,480
The change is reviewed and merged with the same rigor

912
00:35:01,480 --> 00:35:03,680
a software team uses for code release.

913
00:35:03,680 --> 00:35:05,880
Policy changes that could block thousands of users

914
00:35:05,880 --> 00:35:08,440
no longer go straight from an admin's head into production.

915
00:35:08,440 --> 00:35:10,280
They go through a quality gate first.

916
00:35:10,280 --> 00:35:13,320
This model also gives you a deterministic rollback capability.

917
00:35:13,320 --> 00:35:14,880
When a policy change causes an issue,

918
00:35:14,880 --> 00:35:17,400
you simply revert to the previous version in the repository

919
00:35:17,400 --> 00:35:18,480
and run the pipeline.

920
00:35:18,480 --> 00:35:20,440
The previous state is restored instantly.

921
00:35:20,440 --> 00:35:22,120
There is no manual reconstruction.

922
00:35:22,120 --> 00:35:24,840
You don't have to try and remember what the setting used to be.

923
00:35:24,840 --> 00:35:26,320
The version history is right there.

924
00:35:26,320 --> 00:35:30,080
The ROI for policy as code is strongest in regulated industries,

925
00:35:30,080 --> 00:35:31,440
but it applies to everyone.

926
00:35:31,440 --> 00:35:35,480
You get fewer audit findings because your configurations are consistent and verified.

927
00:35:35,480 --> 00:35:38,640
You get faster remediation because fixes are deployed by a pipeline

928
00:35:38,640 --> 00:35:40,040
instead of manual clicks.

929
00:35:40,040 --> 00:35:43,480
You also get audit-ready documentation as a byproduct of the process.

930
00:35:43,480 --> 00:35:46,280
Your repository history is the evidence trail of what changed,

931
00:35:46,280 --> 00:35:48,040
who approved it and when it happened.

932
00:35:48,040 --> 00:35:50,680
That trail doesn't exist in a portal-managed environment,

933
00:35:50,680 --> 00:35:53,680
unless someone logs every click, which nobody actually does.

934
00:35:53,680 --> 00:35:55,000
The cultural shift here is real.

935
00:35:55,000 --> 00:35:57,880
Treating governance like software means owning it like software.

936
00:35:57,880 --> 00:36:01,120
It requires version control, code reviews and deployment discipline

937
00:36:01,120 --> 00:36:03,840
for IT teams used to portal-based administration.

938
00:36:03,840 --> 00:36:06,960
This can feel like over-engineering, but it isn't.

939
00:36:06,960 --> 00:36:09,560
It is the difference between governance that holds its scale

940
00:36:09,560 --> 00:36:11,960
and governance that breaks the moment something goes wrong.

941
00:36:11,960 --> 00:36:14,120
Policy as code doesn't replace human judgment.

942
00:36:14,120 --> 00:36:17,200
Decisions still have to be made by people who understand the business.

943
00:36:17,200 --> 00:36:20,440
What it replaces is the gap between deciding something should be true

944
00:36:20,440 --> 00:36:22,280
and ensuring it actually is.

945
00:36:22,280 --> 00:36:24,000
Policy as code is the infrastructure layer.

946
00:36:24,000 --> 00:36:26,960
Now let's talk about the automation patterns that actually work.

947
00:36:26,960 --> 00:36:30,240
The Adempotent Principle scripts that are safe to run repeatedly.

948
00:36:30,240 --> 00:36:34,960
Policy as code is your framework, but idempotency, that's the engineering discipline.

949
00:36:34,960 --> 00:36:37,040
It's what makes a script safe enough to run

950
00:36:37,040 --> 00:36:39,080
without you watching over its shoulder.

951
00:36:39,080 --> 00:36:40,280
The concept is simple.

952
00:36:40,280 --> 00:36:42,720
An idempotent script produces the exact same result

953
00:36:42,720 --> 00:36:44,840
whether you run it once or a hundred times.

954
00:36:44,840 --> 00:36:46,720
The first run builds the state you want.

955
00:36:46,720 --> 00:36:49,640
Every run after that just confirms the state is still there.

956
00:36:49,640 --> 00:36:51,080
And then it exits quietly.

957
00:36:51,080 --> 00:36:51,960
No side effects.

958
00:36:51,960 --> 00:36:53,320
You don't get duplicate accounts.

959
00:36:53,320 --> 00:36:55,200
You don't get double-license assignments.

960
00:36:55,200 --> 00:36:57,640
You don't see the same person added to a group twice.

961
00:36:57,640 --> 00:36:59,520
The script doesn't care about its own history.

962
00:36:59,520 --> 00:37:01,520
It only cares about what's true right now,

963
00:37:01,520 --> 00:37:03,160
compares that to what should be true

964
00:37:03,160 --> 00:37:05,200
and only acts on the gap between the two.

965
00:37:05,200 --> 00:37:07,520
In Graph PowerShell, the pattern is always the same.

966
00:37:07,520 --> 00:37:10,600
You use GetMJ before you ever touch NewMix always.

967
00:37:10,600 --> 00:37:13,400
You check if the user exists before you try to create them.

968
00:37:13,400 --> 00:37:16,360
You verify the group membership before you try to add it.

969
00:37:16,360 --> 00:37:19,080
You confirm the license is there before you try to grant it.

970
00:37:19,080 --> 00:37:21,360
If the condition is already met, you skip the action.

971
00:37:21,360 --> 00:37:22,640
And you log that you skipped it.

972
00:37:22,640 --> 00:37:24,640
If it isn't met, you take the action

973
00:37:24,640 --> 00:37:25,880
and you log what you did.

974
00:37:25,880 --> 00:37:28,120
That distinction in your logs actually matters.

975
00:37:28,120 --> 00:37:30,080
Already exists, skipped,

976
00:37:30,080 --> 00:37:34,240
and did not exist created are two very different stories.

977
00:37:34,240 --> 00:37:37,000
They tell you how your pipeline is actually performing over time.

978
00:37:37,000 --> 00:37:38,800
This shift changes how you operate.

979
00:37:38,800 --> 00:37:41,800
It allows for scheduled automation without manual oversight.

980
00:37:41,800 --> 00:37:43,400
A provisioning script that runs every night

981
00:37:43,400 --> 00:37:44,760
doesn't need a human monitor

982
00:37:44,760 --> 00:37:46,920
because it can't make things worse by running again.

983
00:37:46,920 --> 00:37:48,880
If Monday's run was a success, Tuesday's run

984
00:37:48,880 --> 00:37:51,520
finds everything in the right spot and finishes instantly.

985
00:37:51,520 --> 00:37:54,800
But if Monday's run hit a network timeout or a throttling event,

986
00:37:54,800 --> 00:37:57,200
Tuesday's run picks up exactly where the last one stopped.

987
00:37:57,200 --> 00:37:58,640
It finishes the job.

988
00:37:58,640 --> 00:38:01,120
The end state is correct, regardless of how many times

989
00:38:01,120 --> 00:38:02,440
the connection dropped.

990
00:38:02,440 --> 00:38:05,200
Error handling here requires a specific kind of discipline.

991
00:38:05,200 --> 00:38:06,640
You have to distinguish between,

992
00:38:06,640 --> 00:38:08,920
this was already done and this failed.

993
00:38:08,920 --> 00:38:10,800
At the code level, they look similar.

994
00:38:10,800 --> 00:38:13,280
Neither one results in a new action.

995
00:38:13,280 --> 00:38:16,760
But operationally, they are opposites.

996
00:38:16,760 --> 00:38:19,120
An account that already exists is a win.

997
00:38:19,120 --> 00:38:21,560
An account creation that through a 403 error

998
00:38:21,560 --> 00:38:23,360
is a failure that needs a human to look at it.

999
00:38:23,360 --> 00:38:25,600
If you collapse these into a single skip path,

1000
00:38:25,600 --> 00:38:28,680
you're just hiding real failures inside expected behavior.

1001
00:38:28,680 --> 00:38:30,240
Then there's partial failure handling.

1002
00:38:30,240 --> 00:38:32,280
If you're processing a thousand users

1003
00:38:32,280 --> 00:38:35,160
and user 400 fails because of a missing attribute,

1004
00:38:35,160 --> 00:38:36,400
the script shouldn't stop.

1005
00:38:36,400 --> 00:38:41,720
It should log the error, move to user 401 and finish the run.

1006
00:38:41,720 --> 00:38:44,000
At the end, your failure log tells you exactly

1007
00:38:44,000 --> 00:38:45,560
which records need to fix.

1008
00:38:45,560 --> 00:38:48,880
The 999 users who succeeded shouldn't have to wait for the one

1009
00:38:48,880 --> 00:38:49,680
who didn't.

1010
00:38:49,680 --> 00:38:51,240
Finally, you need safety limits.

1011
00:38:51,240 --> 00:38:52,840
If a script does something destructive,

1012
00:38:52,840 --> 00:38:54,880
like deleting accounts or pulling licenses,

1013
00:38:54,880 --> 00:38:57,640
it needs a hard cap on how much it can change in one go.

1014
00:38:57,640 --> 00:38:59,880
A script designed to disable inactive accounts

1015
00:38:59,880 --> 00:39:01,840
should never hit more than a small percentage

1016
00:39:01,840 --> 00:39:03,320
of your users in a single run.

1017
00:39:03,320 --> 00:39:05,080
It doesn't matter what the query says.

1018
00:39:05,080 --> 00:39:07,040
That limit is there to catch logic errors.

1019
00:39:07,040 --> 00:39:10,360
It catches the filter mistake that makes everyone look inactive.

1020
00:39:10,360 --> 00:39:11,960
The cap doesn't stop your automation.

1021
00:39:11,960 --> 00:39:13,600
It stops an automation disaster.

1022
00:39:13,600 --> 00:39:15,920
Identity is a discipline.

1023
00:39:15,920 --> 00:39:17,600
Now let's look at where this actually pays off

1024
00:39:17,600 --> 00:39:20,320
in the real world, automation that delivers ROI.

1025
00:39:20,320 --> 00:39:21,400
Three case studies.

1026
00:39:21,400 --> 00:39:24,200
Theories fine, but numbers are better.

1027
00:39:24,200 --> 00:39:25,760
Let's look at three organizations that

1028
00:39:25,760 --> 00:39:28,560
built their automation on graph and measured the impact.

1029
00:39:28,560 --> 00:39:32,440
First, a global manufacturer with 20,000 factory tablets.

1030
00:39:32,440 --> 00:39:35,080
Before they used automation, every single device

1031
00:39:35,080 --> 00:39:38,000
needed a manual setup, a technician, a ticket,

1032
00:39:38,000 --> 00:39:39,720
a physical checklist.

1033
00:39:39,720 --> 00:39:43,040
At that scale, managing devices wasn't an IT job.

1034
00:39:43,040 --> 00:39:45,000
It was a massive logistics nightmare.

1035
00:39:45,000 --> 00:39:48,120
They moved to zero touch enrollment using Intune and the graph API.

1036
00:39:48,120 --> 00:39:51,000
They used PowerShell scripts to handle the configuration,

1037
00:39:51,000 --> 00:39:53,280
the apps, and the compliance reports.

1038
00:39:53,280 --> 00:39:55,320
Not a single person had to touch the devices.

1039
00:39:55,320 --> 00:39:57,160
The results were massive.

1040
00:39:57,160 --> 00:40:00,080
90% of their management tasks are now fully automated.

1041
00:40:00,080 --> 00:40:02,920
They reclaimed 15,000 hours of labor every year.

1042
00:40:02,920 --> 00:40:04,920
That's time that used to vanish into manual setups

1043
00:40:04,920 --> 00:40:05,840
and troubleshooting.

1044
00:40:05,840 --> 00:40:09,000
Vulnerabilities dropped by 65% because the scripts

1045
00:40:09,000 --> 00:40:11,360
didn't forget to patch things like humans do.

1046
00:40:11,360 --> 00:40:12,360
And audit prep?

1047
00:40:12,360 --> 00:40:14,120
That went from three weeks of stress down

1048
00:40:14,120 --> 00:40:15,720
to two days of clicking buttons.

1049
00:40:15,720 --> 00:40:18,200
The evidence collection was just a scheduled script.

1050
00:40:18,200 --> 00:40:19,400
The difference wasn't the tools.

1051
00:40:19,400 --> 00:40:22,280
It was treating device management as a programmable system

1052
00:40:22,280 --> 00:40:23,680
instead of a list of chores.

1053
00:40:23,680 --> 00:40:25,360
The scripts were "identbitant".

1054
00:40:25,360 --> 00:40:26,520
The pipelines were versioned.

1055
00:40:26,520 --> 00:40:27,640
The outcomes were measured.

1056
00:40:27,640 --> 00:40:29,760
That's why the numbers actually held up.

1057
00:40:29,760 --> 00:40:32,000
The second case is a financial firm with a problem most

1058
00:40:32,000 --> 00:40:34,160
of you probably have orphaned licenses.

1059
00:40:34,160 --> 00:40:35,560
They had licenses sitting on accounts

1060
00:40:35,560 --> 00:40:37,120
that hadn't been touched in months.

1061
00:40:37,120 --> 00:40:39,560
Service accounts were holding e-fives for no reason.

1062
00:40:39,560 --> 00:40:42,440
People changed roles but kept their old expensive licenses.

1063
00:40:42,440 --> 00:40:45,560
At their scale, this waste was invisible to a manual review.

1064
00:40:45,560 --> 00:40:47,800
They built a graph-driven optimization script.

1065
00:40:47,800 --> 00:40:49,600
It cross-referenced assigned licenses

1066
00:40:49,600 --> 00:40:52,600
against actual usage signals from the reporting API.

1067
00:40:52,600 --> 00:40:55,400
If an account had no logins and no activity for 90 days,

1068
00:40:55,400 --> 00:40:56,320
it got flagged.

1069
00:40:56,320 --> 00:40:57,800
Owners got a notification.

1070
00:40:57,800 --> 00:41:00,400
Licenses were reclaimed after a review period.

1071
00:41:00,400 --> 00:41:02,040
And because the script kept running,

1072
00:41:02,040 --> 00:41:03,960
the waste couldn't pile up again in secret.

1073
00:41:03,960 --> 00:41:07,320
The outcome was a reclaimed license spend of about 15%.

1074
00:41:07,320 --> 00:41:09,280
For an enterprise with thousands of seats,

1075
00:41:09,280 --> 00:41:11,520
that is six figure savings every single year.

1076
00:41:11,520 --> 00:41:14,000
The automation paid for itself in less than 12 months.

1077
00:41:14,000 --> 00:41:15,800
The scripts weren't even that complex.

1078
00:41:15,800 --> 00:41:17,320
The problem was just widespread.

1079
00:41:17,320 --> 00:41:18,680
And the solution never stopped running.

1080
00:41:18,680 --> 00:41:20,560
The third case is an insurance company

1081
00:41:20,560 --> 00:41:22,160
that wanted to roll out copilot.

1082
00:41:22,160 --> 00:41:25,400
But they did something smart before they assigned a single license.

1083
00:41:25,400 --> 00:41:27,600
They ran a data readiness audit for four weeks.

1084
00:41:27,600 --> 00:41:31,120
They used graph to audit permissions across SharePoint and OneDrive.

1085
00:41:31,120 --> 00:41:32,480
They generated governance reports

1086
00:41:32,480 --> 00:41:34,520
to find sites with everyone access.

1087
00:41:34,520 --> 00:41:37,760
They mapped out external sharing links and sensitivity labels.

1088
00:41:37,760 --> 00:41:39,400
The audit didn't just find problems.

1089
00:41:39,400 --> 00:41:40,920
It quantified them.

1090
00:41:40,920 --> 00:41:42,840
It let them prioritize the cleanup

1091
00:41:42,840 --> 00:41:45,600
based on actual business risk instead of a gut feeling.

1092
00:41:45,600 --> 00:41:47,160
The cleanup took another four weeks.

1093
00:41:47,160 --> 00:41:49,000
They restructured the messy sites.

1094
00:41:49,000 --> 00:41:50,920
They applied labels to content that had been sitting

1095
00:41:50,920 --> 00:41:52,360
unclassified for years.

1096
00:41:52,360 --> 00:41:54,720
They revoked the old sharing links only after the house

1097
00:41:54,720 --> 00:41:57,040
was cleaned that the copilot licenses go out.

1098
00:41:57,040 --> 00:41:58,960
The result was a rollout that actually worked.

1099
00:41:58,960 --> 00:42:02,880
Users saw a 30% drop in the time they spent drafting emails and summaries.

1100
00:42:02,880 --> 00:42:05,840
And because they took a baseline measurement before they started,

1101
00:42:05,840 --> 00:42:07,560
the ROI was a fact, not a guess.

1102
00:42:07,560 --> 00:42:09,840
They had something most copilot adopters are missing.

1103
00:42:09,840 --> 00:42:13,000
They had evidence, three industries, three different problems.

1104
00:42:13,000 --> 00:42:14,520
But the pattern is the same.

1105
00:42:14,520 --> 00:42:17,000
Automation built on graph.

1106
00:42:17,000 --> 00:42:20,640
Measured from day one and scaled because the foundation was solid.

1107
00:42:20,640 --> 00:42:22,160
These aren't what-if scenarios.

1108
00:42:22,160 --> 00:42:23,240
They are happening right now.

1109
00:42:23,240 --> 00:42:25,480
So let's talk about where we go from here.

1110
00:42:25,480 --> 00:42:28,400
The copilot connection, how graph powers AI agents,

1111
00:42:28,400 --> 00:42:29,920
copilot isn't a chatbot.

1112
00:42:29,920 --> 00:42:33,040
It isn't some separate tool bolted onto Microsoft 365.

1113
00:42:33,040 --> 00:42:34,520
It's an orchestration layer.

1114
00:42:34,520 --> 00:42:35,920
Built directly on top of graph.

1115
00:42:35,920 --> 00:42:37,960
That means everything we've talked about, permissions,

1116
00:42:37,960 --> 00:42:42,440
life cycle governance, determines whether copilot works well or fails completely.

1117
00:42:42,440 --> 00:42:44,120
The architecture is simple but critical.

1118
00:42:44,120 --> 00:42:47,080
When you submit a prompt, copilot doesn't look at a private AI database.

1119
00:42:47,080 --> 00:42:48,280
It calls graph.

1120
00:42:48,280 --> 00:42:51,400
It queries the semantic index built from your emails, your files,

1121
00:42:51,400 --> 00:42:52,520
and your team's messages.

1122
00:42:52,520 --> 00:42:53,720
It finds the right content.

1123
00:42:53,720 --> 00:42:55,400
And then it applies security trimming.

1124
00:42:55,400 --> 00:42:57,760
It checks your actual graph permissions before the AI

1125
00:42:57,760 --> 00:42:59,080
ever sees the data.

1126
00:42:59,080 --> 00:43:01,640
The model never sees a file you aren't allowed to access.

1127
00:43:01,640 --> 00:43:04,000
Because the enforcement happens at the graph layer.

1128
00:43:04,000 --> 00:43:05,520
But this creates two problems.

1129
00:43:05,520 --> 00:43:08,200
First, copilot is only as smart as your data.

1130
00:43:08,200 --> 00:43:10,920
If your information is messy, fragmented, or labeled wrong,

1131
00:43:10,920 --> 00:43:12,040
the AI will reflect that.

1132
00:43:12,040 --> 00:43:13,360
Garbage in, garbage out.

1133
00:43:13,360 --> 00:43:15,760
Second, and this is the part most people miss.

1134
00:43:15,760 --> 00:43:18,280
Copilot is only as safe as your current permissions.

1135
00:43:18,280 --> 00:43:20,720
There is no separate security layer for AI.

1136
00:43:20,720 --> 00:43:22,440
There are no copilot permissions.

1137
00:43:22,440 --> 00:43:24,600
It simply inherits what you've already built.

1138
00:43:24,600 --> 00:43:27,280
If you did the work to clean up your permissions before you deployed,

1139
00:43:27,280 --> 00:43:30,240
you see the benefit immediately, relevant file surface.

1140
00:43:30,240 --> 00:43:32,240
Confidential data stays hidden.

1141
00:43:32,240 --> 00:43:34,200
The tool earns trust because it behaves exactly

1142
00:43:34,200 --> 00:43:35,000
how you expect it to.

1143
00:43:35,000 --> 00:43:36,680
But if you skipped the governance work,

1144
00:43:36,680 --> 00:43:39,040
you usually find out through an uncomfortable incident.

1145
00:43:39,040 --> 00:43:41,680
Sensitivity labels and DLP policies are the only things

1146
00:43:41,680 --> 00:43:43,280
keeping the AI in check.

1147
00:43:43,280 --> 00:43:45,960
If a document is labeled confidential in purview,

1148
00:43:45,960 --> 00:43:48,080
copilot won't show it to someone without the right access

1149
00:43:48,080 --> 00:43:48,600
here.

1150
00:43:48,600 --> 00:43:50,280
These aren't special AI settings.

1151
00:43:50,280 --> 00:43:52,760
They are the same controls you use for everything else.

1152
00:43:52,760 --> 00:43:53,800
And that's the point.

1153
00:43:53,800 --> 00:43:56,800
Governance built for one purpose covers every purpose.

1154
00:43:56,800 --> 00:43:58,960
Graph connectors extend this even further.

1155
00:43:58,960 --> 00:44:01,600
Your knowledge doesn't just live in Microsoft 365.

1156
00:44:01,600 --> 00:44:04,680
It's in service now, Salesforce and SAP.

1157
00:44:04,680 --> 00:44:07,240
Connectors pull that external data into the semantic index,

1158
00:44:07,240 --> 00:44:08,600
making it available to the AI.

1159
00:44:08,600 --> 00:44:10,320
But if your connector permissions are wrong,

1160
00:44:10,320 --> 00:44:12,360
you've just created a fast line for data leaks.

1161
00:44:12,360 --> 00:44:13,560
The model is shifting.

1162
00:44:13,560 --> 00:44:15,240
Copilot agents are now being registered

1163
00:44:15,240 --> 00:44:16,880
as first class objects in Entra.

1164
00:44:16,880 --> 00:44:18,080
They have identities.

1165
00:44:18,080 --> 00:44:19,200
They have permissions.

1166
00:44:19,200 --> 00:44:21,800
You govern them through Graph just like a service principle.

1167
00:44:21,800 --> 00:44:23,440
The work you do today on permission hygiene

1168
00:44:23,440 --> 00:44:25,320
isn't just prep work for the future.

1169
00:44:25,320 --> 00:44:27,280
It is the prerequisite for the AI you're

1170
00:44:27,280 --> 00:44:28,600
trying to use right now.

1171
00:44:28,600 --> 00:44:29,840
The work isn't ahead of you.

1172
00:44:29,840 --> 00:44:31,680
It's what's blocking you.

1173
00:44:31,680 --> 00:44:33,800
Copilot is the present.

1174
00:44:33,800 --> 00:44:35,640
Now let's talk about the agentic future.

1175
00:44:35,640 --> 00:44:38,600
Agent 365 and the agentic future, autonomous systems

1176
00:44:38,600 --> 00:44:39,400
on Graph.

1177
00:44:39,400 --> 00:44:41,680
The governance conversation is about to get complicated,

1178
00:44:41,680 --> 00:44:43,280
not because the rules are changing,

1179
00:44:43,280 --> 00:44:44,760
but because the actors are.

1180
00:44:44,760 --> 00:44:46,480
Right now, you have two types of entities

1181
00:44:46,480 --> 00:44:49,200
in your tenant, humans and applications.

1182
00:44:49,200 --> 00:44:50,520
Humans log in and do work.

1183
00:44:50,520 --> 00:44:52,720
Applications run as service principles and followers

1184
00:44:52,720 --> 00:44:55,840
script. You manage both through Entra ID and the Graph API.

1185
00:44:55,840 --> 00:44:56,800
It's a mature model.

1186
00:44:56,800 --> 00:45:00,320
But now we're adding a third category, autonomous agents.

1187
00:45:00,320 --> 00:45:02,160
These aren't apps that follow a fixed path.

1188
00:45:02,160 --> 00:45:04,840
Agents get a goal and they plan the steps to reach it.

1189
00:45:04,840 --> 00:45:07,080
If you ask an agent to write a board report,

1190
00:45:07,080 --> 00:45:08,320
it doesn't just run a script.

1191
00:45:08,320 --> 00:45:10,000
It decides which data to gather.

1192
00:45:10,000 --> 00:45:11,360
It queries graph for files.

1193
00:45:11,360 --> 00:45:13,640
It identifies gaps and asks for more info.

1194
00:45:13,640 --> 00:45:17,280
It does all of this without a human directing every single click.

1195
00:45:17,280 --> 00:45:19,680
Microsoft is building the infrastructure to control this.

1196
00:45:19,680 --> 00:45:23,760
Agent 365 moves agent management into one single control plane.

1197
00:45:23,760 --> 00:45:26,160
It gives you the same visibility over agents

1198
00:45:26,160 --> 00:45:28,360
that you have over service principles today.

1199
00:45:28,360 --> 00:45:29,880
Agents are registered in your directory.

1200
00:45:29,880 --> 00:45:31,760
They have identities and they have scopes.

1201
00:45:31,760 --> 00:45:33,200
They show up in your audit logs.

1202
00:45:33,200 --> 00:45:35,640
You can put them in groups and define exactly what

1203
00:45:35,640 --> 00:45:36,920
they are authorized to do.

1204
00:45:36,920 --> 00:45:39,480
The registry graph APIs for this are moving fast.

1205
00:45:39,480 --> 00:45:42,040
They were in preview in early 2026,

1206
00:45:42,040 --> 00:45:45,280
with full release targeted for June, 2026.

1207
00:45:45,280 --> 00:45:47,520
This allows you to onboard agents at scale.

1208
00:45:47,520 --> 00:45:49,880
You can inventory every agent running in your tenant

1209
00:45:49,880 --> 00:45:51,840
and feed that data into your risk reports.

1210
00:45:51,840 --> 00:45:55,400
Underneath it all is the model context protocol or MCP.

1211
00:45:55,400 --> 00:45:58,320
This is the layer that standardizes how agents talk to tools.

1212
00:45:58,320 --> 00:46:00,240
When these servers are governed through graph,

1213
00:46:00,240 --> 00:46:01,800
graph becomes the enforcement point.

1214
00:46:01,800 --> 00:46:04,040
It decides which tools an agent can use

1215
00:46:04,040 --> 00:46:05,600
and which data sources it can touch.

1216
00:46:05,600 --> 00:46:07,880
One agent calling another agent to finish a task

1217
00:46:07,880 --> 00:46:09,160
isn't a theory anymore.

1218
00:46:09,160 --> 00:46:10,680
It's on the roadmap.

1219
00:46:10,680 --> 00:46:13,640
The only question is whether your tenant is ready to control it

1220
00:46:13,640 --> 00:46:14,880
for architects.

1221
00:46:14,880 --> 00:46:17,320
This means graph power shell is becoming your DevOps surface

1222
00:46:17,320 --> 00:46:20,680
for AI, registering agents, managing their life cycle,

1223
00:46:20,680 --> 00:46:22,200
auditing their work.

1224
00:46:22,200 --> 00:46:23,480
It all runs through graph.

1225
00:46:23,480 --> 00:46:25,920
If you already have a foundation in policy as code,

1226
00:46:25,920 --> 00:46:28,000
you'll absorb this easily if you don't.

1227
00:46:28,000 --> 00:46:29,960
You're going to have a new category of ungoverned actors

1228
00:46:29,960 --> 00:46:31,400
running wild in your system.

1229
00:46:31,400 --> 00:46:32,960
The scale is the challenge.

1230
00:46:32,960 --> 00:46:35,240
Agents aren't that different from service principles.

1231
00:46:35,240 --> 00:46:36,640
They still need least privilege.

1232
00:46:36,640 --> 00:46:38,160
They still need regular reviews.

1233
00:46:38,160 --> 00:46:39,600
They still need clear owners.

1234
00:46:39,600 --> 00:46:41,600
The only thing that changes is the volume

1235
00:46:41,600 --> 00:46:43,000
and the speed, the organizations

1236
00:46:43,000 --> 00:46:44,560
that master graph governance now

1237
00:46:44,560 --> 00:46:46,600
are building the only safe way to use AI.

1238
00:46:46,600 --> 00:46:48,440
The discipline isn't separate from the future.

1239
00:46:48,440 --> 00:46:49,760
It's the only way to get there.

1240
00:46:49,760 --> 00:46:52,120
Agents are a fundamental shift in how we work.

1241
00:46:52,120 --> 00:46:54,280
Let's talk about what that means for your career.

1242
00:46:54,280 --> 00:46:55,600
The skills gap.

1243
00:46:55,600 --> 00:46:58,240
Portal only admins versus graph architects.

1244
00:46:58,240 --> 00:47:01,880
In February of 2026, the Microsoft 365 Admin Center

1245
00:47:01,880 --> 00:47:03,600
went dark for several hours.

1246
00:47:03,600 --> 00:47:05,520
It was a quiet watershed moment.

1247
00:47:05,520 --> 00:47:07,680
For most IT teams, the portal is the only way

1248
00:47:07,680 --> 00:47:08,680
they know how to work.

1249
00:47:08,680 --> 00:47:11,480
When the interface disappeared, their daily operation stopped.

1250
00:47:11,480 --> 00:47:12,600
They couldn't manage licenses.

1251
00:47:12,600 --> 00:47:13,920
They couldn't provision users.

1252
00:47:13,920 --> 00:47:15,600
They were locked out of their own environment.

1253
00:47:15,600 --> 00:47:17,480
But for organizations with mature graph

1254
00:47:17,480 --> 00:47:20,040
and power shell practices, it was just an inconvenience.

1255
00:47:20,040 --> 00:47:21,120
They kept working.

1256
00:47:21,120 --> 00:47:23,240
They managed security events and handled user requests

1257
00:47:23,240 --> 00:47:25,800
through the same API service they use every day.

1258
00:47:25,800 --> 00:47:28,240
While the rest of the world was waiting for a website to load,

1259
00:47:28,240 --> 00:47:30,040
these teams didn't misbeat.

1260
00:47:30,040 --> 00:47:32,440
This incident exposed a reality that is becoming more

1261
00:47:32,440 --> 00:47:33,800
decisive every day.

1262
00:47:33,800 --> 00:47:35,360
The portal is just a rendering layer.

1263
00:47:35,360 --> 00:47:36,880
The real control plane is graph.

1264
00:47:36,880 --> 00:47:39,520
If you only know the portal, you are structurally dependent

1265
00:47:39,520 --> 00:47:41,440
on what Microsoft chooses to show you.

1266
00:47:41,440 --> 00:47:43,840
You're limited by their interface, their feature sets,

1267
00:47:43,840 --> 00:47:45,080
and their data visibility.

1268
00:47:45,080 --> 00:47:48,000
And as we saw in 2026, you're dependent on their uptime.

1269
00:47:48,000 --> 00:47:50,320
The gap between a portal admin and a graph architect

1270
00:47:50,320 --> 00:47:51,920
isn't just about technical skill.

1271
00:47:51,920 --> 00:47:55,240
It's about leverage portal admins implement what the interface allows.

1272
00:47:55,240 --> 00:47:57,200
Graph architects see the entire data model.

1273
00:47:57,200 --> 00:47:58,600
They don't just close tickets.

1274
00:47:58,600 --> 00:48:00,320
They design programmatic infrastructure

1275
00:48:00,320 --> 00:48:02,440
that enforces policy automatically.

1276
00:48:02,440 --> 00:48:04,440
These aren't the same job with different titles.

1277
00:48:04,440 --> 00:48:06,280
They are different roles with completely different career

1278
00:48:06,280 --> 00:48:07,320
trajectories.

1279
00:48:07,320 --> 00:48:09,920
By 2027, this gap will define who gets hired

1280
00:48:09,920 --> 00:48:11,200
and who gets left behind.

1281
00:48:11,200 --> 00:48:12,640
We're already seeing organizations

1282
00:48:12,640 --> 00:48:14,440
form dedicated automation teams.

1283
00:48:14,440 --> 00:48:16,560
These are small groups of graph literate engineers

1284
00:48:16,560 --> 00:48:19,240
who build the systems that replace manual work at scale.

1285
00:48:19,240 --> 00:48:20,800
Five years ago, these roles barely

1286
00:48:20,800 --> 00:48:22,520
existed in mid-sized companies.

1287
00:48:22,520 --> 00:48:24,600
Now, they are standard operating procedure

1288
00:48:24,600 --> 00:48:27,240
for anyone serious about co-pilot deployment

1289
00:48:27,240 --> 00:48:29,320
or large-scale identity governance.

1290
00:48:29,320 --> 00:48:30,880
The market is paying a premium for this

1291
00:48:30,880 --> 00:48:32,560
because the math is simple.

1292
00:48:32,560 --> 00:48:34,160
One architect building policy as code

1293
00:48:34,160 --> 00:48:36,400
can do the work of several manual admins.

1294
00:48:36,400 --> 00:48:38,560
More importantly, they can provide capabilities

1295
00:48:38,560 --> 00:48:40,400
that a manual team couldn't deliver

1296
00:48:40,400 --> 00:48:42,280
regardless of how many people you hired.

1297
00:48:42,280 --> 00:48:44,960
So what does it actually take to become graph literate?

1298
00:48:44,960 --> 00:48:46,920
The learning curve is steeper than clicking buttons

1299
00:48:46,920 --> 00:48:49,080
in a portal, but it's not as high as people think.

1300
00:48:49,080 --> 00:48:52,160
You can learn the fundamentals in a few weeks of focused practice.

1301
00:48:52,160 --> 00:48:54,360
You need to understand the data model, how to navigate

1302
00:48:54,360 --> 00:48:56,440
permissions, and how to call endpoints.

1303
00:48:56,440 --> 00:48:58,600
Microsoft makes this accessible.

1304
00:48:58,600 --> 00:49:00,400
You can go to the Graph Explorer right now

1305
00:49:00,400 --> 00:49:02,360
and run live queries against your own tenant

1306
00:49:02,360 --> 00:49:04,200
without writing a single line of code.

1307
00:49:04,200 --> 00:49:05,640
The documentation is clear.

1308
00:49:05,640 --> 00:49:08,280
The Graph PowerShell SDK handles the heavy lifting

1309
00:49:08,280 --> 00:49:10,400
of the raw mechanics while keeping you close enough

1310
00:49:10,400 --> 00:49:12,120
to the model to understand what's happening.

1311
00:49:12,120 --> 00:49:13,600
Mastery takes longer, of course.

1312
00:49:13,600 --> 00:49:15,760
There is a big difference between calling an endpoint

1313
00:49:15,760 --> 00:49:18,840
and knowing how to chain them together for a complex workflow.

1314
00:49:18,840 --> 00:49:20,200
You have to learn how to write scripts

1315
00:49:20,200 --> 00:49:22,480
that run safely in production and how to avoid

1316
00:49:22,480 --> 00:49:25,240
throttling events that can ripple across your entire tenant.

1317
00:49:25,240 --> 00:49:27,600
You only get that depth by building real things.

1318
00:49:27,600 --> 00:49:29,480
Organizations that invest in this training now

1319
00:49:29,480 --> 00:49:31,760
are buying more than just a technical edge.

1320
00:49:31,760 --> 00:49:34,000
They are building institutional knowledge of how

1321
00:49:34,000 --> 00:49:35,480
their systems actually connect.

1322
00:49:35,480 --> 00:49:37,040
They aren't looking at a UI.

1323
00:49:37,040 --> 00:49:38,760
They are looking at the source of truth.

1324
00:49:38,760 --> 00:49:40,360
That knowledge compounds over time.

1325
00:49:40,360 --> 00:49:42,480
If your team builds Graph fluency this year,

1326
00:49:42,480 --> 00:49:44,800
they will be ready to govern AI agents next year.

1327
00:49:44,800 --> 00:49:45,800
The patterns are the same.

1328
00:49:45,800 --> 00:49:47,160
The logic transfers directly.

1329
00:49:47,160 --> 00:49:49,280
The admins who wait aren't just standing still.

1330
00:49:49,280 --> 00:49:51,720
They are falling behind a curve that is accelerating.

1331
00:49:51,720 --> 00:49:53,320
More and more critical capabilities

1332
00:49:53,320 --> 00:49:55,320
are surfacing exclusively through Graph,

1333
00:49:55,320 --> 00:49:56,520
leaving the portal behind.

1334
00:49:56,520 --> 00:49:59,120
Skills matter because the future is being built right now.

1335
00:49:59,120 --> 00:50:00,400
And that brings us to the deadlines

1336
00:50:00,400 --> 00:50:02,080
you can't afford to ignore.

1337
00:50:02,080 --> 00:50:05,440
The ticking clock, critical deadlines and forced migrations.

1338
00:50:05,440 --> 00:50:07,920
The strategic reasons to move to Graph are clear,

1339
00:50:07,920 --> 00:50:10,080
but there is a much more urgent reason to act.

1340
00:50:10,080 --> 00:50:11,680
It has nothing to do with your career

1341
00:50:11,680 --> 00:50:13,480
or your competitive advantage.

1342
00:50:13,480 --> 00:50:15,320
Microsoft has set hard deadlines

1343
00:50:15,320 --> 00:50:17,440
that will break your environment if you miss them.

1344
00:50:17,440 --> 00:50:20,480
Not degrade your performance, not create an inconvenience.

1345
00:50:20,480 --> 00:50:21,640
They will break your tools.

1346
00:50:21,640 --> 00:50:24,040
The first major deadline has already passed.

1347
00:50:24,040 --> 00:50:27,760
On June 30th, 2025, Azure AD Graph was officially retired.

1348
00:50:27,760 --> 00:50:29,640
This wasn't a soft retirement,

1349
00:50:29,640 --> 00:50:32,240
where the documentation just stops getting updates.

1350
00:50:32,240 --> 00:50:36,160
It was a hard cutoff, where API calls stopped functioning entirely.

1351
00:50:36,160 --> 00:50:39,120
If you had an application or a script built on the old system

1352
00:50:39,120 --> 00:50:42,960
that didn't migrate to Microsoft Graph by that date, it died.

1353
00:50:42,960 --> 00:50:44,760
Microsoft even ran planned outage tests

1354
00:50:44,760 --> 00:50:46,520
throughout the summer of 2025

1355
00:50:46,520 --> 00:50:48,480
to help teams find hidden dependencies.

1356
00:50:48,480 --> 00:50:50,120
Those tests were a warning.

1357
00:50:50,120 --> 00:50:51,680
The permanent shutdown was not.

1358
00:50:51,680 --> 00:50:54,000
The legacy-power shell modules followed the same path.

1359
00:50:54,000 --> 00:50:56,960
Azure AD and Amazon line were deprecated back in March of 2024.

1360
00:50:56,960 --> 00:50:59,440
They only kept working because of a back-end grace period

1361
00:50:59,440 --> 00:51:01,720
that ended when the API itself was retired.

1362
00:51:01,720 --> 00:51:03,960
If you are still trying to run provisioning scripts

1363
00:51:03,960 --> 00:51:06,960
against those modules today, you aren't on borrowed time.

1364
00:51:06,960 --> 00:51:07,960
You're running on nothing.

1365
00:51:07,960 --> 00:51:09,640
The next big hit is the Graph CLI,

1366
00:51:09,640 --> 00:51:12,040
which retires on August 28th, 2026.

1367
00:51:12,040 --> 00:51:14,160
This one is going to catch a lot of people of God.

1368
00:51:14,160 --> 00:51:16,440
The Graph CLI felt like the modern choice.

1369
00:51:16,440 --> 00:51:19,440
It used current auth patterns and it called the Graph API.

1370
00:51:19,440 --> 00:51:21,120
It seemed like the right direction to go.

1371
00:51:21,120 --> 00:51:23,280
But Microsoft has decided that the official target

1372
00:51:23,280 --> 00:51:24,880
is the PowerShell SDK.

1373
00:51:24,880 --> 00:51:26,800
The retirement for the CLI is hard.

1374
00:51:26,800 --> 00:51:28,120
There is no extended access.

1375
00:51:28,120 --> 00:51:29,800
If your automation relies on it,

1376
00:51:29,800 --> 00:51:32,680
you have until August of 2026 to move

1377
00:51:32,680 --> 00:51:34,720
and there is no room for negotiation.

1378
00:51:34,720 --> 00:51:37,440
Then comes December 31st, 2026.

1379
00:51:37,440 --> 00:51:39,880
This is the date for the Mail Advanced permissions change.

1380
00:51:39,880 --> 00:51:42,360
Right now, the standard Mail Read Write permission

1381
00:51:42,360 --> 00:51:45,120
lets apps update a lot of different message properties.

1382
00:51:45,120 --> 00:51:47,200
After the end of 2026, that changes.

1383
00:51:47,200 --> 00:51:48,840
If an app needs to update sensitive fields

1384
00:51:48,840 --> 00:51:51,120
like the subject line, the body, or the recipients,

1385
00:51:51,120 --> 00:51:54,560
it will require the new Mail Advanced permission family.

1386
00:51:54,560 --> 00:51:56,840
That family requires mandatory admin consent.

1387
00:51:56,840 --> 00:51:59,040
Applications that try to modify email properties

1388
00:51:59,040 --> 00:52:01,680
without that explicit permission will simply stop working.

1389
00:52:01,680 --> 00:52:03,240
They won't give you a helpful warning.

1390
00:52:03,240 --> 00:52:04,920
They will just throw four to three errors

1391
00:52:04,920 --> 00:52:06,880
that could take your team days to diagnose

1392
00:52:06,880 --> 00:52:08,440
if you aren't prepared for the shift.

1393
00:52:08,440 --> 00:52:10,760
We're also seeing a broader secure by default move

1394
00:52:10,760 --> 00:52:12,200
in mid-2026.

1395
00:52:12,200 --> 00:52:14,440
Microsoft is shifting the default policy

1396
00:52:14,440 --> 00:52:16,240
so that many exchange related permissions

1397
00:52:16,240 --> 00:52:18,600
will require admin consent by default.

1398
00:52:18,600 --> 00:52:20,120
If you have apps that relied on users

1399
00:52:20,120 --> 00:52:21,600
consenting for themselves,

1400
00:52:21,600 --> 00:52:23,880
those apps will break the moment the policy flips.

1401
00:52:23,880 --> 00:52:25,640
The pattern here is always the same.

1402
00:52:25,640 --> 00:52:27,080
Microsoft makes an announcement.

1403
00:52:27,080 --> 00:52:28,800
Organizations take a note of it.

1404
00:52:28,800 --> 00:52:29,800
Then the deadline arrives

1405
00:52:29,800 --> 00:52:31,640
and the emergency scramble begins.

1406
00:52:31,640 --> 00:52:32,920
The teams that treated these dates

1407
00:52:32,920 --> 00:52:34,600
as planning inputs are fine.

1408
00:52:34,600 --> 00:52:37,160
The teams that treated them as problems for later

1409
00:52:37,160 --> 00:52:39,480
are now rebuilding their entire integration stack

1410
00:52:39,480 --> 00:52:40,640
under extreme pressure.

1411
00:52:40,640 --> 00:52:42,400
These are not optional upgrades.

1412
00:52:42,400 --> 00:52:43,520
The platform is moving forward

1413
00:52:43,520 --> 00:52:45,160
and it is dropping backward compatibility

1414
00:52:45,160 --> 00:52:46,960
at very specific points in time.

1415
00:52:46,960 --> 00:52:48,080
The calendar is public.

1416
00:52:48,080 --> 00:52:50,000
The only variable is whether or not you are ready

1417
00:52:50,000 --> 00:52:51,120
when the date arrives.

1418
00:52:51,120 --> 00:52:52,800
Deadlines create urgency.

1419
00:52:52,800 --> 00:52:54,440
So let's talk about how you actually build

1420
00:52:54,440 --> 00:52:56,200
a real graph strategy.

1421
00:52:56,200 --> 00:52:58,320
Building your graph strategy, the roadmap.

1422
00:52:58,320 --> 00:53:00,920
Strategy without a sequence is just intention.

1423
00:53:00,920 --> 00:53:03,040
Organizations that actually close the gap

1424
00:53:03,040 --> 00:53:04,720
move through a specific order.

1425
00:53:04,720 --> 00:53:06,480
They don't just do automation.

1426
00:53:06,480 --> 00:53:07,320
They build it.

1427
00:53:07,320 --> 00:53:08,680
Phase one is discovery and baseline.

1428
00:53:08,680 --> 00:53:10,360
This takes two weeks if you move with purpose.

1429
00:53:10,360 --> 00:53:12,160
The goal isn't to fix anything yet.

1430
00:53:12,160 --> 00:53:14,600
It's to see clearly you need to find the friction.

1431
00:53:14,600 --> 00:53:17,440
What processes in your environment are still manual?

1432
00:53:17,440 --> 00:53:19,000
Where are humans clicking through portals

1433
00:53:19,000 --> 00:53:21,280
to do work that a script could do in seconds?

1434
00:53:21,280 --> 00:53:24,200
Map it, quantify it, calculate the time per task

1435
00:53:24,200 --> 00:53:25,680
and the frequency per month.

1436
00:53:25,680 --> 00:53:27,280
That arithmetic tells you where automation

1437
00:53:27,280 --> 00:53:28,760
delivers the fastest return

1438
00:53:28,760 --> 00:53:31,040
and it prevents you from wasting time on edge cases

1439
00:53:31,040 --> 00:53:31,960
that don't matter.

1440
00:53:31,960 --> 00:53:34,160
Simultaneously, you need to run permission discovery.

1441
00:53:34,160 --> 00:53:36,360
Use graph to see who actually has access.

1442
00:53:36,360 --> 00:53:38,560
Enumerate which sites have broad membership

1443
00:53:38,560 --> 00:53:40,720
and which service principles hold permissions

1444
00:53:40,720 --> 00:53:42,560
that haven't been used in 90 days.

1445
00:53:42,560 --> 00:53:45,000
Look for app registrations that have accumulated scopes

1446
00:53:45,000 --> 00:53:46,400
well beyond their original purpose.

1447
00:53:46,400 --> 00:53:47,520
You're not remediating yet.

1448
00:53:47,520 --> 00:53:49,560
You're establishing the before state.

1449
00:53:49,560 --> 00:53:51,280
This baseline turns future improvements

1450
00:53:51,280 --> 00:53:52,760
from stories into evidence.

1451
00:53:52,760 --> 00:53:54,800
Organizations that skip this step end up

1452
00:53:54,800 --> 00:53:56,640
unable to prove ROI later

1453
00:53:56,640 --> 00:53:59,040
because they have no reference point for comparison.

1454
00:53:59,040 --> 00:54:01,160
Phase two is the pilot running from week three

1455
00:54:01,160 --> 00:54:02,320
through week eight.

1456
00:54:02,320 --> 00:54:04,280
The selection criteria for your first project

1457
00:54:04,280 --> 00:54:06,600
matter more than the technical complexity.

1458
00:54:06,600 --> 00:54:09,760
You want something high impact, low risk and measurable.

1459
00:54:09,760 --> 00:54:12,520
License reporting is a reliable starting point.

1460
00:54:12,520 --> 00:54:14,360
It touches almost no right operations,

1461
00:54:14,360 --> 00:54:16,120
produces immediate value

1462
00:54:16,120 --> 00:54:18,000
and gives your team hands on experience

1463
00:54:18,000 --> 00:54:19,400
with the graph reporting API

1464
00:54:19,400 --> 00:54:21,680
before you're dealing with production accounts.

1465
00:54:21,680 --> 00:54:23,600
User provisioning for a specific department

1466
00:54:23,600 --> 00:54:25,040
is another strong candidate.

1467
00:54:25,040 --> 00:54:27,840
It has a bounded scope, clear success criteria

1468
00:54:27,840 --> 00:54:30,560
and a stakeholder who will actually notice the improvement,

1469
00:54:30,560 --> 00:54:32,240
build it, and then, from day one.

1470
00:54:32,240 --> 00:54:34,080
This isn't the best practice to apply later.

1471
00:54:34,080 --> 00:54:35,360
It's the structural constraint

1472
00:54:35,360 --> 00:54:38,560
that shapes every script you write from this point forward.

1473
00:54:38,560 --> 00:54:40,560
Measure the performance before you deploy.

1474
00:54:40,560 --> 00:54:43,840
Track the time per task and the error rate from manual processes.

1475
00:54:43,840 --> 00:54:45,240
Calculate the cost of license waste

1476
00:54:45,240 --> 00:54:46,440
before the cleaner runs.

1477
00:54:46,440 --> 00:54:48,720
Two weeks after deployment, measure those same things again,

1478
00:54:48,720 --> 00:54:49,960
document the delta.

1479
00:54:49,960 --> 00:54:52,080
That documentation is your case for more investment.

1480
00:54:52,080 --> 00:54:53,360
It's the institutional memory

1481
00:54:53,360 --> 00:54:54,760
that justifies the next phase

1482
00:54:54,760 --> 00:54:56,440
when the budget conversation comes.

1483
00:54:56,440 --> 00:54:58,240
Phase three is the governance framework

1484
00:54:58,240 --> 00:55:00,120
covering weeks nine through 16.

1485
00:55:00,120 --> 00:55:01,880
This is where the work becomes infrastructure

1486
00:55:01,880 --> 00:55:03,960
rather than just a series of projects.

1487
00:55:03,960 --> 00:55:05,760
Naming conventions get codified.

1488
00:55:05,760 --> 00:55:07,560
Retention schedules get scripted.

1489
00:55:07,560 --> 00:55:09,160
DLP policies get versioned.

1490
00:55:09,160 --> 00:55:11,000
The permission review cadence gets formalized.

1491
00:55:11,000 --> 00:55:13,360
You move to monthly reviews for high-risk applications

1492
00:55:13,360 --> 00:55:15,440
and quarterly reviews for routine governance.

1493
00:55:15,440 --> 00:55:17,360
These reviews run as automated reports

1494
00:55:17,360 --> 00:55:18,720
rather than manual audits.

1495
00:55:18,720 --> 00:55:21,400
Build dashboards that pull graph data on a schedule.

1496
00:55:21,400 --> 00:55:23,720
Surface the metrics that matter to different audiences.

1497
00:55:23,720 --> 00:55:25,880
The CISO wants to know about security posture,

1498
00:55:25,880 --> 00:55:28,240
the CFO wants to know about license efficiency

1499
00:55:28,240 --> 00:55:30,440
and the CIO wants to see adoption curves.

1500
00:55:30,440 --> 00:55:33,440
This is also when you establish your CICD pipeline

1501
00:55:33,440 --> 00:55:35,080
for configuration changes.

1502
00:55:35,080 --> 00:55:37,960
Any policy modification must go through review and testing

1503
00:55:37,960 --> 00:55:39,520
before it touches production.

1504
00:55:39,520 --> 00:55:42,040
This discipline protects you from the category of incident

1505
00:55:42,040 --> 00:55:43,920
that's hardest to explain to leadership

1506
00:55:43,920 --> 00:55:46,520
and IT generated outage caused by a change

1507
00:55:46,520 --> 00:55:47,840
that wasn't validated.

1508
00:55:47,840 --> 00:55:49,560
Phase four has no end date.

1509
00:55:49,560 --> 00:55:51,000
It's the ongoing operating model.

1510
00:55:51,000 --> 00:55:53,920
Expand automation as your team's graph fluency deepens,

1511
00:55:53,920 --> 00:55:56,520
monitor throttling metrics to catch performance patterns

1512
00:55:56,520 --> 00:55:58,560
before they become operational problems,

1513
00:55:58,560 --> 00:56:00,880
build feedback loops between your automation outcomes

1514
00:56:00,880 --> 00:56:02,440
and the policies that drive them.

1515
00:56:02,440 --> 00:56:05,200
When a new Microsoft 365 capability launches,

1516
00:56:05,200 --> 00:56:06,520
the platform moves fast enough

1517
00:56:06,520 --> 00:56:08,920
that something significant lands every quarter.

1518
00:56:08,920 --> 00:56:10,560
Your team's first question should be

1519
00:56:10,560 --> 00:56:12,320
which graph endpoints expose it

1520
00:56:12,320 --> 00:56:14,080
and what automation patterns it enables.

1521
00:56:14,080 --> 00:56:16,200
The realistic timeline for mature infrastructure

1522
00:56:16,200 --> 00:56:17,440
is six to 12 months.

1523
00:56:17,440 --> 00:56:19,680
It takes that long not because the pieces are complex

1524
00:56:19,680 --> 00:56:21,520
but because building organizational discipline

1525
00:56:21,520 --> 00:56:23,920
around code review and monitoring takes time.

1526
00:56:23,920 --> 00:56:25,040
Start the clock now.

1527
00:56:25,040 --> 00:56:27,400
Every week that passes before the first script runs

1528
00:56:27,400 --> 00:56:29,600
is a week that doesn't count towards your progress.

1529
00:56:29,600 --> 00:56:31,640
Authentication patterns, certificates,

1530
00:56:31,640 --> 00:56:33,400
managed identities and secrets.

1531
00:56:33,400 --> 00:56:35,680
Authentication is where security intentions meet

1532
00:56:35,680 --> 00:56:37,000
engineering reality.

1533
00:56:37,000 --> 00:56:39,800
The permission model defines what an application can do.

1534
00:56:39,800 --> 00:56:41,800
Authentication determines whether the application

1535
00:56:41,800 --> 00:56:43,600
can prove it's authorized to do it.

1536
00:56:43,600 --> 00:56:46,240
Getting this wrong doesn't just create a security gap.

1537
00:56:46,240 --> 00:56:47,880
It creates a gap that looks closed

1538
00:56:47,880 --> 00:56:49,720
until a credential is compromised.

1539
00:56:49,720 --> 00:56:51,680
At that point, the blast radius is determined

1540
00:56:51,680 --> 00:56:53,920
by how broadly that credential was trusted.

1541
00:56:53,920 --> 00:56:55,560
Client secrets are where most teams start

1542
00:56:55,560 --> 00:56:56,720
because they're simple.

1543
00:56:56,720 --> 00:56:59,320
You generate a value, store it and pass it in the request.

1544
00:56:59,320 --> 00:57:01,200
That simplicity is exactly the problem.

1545
00:57:01,200 --> 00:57:02,960
A client secret is just a password.

1546
00:57:02,960 --> 00:57:04,920
It has the same failure modes as any password.

1547
00:57:04,920 --> 00:57:06,760
It can be committed to a repository,

1548
00:57:06,760 --> 00:57:09,360
logged in a pipeline, or stored in a config file

1549
00:57:09,360 --> 00:57:10,920
with bad access controls.

1550
00:57:10,920 --> 00:57:12,080
Secrets expire.

1551
00:57:12,080 --> 00:57:14,000
This creates pressure to extend their lifetime

1552
00:57:14,000 --> 00:57:15,440
rather than rotating them properly.

1553
00:57:15,440 --> 00:57:16,960
When a secret is compromised,

1554
00:57:16,960 --> 00:57:18,960
the exposure window extends all the way back

1555
00:57:18,960 --> 00:57:22,160
to the last rotation, not just to when the breach happened.

1556
00:57:22,160 --> 00:57:24,720
The rotation discipline required to make secrets safe

1557
00:57:24,720 --> 00:57:26,040
is operationally heavy.

1558
00:57:26,040 --> 00:57:27,640
Most organizations don't maintain it.

1559
00:57:27,640 --> 00:57:29,880
Secrets quietly accumulate long lifetimes.

1560
00:57:29,880 --> 00:57:31,440
The ones that should expire in 90 days

1561
00:57:31,440 --> 00:57:32,600
get extended to a year.

1562
00:57:32,600 --> 00:57:33,960
The ones that should have been rotated

1563
00:57:33,960 --> 00:57:35,400
after a personnel change weren't

1564
00:57:35,400 --> 00:57:37,120
because nobody owns the process.

1565
00:57:37,120 --> 00:57:39,880
As your key vault is mandatory if you use client secrets,

1566
00:57:39,880 --> 00:57:42,200
it provides rotation policies and audit logs

1567
00:57:42,200 --> 00:57:44,120
that make the exposure window visible,

1568
00:57:44,120 --> 00:57:46,400
but key vault doesn't eliminate the fundamental weakness.

1569
00:57:46,400 --> 00:57:47,360
It just manages it.

1570
00:57:47,360 --> 00:57:49,520
Certificates raise the bar significantly.

1571
00:57:49,520 --> 00:57:51,320
Certificate-based authentication replaces

1572
00:57:51,320 --> 00:57:53,680
the shared secret with an asymmetric key pair.

1573
00:57:53,680 --> 00:57:55,600
Your automation holds the private key

1574
00:57:55,600 --> 00:57:57,920
and Microsoft validates the public key

1575
00:57:57,920 --> 00:57:59,800
registered against your application.

1576
00:57:59,800 --> 00:58:01,560
The private key never leaves your environment.

1577
00:58:01,560 --> 00:58:04,160
It can't be guest or brute force through the API.

1578
00:58:04,160 --> 00:58:07,040
Certificate rotation is more complex than secret rotation,

1579
00:58:07,040 --> 00:58:09,480
but the security improvement justifies the effort.

1580
00:58:09,480 --> 00:58:11,560
If your provisioning scripts or governance workflows

1581
00:58:11,560 --> 00:58:12,560
run with user.

1582
00:58:12,560 --> 00:58:13,800
Read write all or broader,

1583
00:58:13,800 --> 00:58:16,160
certificates are the minimum acceptable pattern.

1584
00:58:16,160 --> 00:58:17,760
Managed identities are the right answer

1585
00:58:17,760 --> 00:58:19,480
for automation running inside Azure.

1586
00:58:19,480 --> 00:58:21,280
When your runbook or function runs in Azure,

1587
00:58:21,280 --> 00:58:23,920
it can assume an identity assigned to the resource.

1588
00:58:23,920 --> 00:58:25,360
There are no credentials to manage,

1589
00:58:25,360 --> 00:58:28,040
no secrets to rotate and no certificates to track.

1590
00:58:28,040 --> 00:58:30,400
The identity is tied to the Azure resource itself.

1591
00:58:30,400 --> 00:58:31,960
When the resource is decommissioned,

1592
00:58:31,960 --> 00:58:33,440
the identity goes with it.

1593
00:58:33,440 --> 00:58:35,920
You can't accidentally leave a managed identity active

1594
00:58:35,920 --> 00:58:38,760
after the workload it served is retired.

1595
00:58:38,760 --> 00:58:41,920
For graph automation running in Azure Automation or Functions,

1596
00:58:41,920 --> 00:58:44,440
managed identities should be the default choice.

1597
00:58:44,440 --> 00:58:47,440
Using a client secret should require documented justification.

1598
00:58:47,440 --> 00:58:50,000
Understanding the OAuth 2.0 flow matters

1599
00:58:50,000 --> 00:58:52,880
because the flow determines what the token represents.

1600
00:58:52,880 --> 00:58:54,960
The client credentials flow produces a token

1601
00:58:54,960 --> 00:58:57,880
that acts with the full scope of the application's permissions.

1602
00:58:57,880 --> 00:58:59,920
The authorization code flow produces tokens

1603
00:58:59,920 --> 00:59:01,760
scoped to a specific user's rights.

1604
00:59:01,760 --> 00:59:03,840
Continuous access evaluation means

1605
00:59:03,840 --> 00:59:06,000
graph can revoke tokens in real time

1606
00:59:06,000 --> 00:59:07,640
when risk signals change.

1607
00:59:07,640 --> 00:59:10,000
If a user account is disabled or location anomaly

1608
00:59:10,000 --> 00:59:11,960
is detected, the access stops.

1609
00:59:11,960 --> 00:59:13,920
Shorter token lifetimes reduce the window

1610
00:59:13,920 --> 00:59:16,080
between a risk event and access termination.

1611
00:59:16,080 --> 00:59:17,600
The default one hour lifetime

1612
00:59:17,600 --> 00:59:20,080
is a balance between performance and security,

1613
00:59:20,080 --> 00:59:21,840
not an optimization target.

1614
00:59:21,840 --> 00:59:22,920
The summary is direct.

1615
00:59:22,920 --> 00:59:25,600
Use certificates or managed identities for production.

1616
00:59:25,600 --> 00:59:28,640
Use secrets only with key vault and strict rotation policies.

1617
00:59:28,640 --> 00:59:30,600
Keep token lifetimes short for anything

1618
00:59:30,600 --> 00:59:32,560
touching sensitive scopes.

1619
00:59:32,560 --> 00:59:35,160
Operational excellence, monitoring, alerting,

1620
00:59:35,160 --> 00:59:36,680
and incident response.

1621
00:59:36,680 --> 00:59:38,320
Authentication holds the door.

1622
00:59:38,320 --> 00:59:40,320
Governance defines the rules.

1623
00:59:40,320 --> 00:59:42,360
But neither matters if nobody is watching what happens

1624
00:59:42,360 --> 00:59:44,520
once your automation is running in production.

1625
00:59:44,520 --> 00:59:46,640
Operational excellence in graph driven environments

1626
00:59:46,640 --> 00:59:48,680
starts with a question most teams never ask

1627
00:59:48,680 --> 00:59:49,720
until something breaks.

1628
00:59:49,720 --> 00:59:51,760
What is your automation actually doing right now?

1629
00:59:51,760 --> 00:59:53,000
Not what it's supposed to do,

1630
00:59:53,000 --> 00:59:54,600
not what it did last week during testing.

1631
00:59:54,600 --> 00:59:56,400
What is it doing at this moment?

1632
00:59:56,400 --> 00:59:57,800
Against your life tenant.

1633
00:59:57,800 --> 00:59:59,920
Graph activity logs reach general availability

1634
00:59:59,920 --> 01:00:01,280
in April of 2024.

1635
01:00:01,280 --> 01:00:02,520
And they answer that question

1636
01:00:02,520 --> 01:00:05,280
with a precision that simply didn't exist before.

1637
01:00:05,280 --> 01:00:07,720
Every HTTP request made to Microsoft graph

1638
01:00:07,720 --> 01:00:10,520
by every application in your tenant gets recorded.

1639
01:00:10,520 --> 01:00:12,600
The endpoint called, the identity that called it,

1640
01:00:12,600 --> 01:00:15,800
the response code returned, the timestamp.

1641
01:00:15,800 --> 01:00:17,640
That log stream is the diagnostic layer

1642
01:00:17,640 --> 01:00:19,520
underneath your entire automation stack.

1643
01:00:19,520 --> 01:00:22,200
The immediate operational use is throttling detection.

1644
01:00:22,200 --> 01:00:25,000
When your script start hitting 429 responses,

1645
01:00:25,000 --> 01:00:27,560
the activity logs show you exactly which application

1646
01:00:27,560 --> 01:00:30,600
is generating the load, which endpoints its hammering

1647
01:00:30,600 --> 01:00:32,000
and at what frequency.

1648
01:00:32,000 --> 01:00:33,600
You can see the noisy neighbor problem

1649
01:00:33,600 --> 01:00:36,040
before it escalates from degraded performance

1650
01:00:36,040 --> 01:00:37,000
to failed operations.

1651
01:00:37,000 --> 01:00:39,400
Because you have this data, you can adjust chunk sizes,

1652
01:00:39,400 --> 01:00:41,520
introduce batching, or spread workload

1653
01:00:41,520 --> 01:00:44,920
across different execution windows based on actual telemetry

1654
01:00:44,920 --> 01:00:46,240
rather than speculation.

1655
01:00:46,240 --> 01:00:49,280
Audit logs serve a different but equally critical function

1656
01:00:49,280 --> 01:00:51,800
where activity logs tell you what applications did,

1657
01:00:51,800 --> 01:00:54,520
audit logs tell you what administrators and users did,

1658
01:00:54,520 --> 01:00:56,840
who changed a conditional access policy and when.

1659
01:00:56,840 --> 01:00:58,720
Which account added an application permission

1660
01:00:58,720 --> 01:01:00,520
that wasn't in the approved baseline,

1661
01:01:00,520 --> 01:01:03,120
which admin removed a user from a privileged role

1662
01:01:03,120 --> 01:01:04,720
at 2am on a Sunday.

1663
01:01:04,720 --> 01:01:07,320
This is the evidence trail that governance frameworks depend on,

1664
01:01:07,320 --> 01:01:09,560
and it's the data that incident response teams reach

1665
01:01:09,560 --> 01:01:11,440
for first when something goes wrong.

1666
01:01:11,440 --> 01:01:14,280
Feeding audit logs into a CM, like Microsoft Sentinel.

1667
01:01:14,280 --> 01:01:15,720
Creates the correlation capability

1668
01:01:15,720 --> 01:01:17,880
that turns individual events into patents.

1669
01:01:17,880 --> 01:01:19,920
A single unusual permission grant is noise.

1670
01:01:19,920 --> 01:01:22,160
Three unusual permission grants from the same source

1671
01:01:22,160 --> 01:01:25,400
in the same hour is a signal that deserves attention immediately.

1672
01:01:25,400 --> 01:01:27,840
Alerting needs to be specific to be useful.

1673
01:01:27,840 --> 01:01:29,600
Generic, something happened alerts,

1674
01:01:29,600 --> 01:01:31,640
produce alert fatigue and train teams

1675
01:01:31,640 --> 01:01:33,320
to ignore the notification system.

1676
01:01:33,320 --> 01:01:35,240
Effective alerting is targeted.

1677
01:01:35,240 --> 01:01:37,240
Bulk deletions above a defined threshold,

1678
01:01:37,240 --> 01:01:40,000
new admin consent grants outside business hours.

1679
01:01:40,000 --> 01:01:41,560
Service principles gaining permissions

1680
01:01:41,560 --> 01:01:43,920
that weren't part of their registered baseline.

1681
01:01:43,920 --> 01:01:46,480
Sign-ins from accounts that should be service only.

1682
01:01:46,480 --> 01:01:49,520
These conditions are buildable as graph-backed detection rules.

1683
01:01:49,520 --> 01:01:50,920
The logic runs on a schedule,

1684
01:01:50,920 --> 01:01:53,360
compares current state against expected state,

1685
01:01:53,360 --> 01:01:55,840
and fires only when the deviation is real.

1686
01:01:55,840 --> 01:01:57,360
Error tracking inside your automation

1687
01:01:57,360 --> 01:01:59,080
deserves the same rigor as error tracking

1688
01:01:59,080 --> 01:02:00,960
in any production software system.

1689
01:02:00,960 --> 01:02:03,080
Transient failures, like a 503

1690
01:02:03,080 --> 01:02:04,680
from a briefly unavailable endpoint

1691
01:02:04,680 --> 01:02:06,680
or a timeout during a large query,

1692
01:02:06,680 --> 01:02:09,240
are expected and recoverable with proper retry logic.

1693
01:02:09,240 --> 01:02:11,040
Persistent failures are different.

1694
01:02:11,040 --> 01:02:13,760
Repeated 403s indicating a permission change

1695
01:02:13,760 --> 01:02:16,520
or consistent 400s indicating a malformed request

1696
01:02:16,520 --> 01:02:18,560
after an API update are signals

1697
01:02:18,560 --> 01:02:20,480
that something structural needs attention.

1698
01:02:20,480 --> 01:02:23,480
A logging pattern that distinguishes these two categories

1699
01:02:23,480 --> 01:02:25,480
turns your error stream from noise

1700
01:02:25,480 --> 01:02:27,000
into an operational dashboard.

1701
01:02:27,000 --> 01:02:29,000
You see which workflows are running cleanly,

1702
01:02:29,000 --> 01:02:31,200
which ones need a retry policy adjustment,

1703
01:02:31,200 --> 01:02:33,120
and which ones need a human to investigate

1704
01:02:33,120 --> 01:02:34,920
why they're consistently failing.

1705
01:02:34,920 --> 01:02:37,000
Runbooks give your team a structured response

1706
01:02:37,000 --> 01:02:38,160
when incidents do occur.

1707
01:02:38,160 --> 01:02:41,320
Not every alert needs an investigation from first principles.

1708
01:02:41,320 --> 01:02:43,480
A documented runbook for common scenarios.

1709
01:02:43,480 --> 01:02:46,320
Like throttling events, certificate expiry warnings

1710
01:02:46,320 --> 01:02:48,120
or permission drift detections.

1711
01:02:48,120 --> 01:02:50,400
Means the on-call team follows a proven process

1712
01:02:50,400 --> 01:02:53,040
rather than improvising under pressure at 3am.

1713
01:02:53,040 --> 01:02:54,760
Blameless post mortems close the loop.

1714
01:02:54,760 --> 01:02:56,240
When something fails in production,

1715
01:02:56,240 --> 01:02:58,480
the conversation should end with updated runbooks,

1716
01:02:58,480 --> 01:03:00,000
improved alerting thresholds,

1717
01:03:00,000 --> 01:03:02,640
and better test coverage for the failure mode that surfaced.

1718
01:03:02,640 --> 01:03:04,680
It shouldn't end with someone being held responsible

1719
01:03:04,680 --> 01:03:07,120
for a gap the process itself should have caught.

1720
01:03:07,120 --> 01:03:08,880
Operations keep systems running.

1721
01:03:08,880 --> 01:03:10,800
Now let's talk about the future state.

1722
01:03:10,800 --> 01:03:13,120
The future of M365 administration,

1723
01:03:13,120 --> 01:03:15,280
2027 and beyond.

1724
01:03:15,280 --> 01:03:19,040
Picture the role of M365 administrator in 2027.

1725
01:03:19,040 --> 01:03:20,080
Not as it exists today,

1726
01:03:20,080 --> 01:03:22,400
reactive ticket-driven.portal-dependent,

1727
01:03:22,400 --> 01:03:23,920
but as it's being actively redefined

1728
01:03:23,920 --> 01:03:25,520
by the organization's already operating

1729
01:03:25,520 --> 01:03:27,680
at the frontier of what graph makes possible.

1730
01:03:27,680 --> 01:03:29,040
The portal doesn't disappear.

1731
01:03:29,040 --> 01:03:33,360
It persists as the interface for simple occasional tasks,

1732
01:03:33,360 --> 01:03:35,960
like checking a setting, verifying a configuration,

1733
01:03:35,960 --> 01:03:38,480
or investigating a specific account during an incident.

1734
01:03:38,480 --> 01:03:40,600
But serious work happens at the API layer,

1735
01:03:40,600 --> 01:03:43,520
the work that shapes how an organization operates.

1736
01:03:43,520 --> 01:03:46,320
Configuration is declared in code and deployed through pipelines.

1737
01:03:46,320 --> 01:03:48,200
Governance is enforced by automation

1738
01:03:48,200 --> 01:03:50,040
and validated continuously.

1739
01:03:50,040 --> 01:03:51,880
Security posture is monitored by systems

1740
01:03:51,880 --> 01:03:54,040
that alert on deviations rather than humans

1741
01:03:54,040 --> 01:03:55,280
who notice them eventually.

1742
01:03:55,280 --> 01:03:56,520
This isn't a prediction.

1743
01:03:56,520 --> 01:03:59,440
It's a description of infrastructure already in production

1744
01:03:59,440 --> 01:04:02,040
at organizations that started three or four years ago

1745
01:04:02,040 --> 01:04:04,240
and have been compounding that advantage since.

1746
01:04:04,240 --> 01:04:06,480
The question isn't whether this future arrives.

1747
01:04:06,480 --> 01:04:08,920
It's whether your organization is building toward it,

1748
01:04:08,920 --> 01:04:11,560
or inheriting the gap when it does.

1749
01:04:11,560 --> 01:04:14,600
AI and agents will be the primary consumers of tenant data

1750
01:04:14,600 --> 01:04:17,520
within that timeline, not users browsing document libraries,

1751
01:04:17,520 --> 01:04:18,960
not admins running reports,

1752
01:04:18,960 --> 01:04:21,520
but autonomous systems making thousands of graph calls

1753
01:04:21,520 --> 01:04:23,960
per hour to ground decisions, execute workflows,

1754
01:04:23,960 --> 01:04:25,800
and coordinate across services.

1755
01:04:25,800 --> 01:04:27,520
The governance implications of that shift

1756
01:04:27,520 --> 01:04:29,160
dwarf anything we currently associate

1757
01:04:29,160 --> 01:04:30,880
with application permission management.

1758
01:04:30,880 --> 01:04:32,760
Your tenant will be interacting with systems

1759
01:04:32,760 --> 01:04:34,960
that act faster than any human led review process

1760
01:04:34,960 --> 01:04:36,680
contract, which means the controls

1761
01:04:36,680 --> 01:04:38,800
have to be structural rather than procedural.

1762
01:04:38,800 --> 01:04:41,680
Policy as code isn't a modernization project for 2027.

1763
01:04:41,680 --> 01:04:44,040
It's the baseline expectation for any organization

1764
01:04:44,040 --> 01:04:45,640
that wants to deploy AI agents

1765
01:04:45,640 --> 01:04:47,400
without creating ungovernable risk.

1766
01:04:47,400 --> 01:04:50,120
The shift in how administration gets valued reflects this.

1767
01:04:50,120 --> 01:04:52,280
Systems thinking becomes the core competency

1768
01:04:52,280 --> 01:04:54,600
that separates architects from operators.

1769
01:04:54,600 --> 01:04:57,240
The ability to reason about how identity, permissions,

1770
01:04:57,240 --> 01:05:00,440
data flows, and automation patterns interact at scale.

1771
01:05:00,440 --> 01:05:01,920
Knowing which portal blade contains

1772
01:05:01,920 --> 01:05:03,400
which setting has diminishing value

1773
01:05:03,400 --> 01:05:05,800
as more of those settings get managed programmatically.

1774
01:05:05,800 --> 01:05:08,360
Understanding the data model underneath the portal,

1775
01:05:08,360 --> 01:05:10,120
the permission boundaries that constrain

1776
01:05:10,120 --> 01:05:12,560
what automation can reach, and the performance patterns

1777
01:05:12,560 --> 01:05:15,320
that determine whether large-scale operations succeed

1778
01:05:15,320 --> 01:05:16,240
or throttle.

1779
01:05:16,240 --> 01:05:17,960
That knowledge compounds in a way that GUI

1780
01:05:17,960 --> 01:05:19,200
familiarity never could.

1781
01:05:19,200 --> 01:05:20,760
Automation stops being exceptional

1782
01:05:20,760 --> 01:05:22,640
and becomes the expected baseline.

1783
01:05:22,640 --> 01:05:24,040
The question organizations ask

1784
01:05:24,040 --> 01:05:25,920
about any repeatable administrative process

1785
01:05:25,920 --> 01:05:28,000
won't be, should we automate this?

1786
01:05:28,000 --> 01:05:30,800
It'll be, why hasn't this been automated yet?

1787
01:05:30,800 --> 01:05:32,640
The organizations that built-identbitant,

1788
01:05:32,640 --> 01:05:34,760
versioned, monitored automation infrastructure

1789
01:05:34,760 --> 01:05:37,160
over the next 18 months are the ones positioned

1790
01:05:37,160 --> 01:05:39,120
to answer that question confidently.

1791
01:05:39,120 --> 01:05:41,000
The ones that waited are rebuilding under pressure

1792
01:05:41,000 --> 01:05:43,440
while simultaneously trying to govern AI systems

1793
01:05:43,440 --> 01:05:44,640
they didn't plan for.

1794
01:05:44,640 --> 01:05:46,160
Security and compliance enforcement

1795
01:05:46,160 --> 01:05:47,640
follows the same trajectory.

1796
01:05:47,640 --> 01:05:51,280
Manual policy reviews get replaced by continuous drift detection.

1797
01:05:51,280 --> 01:05:54,280
Audit preparation gets replaced by always on evidence collection.

1798
01:05:54,280 --> 01:05:55,680
Incident response gets faster

1799
01:05:55,680 --> 01:05:57,680
because graph activity logs make the timeline

1800
01:05:57,680 --> 01:06:00,400
of what happened reconstructable in hours rather than days.

1801
01:06:00,400 --> 01:06:02,160
The competitive advantage isn't permanent

1802
01:06:02,160 --> 01:06:03,480
for those who move early.

1803
01:06:03,480 --> 01:06:05,680
Eventually these practices become table stakes,

1804
01:06:05,680 --> 01:06:07,920
but the organizations that master them first

1805
01:06:07,920 --> 01:06:09,160
build institutional knowledge

1806
01:06:09,160 --> 01:06:12,160
that can't be purchased off the shelf or caught up too quickly.

1807
01:06:12,160 --> 01:06:14,480
The window to build that advantage is open right now,

1808
01:06:14,480 --> 01:06:15,440
the future is clear.

1809
01:06:15,440 --> 01:06:19,680
Now let's talk about what you should do starting today.

1810
01:06:19,680 --> 01:06:22,760
Starting today, your first steps, the roadmap,

1811
01:06:22,760 --> 01:06:25,040
the case studies, the deadlines.

1812
01:06:25,040 --> 01:06:28,040
None of it matters until someone on your team opens a terminal,

1813
01:06:28,040 --> 01:06:30,680
you need to run a query against your actual tenant.

1814
01:06:30,680 --> 01:06:32,520
That first step is smaller than you think

1815
01:06:32,520 --> 01:06:34,040
and it's where the shift begins.

1816
01:06:34,040 --> 01:06:36,400
Start with an honest audit of your current state.

1817
01:06:36,400 --> 01:06:39,320
Not a strategy meeting, a literal inventory.

1818
01:06:39,320 --> 01:06:40,960
Open a spreadsheet if you have to.

1819
01:06:40,960 --> 01:06:43,480
List every recurring task your team does manually,

1820
01:06:43,480 --> 01:06:46,040
write down how long it takes, how often it happens,

1821
01:06:46,040 --> 01:06:47,760
and if any automation exists at all,

1822
01:06:47,760 --> 01:06:49,120
most teams find the same thing.

1823
01:06:49,120 --> 01:06:50,880
The majority of their time goes to tasks

1824
01:06:50,880 --> 01:06:53,800
that are fully automatable and the automation they do have,

1825
01:06:53,800 --> 01:06:56,200
it was built ad hoc, it isn't monitored

1826
01:06:56,200 --> 01:06:58,160
and it wasn't designed to be reliable.

1827
01:06:58,160 --> 01:06:59,560
That inventory is your starting point.

1828
01:06:59,560 --> 01:07:01,200
It shows you where the leverage is

1829
01:07:01,200 --> 01:07:03,040
before you write a single line of code

1830
01:07:03,040 --> 01:07:06,280
while you're auditing processes, audit your permissions.

1831
01:07:06,280 --> 01:07:09,000
Run a query to find service principles with permissions

1832
01:07:09,000 --> 01:07:10,600
they haven't used in 90 days.

1833
01:07:10,600 --> 01:07:13,000
Pull a list of SharePoint sites with broad membership.

1834
01:07:13,000 --> 01:07:15,840
Check which app registrations have accumulated scopes

1835
01:07:15,840 --> 01:07:17,160
they don't actually need.

1836
01:07:17,160 --> 01:07:18,680
You already know what permission debt costs

1837
01:07:18,680 --> 01:07:20,080
when you deploy co-pilot.

1838
01:07:20,080 --> 01:07:22,040
Seeing the scope of your own debt is motivating.

1839
01:07:22,040 --> 01:07:24,200
The abstract argument becomes a concrete problem.

1840
01:07:24,200 --> 01:07:25,720
Step two is learning the fundamentals

1841
01:07:25,720 --> 01:07:28,760
and the entry point is easier than the documentation makes it look.

1842
01:07:28,760 --> 01:07:31,640
Go to graph.microsoft.com and open the Graph Explorer.

1843
01:07:31,640 --> 01:07:33,560
It lets you run queries against your life tenant

1844
01:07:33,560 --> 01:07:36,240
with zero local setup, start there.

1845
01:07:36,240 --> 01:07:38,880
Type get users and look at the response.

1846
01:07:38,880 --> 01:07:41,160
Add a select statement for display names and mail

1847
01:07:41,160 --> 01:07:42,960
to see how it reduces the data load.

1848
01:07:42,960 --> 01:07:44,840
Run a query for groups and filter by name.

1849
01:07:44,840 --> 01:07:46,280
These aren't production scripts.

1850
01:07:46,280 --> 01:07:48,000
They're conversations with the data model.

1851
01:07:48,000 --> 01:07:49,920
10 minutes of exploration teaches you more

1852
01:07:49,920 --> 01:07:52,760
about the graph schema than an hour of reading.

1853
01:07:52,760 --> 01:07:56,160
From there, move to the PowerShell SDK in a test environment,

1854
01:07:56,160 --> 01:07:58,320
connect with your own account, retrieve something,

1855
01:07:58,320 --> 01:08:00,080
modify something that isn't critical.

1856
01:08:00,080 --> 01:08:01,600
See what a throttling response looks like

1857
01:08:01,600 --> 01:08:03,480
before you hit one in production.

1858
01:08:03,480 --> 01:08:06,480
Understand what the response body tells you about when to try again.

1859
01:08:06,480 --> 01:08:09,320
This isn't about mastery yet, it's about orientation.

1860
01:08:09,320 --> 01:08:12,800
An orientation is what makes the first real project move faster.

1861
01:08:12,800 --> 01:08:14,720
Step three is picking that first project.

1862
01:08:14,720 --> 01:08:17,320
The criteria matter more than the technical difficulty.

1863
01:08:17,320 --> 01:08:19,640
You want high visibility with a low blast radius.

1864
01:08:19,640 --> 01:08:21,680
License reporting is the classic entry point.

1865
01:08:21,680 --> 01:08:23,040
There are no right operations.

1866
01:08:23,040 --> 01:08:25,920
It provides immediate value and stakeholders will actually notice.

1867
01:08:25,920 --> 01:08:28,640
User provisioning for a single department is the next level,

1868
01:08:28,640 --> 01:08:30,920
build it to be idempotent, measure the state of things

1869
01:08:30,920 --> 01:08:33,800
before you deploy, measure it again two weeks later,

1870
01:08:33,800 --> 01:08:35,400
document the difference.

1871
01:08:35,400 --> 01:08:37,520
Step four is sharing what you find.

1872
01:08:37,520 --> 01:08:39,560
Show a dashboard of recovered licenses,

1873
01:08:39,560 --> 01:08:42,400
compare provisioning times before and after the change.

1874
01:08:42,400 --> 01:08:43,840
These aren't just metrics.

1875
01:08:43,840 --> 01:08:46,120
They're the argument for the next phase of investment.

1876
01:08:46,120 --> 01:08:48,320
Results become budget justifications.

1877
01:08:48,320 --> 01:08:51,320
Budget justifications become dedicated automation teams.

1878
01:08:51,320 --> 01:08:53,120
And those teams build the infrastructure graph

1879
01:08:53,120 --> 01:08:54,680
needs to reach its full potential.

1880
01:08:54,680 --> 01:08:56,000
Step five is the calendar.

1881
01:08:56,000 --> 01:08:59,840
If Azure AD graph is still in your environment, that's the emergency.

1882
01:08:59,840 --> 01:09:03,920
The graph CLI retires in August of 2026.

1883
01:09:03,920 --> 01:09:07,080
Male permission changes land in December of 2026.

1884
01:09:07,080 --> 01:09:09,240
Put those dates in your tracker right now.

1885
01:09:09,240 --> 01:09:10,840
Do it before this section closes.

1886
01:09:10,840 --> 01:09:11,960
Do it before the episode ends.

1887
01:09:11,960 --> 01:09:13,360
Start small.

1888
01:09:13,360 --> 01:09:14,400
Measure everything.

1889
01:09:14,400 --> 01:09:15,640
Scale what works.

1890
01:09:15,640 --> 01:09:17,480
The portal is just a convenience layer.

1891
01:09:17,480 --> 01:09:18,680
Graph is your control plane.

1892
01:09:18,680 --> 01:09:22,160
PowerShell is the engine that makes it work at enterprise scale.

1893
01:09:22,160 --> 01:09:23,240
Everything we talked about today.

1894
01:09:23,240 --> 01:09:26,360
User life cycles, governance, security and co-pilot readiness.

1895
01:09:26,360 --> 01:09:28,440
It all runs through that same foundation.

1896
01:09:28,440 --> 01:09:31,280
The company's building on it right now aren't waiting to see what happens.

1897
01:09:31,280 --> 01:09:34,400
They are building an advantage that gets harder to beat every single month.

1898
01:09:34,400 --> 01:09:35,480
But here's the problem.

1899
01:09:35,480 --> 01:09:36,640
The deadlines are real.

1900
01:09:36,640 --> 01:09:38,160
The skills gap is real.

1901
01:09:38,160 --> 01:09:41,320
And the permission debt sitting in your tenant right now is very real.

1902
01:09:41,320 --> 01:09:43,040
None of it gets easier by waiting.

1903
01:09:43,040 --> 01:09:45,600
So what is actually happening is a shift in how we work.

1904
01:09:45,600 --> 01:09:46,760
Start with one audit.

1905
01:09:46,760 --> 01:09:48,040
Pick one pilot project.

1906
01:09:48,040 --> 01:09:49,200
Measure what changes.

1907
01:09:49,200 --> 01:09:53,000
Every serious graph program started the same way.

1908
01:09:53,000 --> 01:09:54,600
It didn't start with a big initiative.

1909
01:09:54,600 --> 01:09:58,880
It started with one person running a query and seeing data the portal never showed them.

1910
01:09:58,880 --> 01:10:03,080
If this changed how you think about M365, follow me, myorcapeaters on LinkedIn, leave a review

1911
01:10:03,080 --> 01:10:04,080
for the podcast.

1912
01:10:04,080 --> 01:10:05,520
It helps more people find it.

1913
01:10:05,520 --> 01:10:07,520
And share your biggest challenge with graph in the comments.

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.