SHIELD — S: Sight¶

You cannot secure what you cannot see.

TL;DR

You cannot secure what you cannot see. Maintain a complete identity inventory — users, service accounts, service principals, guest users. Enforce MFA on all admin accounts. Apply least privilege everywhere. Run access reviews regularly. Detect and remediate orphaned accounts. Identity is the primary attack vector for cloud platforms.

Applies To

Audience: Security Architect · Compliance Officer · Platform Admin Character: Ongoing Frameworks: SHIELD · SCALE-OPS (Stewardship — admin governance)

What Sight Means in SHIELD¶

Sight is the foundation of the SHIELD framework. Before any control can be enforced, any policy applied, or any threat detected, the organisation must have complete visibility of who exists in the Power Platform tenant, what they can access, and whether that access is appropriate.

Sight is not a one-time inventory exercise. It is an ongoing operational discipline — because access changes constantly. Users join and leave. Roles are assigned and forgotten. Service accounts accumulate. External users are invited and never removed. Makers build solutions under personal accounts that become orphaned when they move to another team.

In the absence of Sight, the other SHIELD pillars operate on incomplete information. Harden cannot protect data if it does not know who has access to it. Enforce cannot generate audit evidence about access governance if access has never been reviewed. Defend cannot detect anomalous access patterns if it does not know what normal looks like.

Sight makes everything else possible.

Why Sight Decisions Matter¶

Identity is the primary attack vector for enterprise cloud platforms. Most security incidents involving Power Platform are not exploitation of technical vulnerabilities — they are exploitation of excessive access, stale credentials, ungoverned service accounts, and misconfigured permissions that exist because nobody has reviewed them.

The pattern is familiar in enterprise environments:

An admin account created for a project three years ago still has tenant-level admin rights
A flow runs under a personal user account — when that user leaves, the flow fails and nobody knows why
An external consultant was given Environment Admin access six months ago and was never removed
A service principal with organisation-wide read access was created for an integration and never scoped down
A maker built a solution that shares data with 500 users — nobody reviewed whether all 500 should have access

Every one of these is a Sight failure. The access existed. Nobody could see it clearly. Nobody reviewed it.

The Core Questions Sight Answers¶

Do we have a complete inventory of who has access to Power Platform?
Are permissions assigned on a least-privilege basis?
Are service accounts and service principals governed and reviewed?
Are guest and external users tracked and time-bound?
Are there orphaned accounts, orphaned resources, or stale permissions that need remediation?
Do we know who our Power Platform administrators are at every level?

Identity and Access in Power Platform — The Landscape¶

Power Platform has a layered identity and access model. Sight must cover every layer — missing one creates a gap that other pillars cannot compensate for.

Tenant-Level Administration¶

The highest privilege level in Power Platform is the Power Platform Administrator role in Microsoft Entra ID. Users with this role have unrestricted access to all environments, all DLP policies, all tenant settings, and all licensing. This role should be held by the smallest possible number of named individuals — typically two to four in an enterprise organisation, to ensure cover without excessive exposure.

The Global Administrator role in Microsoft 365 also carries Power Platform admin rights. Every Global Administrator is effectively a Power Platform Administrator. Global Administrator role holders should be inventoried as part of Power Platform access governance — not just dedicated Power Platform admin roles.

Tenant-level Sight requirements: - Complete list of all Power Platform Administrators and Global Administrators — named individuals, not groups - Justification on file for each assignment - Review cadence defined — quarterly for admin roles - Just-in-time access via Azure AD Privileged Identity Management (PIM) for admin operations where possible — removing standing admin access in favour of time-limited elevation

Environment-Level Roles¶

Within each environment, three built-in roles govern access:

Role	Capability	Risk Level
System Administrator	Full control of the environment — create, read, update, delete all data and configuration	Highest
System Customizer	Create and modify solution components — apps, flows, tables — but limited data access	High
Environment Maker	Create apps and flows — no data access by default	Moderate

The risk of default role assignment: In many Power Platform environments, the System Administrator role is assigned broadly — to every IT team member, every developer, or even all licensed users. This is the most common Sight failure at the environment level. System Administrator should be held only by the individuals who need full environment control — typically the environment owner and their designated backup.

Environment-level Sight requirements: - Named owner for every environment — recorded in the Power Platform Admin Center - System Administrator role holders inventoried per environment - System Customizer and Environment Maker role assignments reviewed for appropriateness - No individuals assigned System Administrator "just in case" or because it was easier than defining a scoped role

Dataverse Security Roles¶

Within Dataverse, security roles define what users can do with specific tables — create, read, update, delete, append, append to, assign, share — at defined scope levels (user, business unit, organisation).

Security roles are the most granular access control layer in Power Platform. They are also the most frequently misconfigured — either because roles were never designed deliberately, or because the default System Administrator role was applied broadly and never replaced with purpose-built roles.

The principle of designed security roles: Every production Dataverse environment should have security roles designed by job function — not by convenience. The question is not "what is the easiest way to give this user access?" but "what is the minimum access this user needs to do their job?"

Sight requirements for Dataverse security roles: - Complete inventory of security roles per environment — what they permit, who holds them - Roles reviewed for least-privilege compliance — no overly permissive roles assigned to broad populations - System Administrator role in Dataverse used only where full control is genuinely required - Role assignments reviewed when user responsibilities change

Service Accounts and Application Users¶

Service accounts and application users are non-interactive identities used by integrations, flows, and external systems to access Dataverse and Power Platform.

Application users are the correct pattern for Power Platform integrations — non-licensed, non-interactive accounts associated with Azure AD app registrations. They have security roles assigned like any other user but cannot log in interactively.

The personal account anti-pattern: Flows and integrations that use a personal user account's credentials will fail when that user's password changes, their MFA configuration changes, or they leave the organisation. Personal account credentials used for service purposes are a reliability risk and a security risk — the account typically has broader access than the integration requires, and access ends only when someone notices the failure.

Sight requirements for service accounts: - Complete inventory of application users and service accounts across all environments - Each application user associated with a named owner — the team or individual responsible for it - Service account permissions scoped to the minimum required — no application users with System Administrator - Regular review — application users that are no longer needed should be disabled and removed - No production flows or integrations running under personal user account credentials

Guest and External Users¶

Power Platform environments frequently include guest users — external consultants, partners, auditors, and contractors invited into the organisation's Azure AD tenant. These users carry the same risks as internal users but with additional considerations: their access is typically less scrutinised, their identity is managed by an external organisation, and they are often not removed when their engagement ends.

Sight requirements for external users: - Complete inventory of guest users with access to Power Platform environments - Access justification on file for each external user — who invited them, why, and for how long - Time-bound access — external access should have an expiry date, not be open-ended - Regular review — quarterly at minimum — of all guest user access - Defined offboarding process — when an engagement ends, access is removed, not left to expire organically

Authentication Controls¶

Authentication controls are the first line of Sight — ensuring that only legitimate, verified identities can access Power Platform.

Multi-Factor Authentication¶

MFA is the single most effective control against credential-based attacks. For Power Platform, MFA must be enforced for:

All Power Platform administrators — unconditionally
All users with Environment Admin or System Administrator roles
All makers and developers with access to production environments
All external and guest users

MFA enforcement for the broader licensed user population — makers in development environments, read-only users — is best practice and should be the organisational standard, not an exception.

Conditional Access as the enforcement mechanism: MFA should be enforced via Entra ID Conditional Access policies — not relied upon as a per-user setting. Conditional Access policies enforce MFA at authentication time based on defined conditions: user role, application, device compliance, location, and risk level. This provides consistent, auditable enforcement across the entire user population.

Passwordless Authentication¶

For high-privilege accounts — Power Platform administrators, environment admins, and System Administrators — passwordless authentication (FIDO2 security keys, Windows Hello for Business, Microsoft Authenticator) eliminates the password as an attack surface entirely. Organisations with mature identity security practices should move admin accounts to passwordless as standard.

Conditional Access Policies¶

Conditional Access policies govern the conditions under which access to Power Platform is permitted:

Device compliance: Require that devices accessing Power Platform are enrolled in and compliant with the organisation's mobile device management (MDM) policy. Unmanaged personal devices should not have access to Power Platform environments containing sensitive data.

Location-based access: Restrict access to known corporate network locations or approved countries for high-risk roles or sensitive environments. Block access from high-risk geographies where the organisation has no operations.

Session controls: Apply session length limits and re-authentication requirements for admin access and sensitive environment access.

Risk-based access: Leverage Entra ID Identity Protection to enforce step-up authentication or block access when sign-in risk signals indicate a potentially compromised account.

Access Reviews and Recertification¶

Access that is never reviewed is access that accumulates beyond what is needed. Enterprise Power Platform environments operate over years — user roles change, projects end, people leave, and access granted for a specific purpose persists long after that purpose has passed.

Entra ID Access Reviews¶

Microsoft Entra ID Access Reviews provide a structured, auditable process for periodically reviewing and recertifying access assignments:

Schedule access reviews for Power Platform admin roles, environment admin roles, and Dataverse system administrator assignments
Route reviews to appropriate reviewers — environment owners review environment access, the CoE team reviews tenant-level admin roles
Document review outcomes — access confirmed, access removed, access escalated for investigation
Integrate access review results with offboarding processes — departing users should be automatically flagged for access removal

Recommended review cadence:

Role Level	Review Frequency
Tenant-level admin (Power Platform Administrator, Global Admin)	Quarterly
Environment Admin / System Administrator	Quarterly
Dataverse security role assignments (production)	Semi-annually
Guest and external users	Quarterly
Application users and service principals	Semi-annually

Orphaned Resource Detection¶

Users who leave the organisation may leave behind:

Environments they owned — now without a named owner
Flows running under their credentials — now failing silently
Apps they built — now without a support owner
Security role assignments — now assigned to a disabled account

The CoE Starter Kit's orphaned resource detection surfaces these automatically — identifying environments without owners, flows owned by disabled accounts, and apps with no active owner. Orphaned resource remediation should be a standing operational process, not a periodic audit exercise.

Privileged Identity Management — Just-in-Time Admin Access¶

Standing administrative access — where a user holds admin rights continuously, whether they are actively performing admin tasks or not — represents unnecessary exposure. Azure AD Privileged Identity Management (PIM) addresses this with just-in-time access elevation:

Admin roles are assigned as eligible rather than active — the user does not hold the role continuously
When admin access is needed, the user activates their eligible role — providing justification, triggering MFA, and receiving time-limited access (typically 1-8 hours)
All role activations are logged — creating an auditable record of when admin access was used, by whom, and for what stated purpose
Activation can be configured to require approval from a second administrator for the highest-privilege roles

The enterprise implication: PIM dramatically reduces the window of exposure from compromised admin credentials. An attacker who obtains a Power Platform Administrator's credentials gains nothing if that account has no standing admin rights — they would also need to complete the PIM activation process, which requires MFA and generates an alert.

For organisations in regulated industries, PIM activation logs also serve as audit evidence of controlled, justified admin access — a requirement in many compliance frameworks.

Maturity Levels¶

Level	Description
Basic	Environment owners named in Admin Center. MFA enforced for admin accounts. No guest users without review. Application users used for critical integrations.
Intermediate	Complete access inventory across all environments. Conditional Access policies enforced for all Power Platform access. Quarterly access reviews conducted and documented. Orphaned resource detection active via CoE Starter Kit. Service account inventory maintained.
Advanced	PIM enabled for all admin roles — no standing admin access. Continuous access monitoring with anomaly alerting. Automated access review workflow integrated with HR offboarding. All external user access time-bound and reviewed. Zero personal account credentials in production integrations. Full audit trail of all access changes.

Safe Zone¶

Environments used for personal productivity with non-sensitive data, no external users, and a single named owner can operate at Basic maturity.

Any environment or deployment that meets one or more of the following must reach Intermediate or Advanced maturity: - Contains sensitive, regulated, or personally identifiable data - Is accessed by external or guest users - Has more than one administrator - Is used for production workloads - Is subject to compliance or regulatory requirements - Has integrations running under any account credentials

Common Mistakes¶

System Administrator assigned broadly — every IT team member, every developer, or even all licensed users holding System Administrator. The most common and most impactful Sight failure at the environment level.
Personal accounts for service connections — flows and integrations running under named user accounts. Access ends when the person leaves; scope is broader than needed; credentials are unmanaged.
No environment owners — environments created without named owners, accumulating without governance oversight. The CoE Starter Kit surfaces these but they must be actioned.
Guest users never removed — external consultants, auditors, and contractors with persistent access long after their engagement ended. Access reviews exist to catch this.
Standing admin access — administrators holding tenant-level or environment-level admin roles continuously, 24/7, whether performing admin tasks or not. PIM exists to reduce this exposure.
Security roles never reviewed — Dataverse security role assignments made when a user joined a project, never reviewed when their responsibilities changed or the project ended.
No offboarding integration — user accounts disabled in Azure AD but access in Power Platform environments not reviewed. Disabled accounts can still appear as owners of environments, apps, and flows.
Conditional Access gaps — MFA enforced for some users but not all. Unmanaged personal devices with access to sensitive Power Platform environments. Location-based access not configured for high-risk roles.
Application users with excessive permissions — service principals and application users created with System Administrator because it was easier than defining a scoped security role.

Readiness Checklist¶

Tenant-Level Access - [ ] All Power Platform Administrators and Global Administrators inventoried — named individuals documented - [ ] Admin role assignments justified and reviewed quarterly - [ ] PIM configured for tenant-level admin roles — no standing admin access for highest-privilege roles - [ ] MFA enforced for all admin accounts via Conditional Access — not per-user setting

Environment-Level Access - [ ] Named owner recorded for every environment in the Power Platform Admin Center - [ ] System Administrator role holders inventoried per environment - [ ] System Administrator assignments justified — not assigned broadly - [ ] Environment access reviewed quarterly for production environments

Dataverse Security Roles - [ ] Security roles designed by job function — not default System Administrator for all - [ ] Least-privilege principle applied — minimum access required per role - [ ] Security role assignments reviewed semi-annually for production environments - [ ] No users with System Administrator in Dataverse without explicit justification

Service Accounts and Application Users - [ ] Complete inventory of application users and service principals across all environments - [ ] Each application user associated with a named owner team - [ ] Application user permissions scoped to minimum required — no System Administrator - [ ] No production flows or integrations using personal account credentials - [ ] Application user inventory reviewed semi-annually

Authentication Controls - [ ] MFA enforced via Conditional Access for all Power Platform access - [ ] Device compliance required for access to sensitive environments - [ ] Location-based Conditional Access configured for high-risk roles - [ ] Session controls applied for admin and sensitive environment access - [ ] Passwordless authentication implemented for admin accounts (recommended)

Guest and External Users - [ ] Complete inventory of guest users with Power Platform access - [ ] Access justification on file for each external user - [ ] Time-bound access configured — expiry dates set - [ ] Quarterly review of all guest user access conducted and documented - [ ] Offboarding process defined for end of external engagement

Access Reviews - [ ] Entra ID Access Reviews configured for admin and production environment roles - [ ] Review cadence defined and scheduled per role level - [ ] Review outcomes documented and actioned - [ ] Orphaned resource detection active via CoE Starter Kit - [ ] Offboarding integration — departing user access reviewed as part of HR offboarding process

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