SHIELD — L: Lockdown¶

Lockdown is both a standing architecture principle and an emergency capability.

TL;DR

Lockdown is both standing architecture and emergency capability. Isolate workloads by risk — production never shares an environment with development. Harden the Default Environment. Enable Managed Environments on all non-developer environments. Configure VNet for regulated workloads. Be able to suspend an environment or revoke access within minutes of a security event.

Applies To

Audience: Security Architect · Platform Admin · Network Security Character: Ongoing (standing architecture + emergency capability) Frameworks: SHIELD · SCALE-OPS (Containment — environment strategy)

What Lockdown Means in SHIELD¶

Lockdown operates on two levels simultaneously — and understanding both is essential to implementing it correctly.

As a standing architecture principle, Lockdown defines the structural controls that separate workloads by risk, contain data within approved boundaries, and keep Power Platform traffic within organisational network perimeters. These controls are invisible to users under normal operations. They are the walls, not the locks — structural boundaries that prevent risk from spreading rather than emergency responses to specific threats.

As an emergency capability, Lockdown provides the tools for rapid containment when a threat is detected — the ability to suspend an environment, revoke access, block a connector, or isolate a workload within minutes of identifying a security event. These capabilities are rarely used, but their availability — and the speed with which they can be deployed — is a critical security property of enterprise Power Platform.

A platform that can only contain threats by disabling entire services is not well-governed. A platform where a specific environment can be suspended, a specific user's access revoked, or a specific connector blocked in minutes — while other environments continue operating normally — is.

Why Lockdown Decisions Matter¶

Containment failures in Power Platform occur when risk can propagate across workload boundaries:

A security incident in a developer's personal environment affects production because both share the same DLP policy and there is no isolation boundary
A compromised user account has access to every environment in the tenant because role assignments were never scoped
Sensitive data from a regulated environment can be accessed from the Default Environment because no tenant boundary controls separate them
A flow exfiltrating data cannot be stopped without taking down the entire environment because there is no granular connector blocking capability
Traffic from a regulated Power Platform environment traverses the public internet because VNet integration was never configured

Every one of these is a containment architecture failure. The structural controls that would have prevented propagation were never put in place.

The Core Questions Lockdown Answers¶

Are production workloads structurally isolated from development and experimentation?
Are regulated workloads in dedicated environments with appropriate boundaries?
Is the Default Environment properly hardened and monitored?
Can we suspend an environment or revoke access within minutes of a security event?
Is network traffic from Power Platform contained within approved network perimeters for regulated workloads?
Are cross-tenant connections governed — preventing data from crossing tenant boundaries without authorisation?
Does data sovereignty configuration ensure regulated data never leaves approved geographic boundaries?

Environment Isolation — The Structural Foundation¶

Environment isolation is the most important Lockdown control — and the one that must be designed before any workload goes to production. Environment strategy is covered in depth in SCALE-OPS Containment from the platform operations perspective. From a SHIELD perspective, the security requirement is absolute: workloads of different risk profiles must be in separate environments with appropriate boundaries.

The blast-radius principle: A security incident in one environment should not be able to affect other environments. This requires: - Separate environments for development, test, and production — not shared environments where a mistake in development impacts production - Separate environments for workloads of different sensitivity — a regulated HR data solution in a dedicated environment, not sharing infrastructure with a general productivity environment - No production workloads in the Default Environment — the Default Environment is open to all licensed users and cannot be adequately isolated

Environment purpose documentation: Every environment must have a documented purpose — what workloads it hosts, what data it contains, what risk tier it represents. This documentation is the basis for applying appropriate controls. An environment without documented purpose is an environment without deliberate security design.

The restricted environment: For the highest-sensitivity workloads — regulated financial data, health records, legally privileged information — a dedicated restricted environment with the tightest possible controls is appropriate: - Separate admin group — access to this environment requires explicit approval - Tightest DLP tier — minimum necessary connectors only - Managed Environments with all governance controls enabled - VNet integration for network containment - Customer-managed encryption keys - Dedicated monitoring and alerting

Managed Environments — The Primary Containment Layer¶

Managed Environments are the primary tenant-level containment mechanism for Power Platform. They transform environments from ungoverned shared spaces into governed, monitored, policy-enforced workspaces.

Key Managed Environments containment controls:

Sharing limits: In standard environments, canvas apps can be shared with the entire organisation with a single action. Sharing limits in Managed Environments restrict sharing to security groups — preventing viral spread of apps to populations that were never assessed as appropriate audiences.

IP firewall: The IP firewall restricts environment access to approved IP address ranges. Users attempting to access the environment from outside the approved ranges — including from personal devices on home networks — are blocked. This is particularly relevant for environments containing sensitive data where access from unmanaged devices is not acceptable.

Maker welcome content: Custom welcome messages communicate environment purpose, applicable policies, and support contacts to makers when they first access an environment. This is an underused but highly effective control — makers who understand what an environment is for and what policies apply to them make fewer governance errors.

Solution Checker enforcement: Solutions cannot be imported into Managed Environments with Critical or High Solution Checker findings — providing a deployment-time gate that operates independently of the pipeline.

The Default Environment — A Special Security Concern¶

The Default Environment receives dedicated treatment in Lockdown because it presents unique security challenges that no other environment type shares:

It cannot be deleted — unlike other environments, the Default Environment is permanent
All licensed users have access — every user with a Power Apps or Power Automate licence can create apps and flows in the Default Environment
It cannot be renamed to something misleading — though it can be renamed, its accessibility cannot be restricted
It is the most common location for ungoverned solutions — makers who do not know about environment strategy default to building here

Default Environment hardening requirements:

DLP policy: The Default Environment must have the most restrictive DLP policy in the tenant applied to it. All premium connectors should be blocked. All custom connectors should be blocked. Only standard connectors relevant to personal productivity (SharePoint, Teams, Outlook, OneDrive) should be in the Business bucket.

Environment routing: Configure environment routing in the Admin Center to automatically redirect new makers to a personal Developer environment rather than the Default Environment. Makers who begin working in their Developer environment are less likely to accumulate ungoverned solutions in the Default Environment.

Monitoring: The Default Environment should be monitored more intensively than any other environment — precisely because it is the most accessible and the least governed. CoE Starter Kit monitoring should surface active apps, flows, and data usage in the Default Environment with regular review.

Communication: Makers should understand that the Default Environment is for personal productivity only — not for team solutions, not for production workloads, not for solutions that handle anything beyond public data. This communication should be part of maker onboarding.

Network Isolation — Private VNet Integration¶

For regulated workloads where the requirement is that Power Platform traffic never traverses the public internet, Azure Virtual Network (VNet) integration provides network containment. This is covered in depth in DIALOGE Integration from the builder's perspective. From a SHIELD Lockdown perspective, it is a containment control decision.

When VNet integration is a Lockdown requirement: - Regulated industries (financial services, healthcare, government) where data must never leave the organisational network perimeter - Workloads where compliance requirements prohibit data transmission over the public internet - Environments where all traffic must be subject to organisational network security controls (NSG, Azure Firewall, DLP at network level)

VNet integration as a structural control: VNet integration, once configured, applies to all eligible traffic in the environment — it is not a per-connection setting. This makes it a reliable structural containment control rather than a discretionary option that individual flows must opt into.

The gateway alternative: For organisations that cannot use VNet integration (typically because Managed Environments are not yet in use or the Azure infrastructure is not in place), the on-premises data gateway provides a partial equivalent — keeping specific system-to-system traffic off the public internet via the gateway agent. The gateway is less comprehensive than VNet integration (it applies to gateway-routed traffic only, not all environment traffic) but provides meaningful containment for specific high-risk connections.

Cross-Tenant Connector Controls¶

Power Platform connectors can, by default, access systems in other Azure AD tenants — including personal Microsoft accounts. For enterprise environments, this creates a risk of data exfiltration via connectors that connect to personal or external tenant resources.

Tenant isolation controls: The Power Platform Admin Center and Azure AD provide mechanisms to restrict cross-tenant access:

Tenant isolation policies — restrict which external tenants can connect to your Power Platform environments via connectors. Inbound isolation prevents users in other tenants from using connectors that access your data. Outbound isolation prevents your users from using connectors that access other tenants' data.
Conditional Access — restrict access to Power Platform to compliant, managed devices and approved locations, reducing the risk of access from personal devices that might be connecting to personal tenant resources

Personal account connector risk: A connector authenticated with a personal Microsoft account (not a work account) can access personal OneDrive, personal Outlook, and other personal Microsoft services. This is a data exfiltration path — work data sent to a personal account is outside the organisation's control. Tenant isolation controls and DLP policies that restrict personal account connectors address this risk.

Emergency Lockdown Capabilities¶

When a security event occurs — a compromised account, a data exfiltration attempt, a malicious insider action — the ability to contain the damage quickly is critical. The window between incident detection and containment is the window during which damage accumulates.

Environment-level emergency controls:

Environment suspension: The Power Platform Admin Center allows administrators to disable an environment — preventing all access to apps, flows, and data within the environment. This is the most comprehensive containment action available and is appropriate for the most severe security events where the entire environment is potentially compromised.

Environment access revocation: Individual users can have their access to specific environments revoked via role removal. For a compromised account, removing all environment roles immediately — combined with disabling the Azure AD account — terminates the account's Power Platform access.

DLP policy emergency modification: A tenant-level DLP policy can be modified to immediately block a specific connector across all environments — preventing further data exfiltration via that connector while investigation proceeds.

Flow disabling: Individual cloud flows can be disabled via the Admin Center or PowerShell — stopping specific automated processes while the incident is assessed without taking down the entire environment.

Preparation for emergency response: Emergency Lockdown capabilities are only effective if the people who need to use them know how to use them before an incident occurs. The Defend pillar's incident response runbooks should include specific, step-by-step procedures for each emergency Lockdown action — with the relevant Admin Center navigation paths, PowerShell commands, and authorisation requirements documented.

The authorisation question: Emergency Lockdown actions — particularly environment suspension — can have significant business impact. The incident response runbook must define who has the authority to invoke each Lockdown action, under what conditions, and what notification and approval is required. A security analyst who cannot suspend an environment without a 48-hour approval process is not equipped for a real-time incident.

Data Sovereignty¶

Data sovereignty — ensuring regulated data never leaves approved geographic boundaries — is a Lockdown concern at the infrastructure level.

Environment geographic region: Every Dataverse environment is provisioned in a specific geographic region. For regulated workloads, the environment must be provisioned in the approved region before any data is created. Changing an environment's region after data exists requires Microsoft support intervention and may not be possible without data migration.

Service processing locations: Some Power Platform features process data in locations outside the primary environment region. AI Builder, certain analytics features, and some connector processing may involve data leaving the primary region. Review Microsoft's Power Platform data residency documentation for each service in use and assess against sovereignty requirements.

Cross-border DLP: DLP policies can restrict connectors that are based in or process data in specific geographic regions — blocking connectors that would result in regulated data leaving approved boundaries.

Maturity Levels¶

Level	Description
Basic	Production workloads in dedicated environments — not Default Environment. Managed Environments enabled on production. Default Environment has restrictive DLP policy. Environment owners named.
Intermediate	Managed Environments enabled on all non-developer environments. Environment routing configured. Default Environment monitored via CoE Starter Kit. Tenant isolation policies configured. Emergency Lockdown procedures documented. Data residency verified for regulated environments.
Advanced	VNet integration for all regulated workloads. Restricted environment for highest-sensitivity data. Customer-managed keys where required. Cross-tenant controls fully configured. Emergency Lockdown runbooks tested and staff trained. Data sovereignty controls verified and monitored. IP firewall configured for sensitive environments.

Safe Zone¶

Personal productivity solutions in personal Developer environments with non-sensitive data can operate at Basic maturity.

Any deployment that meets one or more of the following must reach Intermediate or Advanced maturity: - Contains production workloads - Handles Confidential or Regulated data - Has external users or external-facing components - Is subject to data residency or data sovereignty requirements - Has regulatory requirements for network containment - Is in a regulated industry (financial services, healthcare, government)

Common Mistakes¶

Production workloads in the Default Environment — the most common containment failure. The Default Environment is accessible to all licensed users, has no isolation from other workloads, and cannot be adequately governed for production use.
Managed Environments not enabled — environments operating without the containment infrastructure that Managed Environments provides. No sharing limits, no IP firewall, no Solution Checker enforcement.
No environment routing — new makers default to the Default Environment, accumulating ungoverned solutions. Environment routing redirects them to personal Developer environments automatically.
Emergency procedures not documented — when a security incident occurs, administrators search for how to suspend an environment or revoke access. Response time is measured in hours rather than minutes.
VNet integration not assessed for regulated workloads — regulated environments where data traverses the public internet because VNet integration was never considered as a requirement.
Cross-tenant controls not configured — personal account connectors accessible in production environments, providing a data exfiltration path to personal storage and email.
Data residency assumed — regulated environments provisioned without verifying the geographic region. Data is being stored in a jurisdiction that does not meet regulatory requirements.
IP firewall not configured for sensitive environments — access from unmanaged personal devices to environments containing sensitive data, with no network-level restriction.
Emergency authority undefined — incident response runbooks describe what to do but not who can authorise it. Security events wait for approval chains while damage accumulates.

Readiness Checklist¶

Environment Isolation - [ ] Environment strategy defined — purpose documented for every environment - [ ] Production workloads in dedicated environments — not Default Environment - [ ] Regulated and high-sensitivity workloads in dedicated restricted environments - [ ] Environment risk tiers defined and applied - [ ] No production workloads in the Default Environment

Managed Environments - [ ] Managed Environments enabled on all non-developer environments - [ ] Sharing limits configured — canvas apps restricted to security groups - [ ] IP firewall configured for sensitive environments - [ ] Maker welcome content configured for every environment - [ ] Solution Checker enforcement enabled

Default Environment - [ ] Restrictive DLP policy applied — premium and custom connectors blocked - [ ] Environment routing configured — new makers directed to personal Developer environments - [ ] Default Environment monitored via CoE Starter Kit - [ ] Maker communication — Default Environment purpose communicated in onboarding

Network Isolation - [ ] VNet integration assessed for regulated workloads — decision documented - [ ] VNet integration configured for environments requiring network containment - [ ] On-premises gateway deployed on managed servers with HA cluster (where applicable) - [ ] NSG rules and network configuration reviewed with network team

Cross-Tenant Controls - [ ] Tenant isolation policies assessed and configured - [ ] Personal account connector risk assessed — DLP controls in place - [ ] Cross-tenant access review conducted

Data Sovereignty - [ ] Production environment geographic regions verified against residency requirements - [ ] Service processing location review completed for all services in use - [ ] Cross-border DLP controls configured for regulated connectors

Emergency Lockdown - [ ] Emergency Lockdown procedures documented — environment suspension, access revocation, connector blocking, flow disabling - [ ] Authorisation requirements defined — who can invoke each action - [ ] Contact list maintained — who to notify when Lockdown actions are invoked - [ ] Runbooks reviewed and staff trained — not discovered during an incident - [ ] Emergency access tested — procedures verified to work before they are needed

Part of the SHIELD Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026