M365.FM - Modern work, security, and productivity with Microsoft 365 Titelbild

M365.FM - Modern work, security, and productivity with Microsoft 365

M365.FM - Modern work, security, and productivity with Microsoft 365

Von: Mirko Peters (Microsoft 365 consultant and trainer)
Jetzt kostenlos hören, ohne Abo

Über diesen Titel

 Welcome to the M365.FM — your essential podcast for everything Microsoft 365, Azure, and beyond. Join us as we explore the latest developments across Power BI, Power Platform, Microsoft Teams, Viva, Fabric, Purview, Security, and the entire Microsoft ecosystem. Each episode delivers expert insights, real-world use cases, best practices, and interviews with industry leaders to help you stay ahead in the fast-moving world of cloud, collaboration, and data innovation. Whether you're an IT professional, business leader, developer, or data enthusiast, the M365.FM brings the knowledge, trends, and strategies you need to thrive in the modern digital workplace. Tune in, level up, and make the most of everything Microsoft has to offer. M365.FM is part of the M365-Show Network.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.Copyright Mirko Peters / m365.fm - Part of the m365.show Network - News, tips, and best practices for Microsoft 365 admins Politik & Regierungen
Folgen
  • Sovereignty is Not a Product: The Architecture of Control

    Sovereignty is Not a Product: The Architecture of Control
    Feb 22 2026
    Most organizations treat “sovereign cloud” like something you can buy. Pick a region.Print the compliance packet.Call it done. That’s the comfortable lie. In this episode, we dismantle the myth that sovereignty is a SKU, a geography, or a contract clause. Sovereignty is not residency. It’s not a marketing label. It’s not “EU-only” storage. Sovereignty is enforceable authority over:IdentityKeysDataThe control plane that can change all threeAnd if you don’t control those layers — you’re renting, not governing. 🔥 What We Break Down in This Episode This conversation moves past slogans and into architecture. We explore: 1️⃣ The Comfortable Lie: “Sovereign Cloud” as a Product Why residency, sovereignty, and independence are three completely different problems — and why confusing them leads to a probabilistic security model. 2️⃣ The Sovereignty Stack: Five Verifiable Layers We define sovereignty as something you can test, audit, and assign ownership to:JurisdictionIdentity authorityControl plane authorityData plane placementCryptographic custodyIf you can’t verify a layer, you don’t control it. 3️⃣ EU Data Boundary vs. Authority The EU Data Boundary improves residency.It does not transfer decision authority. Geography answers where.Sovereignty answers who. 4️⃣ The CLOUD Act Reality Check Jurisdiction eats geography. If a provider can be compelled, sovereignty depends on one question: Does compelled access produce plaintext — or encrypted noise? That answer lives in your key custody model. 5️⃣ Encryption Without Custody Is Theater Encryption at rest is hygiene.Customer-managed keys are better.External custody with controlled release? That’s sovereignty. Because encryption isn’t the point. Who can cause decryption is. 🧠 Identity Is the Compiler of Authority Entra isn’t just an identity provider.It’s a distributed decision engine that continuously mints tokens — portable authority. If token issuance drifts, your sovereignty drifts. We break down:Conditional Access entropyToken supply chain dependenciesRisk-based controls vs deterministic enforcementWhy policy rollback is more important than policy documentationSovereignty fails silently through identity drift. 🏗 Control Plane vs Data Plane Data lives in regions.Authority lives in the control plane. If someone can:Assign rolesChange policiesRotate keysApprove support accessThen they can redefine reality — regardless of where your data sits. Sovereignty starts with minimizing who can change the rules. 🌍 Hybrid, Arc, and Azure Local We walk through the real trade-offs:Azure Arc — powerful governance tool or sovereignty amplifier?Regional landing zones vs application landing zonesConnected Azure Local — sovereignty by extensionDisconnected Azure Local — sovereignty by isolationM365 Local — where sovereignty gains are real (and where they stop)The takeaway: locality is not control. Authority is control. 🧩 Tenant Isolation and Metadata Reality Tenant isolation is logical — not physical. Metadata, connectors, and cross-tenant patterns create permeability most organizations ignore. We explore:Power Platform tenant isolationConnector enforcement gapsGuest identity implicationsMetadata gravityWhy default-deny matters more than allowlists🛡 The Default-Deny Sovereign Reference Architecture This episode culminates in a practical blueprint: A four-plane default-deny model across:Identity authorityControl plane authorityData plane constraintsCryptographic custodyPlus one critical ingredient most programs skip: Rollback as a first-class security control. If you cannot restore identity and control-plane state to a known-good version, sovereignty is temporary. 💡 Core Message Sovereignty is not a region label.It is not a compliance PDF.It is not a vendor promise. Sovereignty is the ability to prevent:Unauthorized authorityUncontrolled decryptionPolicy driftSilent exceptionsAnd that requires architectural discipline — not procurement.Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.
    Mehr anzeigen Weniger anzeigen
    1 Std. und 23 Min.
  • Stop Building Apps, Start Engineering Control Planes

    Stop Building Apps, Start Engineering Control Planes
    Feb 21 2026
    Most organizations think more apps means more productivity. They’re wrong. More apps mean more governance surface area — more connectors, more owners, more permissions, more data pathways, and more tickets when something breaks. Governance-by-humans doesn’t scale. Control planes scale trust. This episode breaks down a single operating model shift — from building apps to engineering control planes — that consistently reduces governance-related support tickets by ~40%. This channel does control, not crafts. 1. The Foundational Misunderstanding: “An App Is the Solution” An app is not the solution. An app is a veneer over:Identity decisionsConnector pathwaysEnvironment boundariesLifecycle eventsAuthorization graphsWhat gets demoed isn’t what gets audited. Governance doesn’t live in the canvas. It lives in the control plane: identity policy, Conditional Access, connector permissions, DLP, environment strategy, inventory, and lifecycle enforcement. App-first models create probabilistic systems.Control planes create deterministic ones. If the original maker quits today and the system can’t be safely maintained or retired, you didn’t build a solution — you built a hostage situation. 2. App Sprawl Autopsy App sprawl isn’t aesthetic. It’s measurable. Symptoms:3,000+ apps no one can explainOrphaned ownershipDefault environment gravityConnector creepGovernance tickets as leading indicatorsThe root cause: governance that depends on human review. Approval boards don’t enforce policy.They manufacture precedent. Exceptions accumulate. Drift becomes normal. Audits require heroics. Governance becomes theater. 3. The Hidden Bill App-first estates create recurring operational debt:📩 Support friction📑 Audit evidence scavenger hunts🚨 Incident archaeology💸 License and capacity wasteThe executive translation: You can invest once in a control plane.Or you can pay ambiguity tax forever. 4. What a Control Plane Actually Is A control plane decides:What can existWho can create itWhat must be true at creation timeWhat happens when rules driftOutputs:Identity outcomesPolicy outcomesLifecycle outcomesObservability outcomesIf enforcement requires memory instead of automation, it’s not control. 5. Microsoft Already Has the Control Plane Components You’re just not using them intentionally.Entra = distributed decision engineConditional Access = policy compilerMicrosoft Graph = lifecycle orchestration busPurview DLP = boundary enforcement layerPower Platform admin features = scale controlsThe tools exist. Intent usually doesn’t. Case Study 1: Power App Explosion Problem: 3,000+ undefined apps.Solution: Governance through Graph + lifecycle at birth. Changes:Enforced ownership continuityZoned environments (green/yellow/red)Connector governance gatesAutomated retirementContinuous inventoryResults:41% reduction in governance-related tickets60% faster audit evidence production28% reduction in unused assetsSystem behavior changed. Case Study 2: Azure Policy Chaos Problem: RBAC drift, orphaned service principals, inconsistent tagging.Solution: Identity-first guardrails + blueprinted provisioning. Changes:Workload identity standardsExpiring privileged rolesSubscription creation templatesDrift as telemetryEnforced tagging at birthResults:35% drop in misconfigurations22% reduced cloud spendZero major audit findingsGovern the principals. Not the resources. Case Study 3: Copilot & Shadow AI Blocking AI creates shadow AI. So they built an agent control plane:Prompt-level DLPLabel-aware exclusionsAgent identity governanceTool-scoped permissionsLifecycle + quarantineMonitoring for drift & defectsResults:Full rollout in 90 daysZero confirmed sensitive data leakage events2.3× forecasted adoptionNot “safe AI.”Governable AI. Executive Objection: “Governance Slows Innovation” Manual review slows innovation. Control planes accelerate it. App-first scaling looks fast early.Then ambiguity compounds.Tickets rise. Trust erodes. Innovation slows anyway. Control planes remove human bottlenecks from the hot path. The Operating Model Self-service with enforced guardrails:Zoning (green/yellow/red)Hub-and-spoke or federated on purposeEngineered exception workflowsStandardized templatesIncentives for reuse and deprecationAnd one executive truth serum: 🎯 Governance-related support ticket volume. If that number drops ~40%, your control plane is real. If it doesn’t, you’re performing governance. Failure Modes Control planes rot when:Automation is over-privilegedPolicies pile without refactoringLabels are fantasyOrphaned identities persistTelemetry doesn’t existGovernance must be enforceable, observable, and lifecycle-driven. Otherwise it’s theater. Conclusion Stop scaling apps.Scale a programmable control plane. If this episode helped reframe your tenant, leave a review so more operators find it. Connect with Mirko Peters on LinkedIn for deeper control plane patterns.Become a supporter of this podcast: ...
    Mehr anzeigen Weniger anzeigen
    1 Std. und 32 Min.
  • The Context Advantage: Architecting the High-Performance Autonomous Enterprise

    The Context Advantage: Architecting the High-Performance Autonomous Enterprise
    Feb 20 2026
    Most organizations think their AI rollout failed because the model wasn’t smart enough, or because users “don’t know how to prompt.” That’s the comforting story. It’s also wrong. In enterprises, AI fails because context is fragmented: identity doesn’t line up with permissions, work artifacts don’t line up with decisions, and nobody can explain what the system is allowed to treat as evidence. This episode maps context as architecture: memory, state, learning, and control. Once you see that substrate, Copilot stops looking random and starts behaving exactly like the environment you built for it. 1) The Foundational Misunderstanding: Copilot isn’t the system The foundational mistake is treating Microsoft 365 Copilot as the system. It isn’t. Copilot is an interaction surface. The real system is your tenant: identity, permissions, document sprawl, metadata discipline, lifecycle policies, and unmanaged connectors. Copilot doesn’t create order. It consumes whatever order you already have. If your tenant runs on entropy, Copilot operationalizes entropy at conversational speed. Leaders experience this as “randomness.” The assistant sounds plausible—sometimes accurate, sometimes irrelevant, occasionally risky. Then the debate starts: is the model ready? Do we need better prompts? Meanwhile, the substrate stays untouched. Generative AI is probabilistic. It generates best-fit responses from whatever context it sees. If retrieval returns conflicting documents, stale procedures, or partial permissions, the model blends. It fills gaps. That’s not a bug. That’s how it works. So when executives say, “It feels like it makes things up,” they’re observing the collision between deterministic intent and probabilistic generation. Copilot cannot be more reliable than the context boundary it operates inside. Which means the real strategy question is not: “How do we prompt better?” It’s: “What substrate have we built for it to reason over?” What counts as memory?What counts as state?What counts as evidence?What happens when those are missing? Because when Copilot becomes the default interface for work—documents, meetings, analytics—the tenant becomes a context compiler. And if you don’t design that compiler, you still get one. You just get it by accident. 2) “Context” Defined Like an Architect Would Context is not “all the data.” It’s the minimal set of signals required to make a decision correctly, under the organization’s rules, at a specific moment in time. That forces discipline. Context is engineered from:Identity (who is asking, under what conditions)Permissions (what they can legitimately see)Relationships (who worked on what, and how recently)State (what is happening now)Evidence (authoritative sources, with lineage)Freshness (what is still true today)Data is raw material. Context is governed material. If you feed raw, permission-chaotic data into AI and call it context, you’ll get polished outputs that fail audit. Two boundaries matter:Context window: what the model technically seesRelevance window: what the organization authorizes as decision-grade evidenceBigger context ≠ better context. Bigger context often means diluted signal and increased hallucination risk. Measure context quality like infrastructure:AuthoritySpecificityTimelinessPermission correctnessConsistencyIf two sources disagree and you haven’t defined precedence, the model will average them into something that never existed. That’s not intelligence. That’s compromise rendered fluently. 3) Why Agents Fail First: Non-determinism meets enterprise entropy Agents fail before chat does. Why? Because chat can be wrong and ignored.Agents can be wrong and create consequences. Agents choose tools, update records, send emails, provision access. That means ambiguity becomes motion. Typical failure modes: Wrong tool choice.The tenant never defined which system owns which outcome. The agent pattern-matches and moves. Wrong scope.“Clean up stale vendors” without a definition of stale becomes overreach at scale. Wrong escalation.No explicit ownership model? The agent escalates socially, not structurally. Hallucinated authority.Blended documents masquerade as binding procedure. Agents don’t break because they’re immature. They break because enterprise context is underspecified. Autonomy requires evidence standards, scope boundaries, stopping conditions, and escalation rules. Without that, it’s motion without intent. 4) Graph as Organizational Memory, Not Plumbing4Microsoft Graph is not just APIs. It’s organizational memory. Storage holds files.Memory holds meaning. Graph encodes relationships:Who metWho editedWhich artifacts clustered around decisionsWhich people co-author repeatedlyWhich documents drove escalationCopilot consumes relational intelligence. But Graph only reflects what the organization leaves behind. If containers are incoherent, memory retrieval becomes probabilistic. ...
    Mehr anzeigen Weniger anzeigen
    1 Std. und 22 Min.
Noch keine Rezensionen vorhanden