How to govern Security in Power Apps

Steps

1. 1

   Inventory Power Apps

   Connect Power Apps and let Rencore build a continuous inventory of its resources, owners, and configuration, so governance starts from what exists rather than a stale export.

2. 2

   Detect with policies

   Turn on the pre-built policies that cover Security in Power Apps to surface oversharing, sprawl, and misconfiguration on the first scan, before writing a single custom rule.

3. 3

   Review by owner and severity

   Use the Power Apps reports to review findings by owner, category, and severity, and to share them with stakeholders who do not have a seat in the platform.

4. 4

   Remediate and automate

   Apply automations to fix findings at scale, route sensitive changes through approvals, and keep every action reversible and logged for the audit trail.

Power Apps controls for Security

Grounded in the Rencore catalog. See the full Power Apps catalog on the Power Apps connector page.

• Power Apps (Canvas Apps) shared with everyone

  Shows Power Apps that all users of current tenant can viewed and used.

  Severity: Information

• Power Apps using an on-premise data gateway

  Apps reaching on-premise data sources increase the attack surface and depend on gateway availability.

  Severity: Medium

• Power Apps using custom connectors

  Apps using custom connectors bypass first-party connector governance and must be reviewed.

  Severity: Medium

• Power Apps that bypass user consent

  Apps with BypassConsent skip the connector consent prompt and silently use shared credentials.

  Severity: High

• Power Apps shared with more than 100 users

  Apps shared with very large groups of users should be evaluated for tenant-wide sharing or governance.

  Severity: Information

• Custom Power App connections

  Custom connectors expose external APIs and need to be reviewed for security and authentication.

  Severity: Medium

• On-premise Power App connections

  On-premise connections route Power App traffic through customer-managed gateways and require monitoring.

  Severity: Medium

• Power App connections that bypass consent

  Connections with ByPassConsent skip prompting end users for consent before sharing credentials.

  Severity: High

• DLP policy covers all environments but blocks no connectors

  An all-environments DLP policy without blocked connectors offers no real protection.

  Severity: High

• DLP policies defaulting connectors to General

  Policies that default new connectors to the non-business (General) group inadvertently approve every new connector for general use.

  Severity: Medium

• DLP policies with no blocked connectors

  Policies that do not block any connector cannot prevent sensitive connector combinations.

  Severity: Information

• DLP policies without custom connector restrictions

  Policies that do not explicitly classify any custom connector leave tenant-built connectors unrestricted.

  Severity: Medium

• Custom connectors without a privacy policy

  Custom connectors should declare a privacy policy URL so end users understand how their data is handled.

  Severity: Information

• Apps shared with entire tenant

  Power Apps shared with everyone in the tenant, grouped by owner.

• Power Apps using on-premise gateway

  Power Apps split by whether they connect through an on-premise data gateway.

• DLP policies by environment scope

  Distribution of Power Platform DLP policies across environment scopes.

• DLP policies by default classification

  DLP policies grouped by how they classify connectors by default.

• Apps using custom connectors

  Power Apps that depend on custom (non-Microsoft) connectors.

• Apps using on-premise gateway

  Power Apps that connect to on-premise data sources through a gateway.

• Apps shared with everyone

  Power Apps that are shared with all users in the tenant.