From February 2027, Microsoft plans stricter licence checks when people open Power Apps applications in managed environments. The underlying requirement is not new: Managed Environments already require appropriate standalone licences or supported capacity and pay-as-you-go entitlements for active use. What changes is enforcement. After notifications, a user without the right entitlement will be unable to open the app until a suitable licence is detected. Microsoft explains the change, including the administrator and end-user experiences. IT teams need to distinguish where an app runs, who actually uses it and what that specific person is licensed to do, rather than looking only at connector names.
Timeline: existing obligation, stronger enforcement
According to Microsoft, administrator notifications began in March 2026 and in-app end-user notices in June 2026. Starting February 2027, a user without an appropriate licence can be blocked when opening an app in a Managed Environment. The app is not deleted; access resumes once the right entitlement is recognized. This is why waiting for the first production incident is poor preparation. Use the remaining months to identify usage, correct assignments, secure capacity and explain the support route. Follow the current Microsoft documentation for any schedule or wording changes rather than treating an old internal notice as the licensing authority.
Environment and active use determine scope
In a Managed Environment, every person who actually runs an app is in scope, including a user of an otherwise standard canvas app. The condition is not limited to premium connectors. Managed Environments carry their own governance capabilities and Microsoft defines an entitlement for active use in that context. Merely being able to enter an environment does not establish the right to run an app. Conversely, an administrator who manages the environment but does not use a particular app should not automatically be counted in the same way as an active user. Connect the environment inventory with app launch data and actual assigned licences.
A standard app can still need a premium entitlement
A common surprise is a standard app hosted in a Managed Environment. The team may assume Microsoft 365 seeded rights are enough because the app does not use SQL Server or Dataverse. Microsoft explicitly says the managed-environment requirement includes users who run standard apps. Assess the app capability and the environment status separately. The same app can have a different licensing answer in another context. Moving it out of Managed Environments solely to avoid a licensing check could remove the governance controls that motivated the managed setting. Make such a design decision deliberately, with the app owner and security team, rather than as an emergency workaround.
| Scenario | Check | Risk if unresolved |
|---|---|---|
| Standard canvas app | Managed Environment status and actual launchers | Unlicensed user may be blocked from opening it |
| Model-driven app | Premium use rights for every active user | Microsoft 365 seeded rights alone may be insufficient |
| App with Dynamics 365 rights | Context of the licensed Dynamics app and environment | Usage outside that context can need separate rights |
| Pay-as-you-go capacity | Correct meter and allocation for the use case | One meter does not automatically cover another service |
Which licensing routes may satisfy the requirement
Microsoft names Power Apps Premium, selected Power Automate Premium entitlements and suitable Dynamics 365 licences with the relevant rights among the possibilities. Per-app options and Power Apps pay-as-you-go can also satisfy Power Apps use when configured for the correct scenario; capacity plans must be allocated as required. This does not mean every Dynamics licence or every meter covers any application. Use rights differ by product and context. The current Microsoft licensing page and the Power Platform Licensing Guide linked from it should decide the exact SKU, not a generic internal price sheet. Recheck before committing a large purchase.
Dynamics 365 rights have an application context
A Dynamics 365 licence may include Power Apps rights, but those rights are not a universal pass for every custom app. Microsoft describes use in the context of the licensed Dynamics 365 application and in the same environment. A custom app opened outside that context can require separate Power Apps licensing. For every user group, record which Dynamics application is licensed, where the team works and why the custom app is part of that workflow. Do not infer entitlement merely because any Dynamics 365 product appears in the user’s licence list. The Power Apps licensing FAQ highlights this distinction and other context-dependent cases.
Review Power Automate flows separately
The same environment may also contain cloud flows. Microsoft says a person using an app and a cloud flow in a Managed Environment does not necessarily need both Power Apps Premium and Power Automate Premium merely for the Managed Environments entitlement; one suitable premium licence can satisfy that layer. This is not permission to assume that a Power Apps per-app pay-as-you-go meter covers all Power Automate activity. Microsoft explicitly says that meter covers Power Apps usage, while cloud-flow usage needs its own appropriate entitlement. Add flow triggers, owners and business processes to the inventory alongside the apps. Some flow rights also depend on whether the flow is in the context of an app.
Use the users-requiring-licences report as a starting point
The Power Platform admin center provides a Users requiring licenses in Managed Environments report. Microsoft says it lists unique people who opened an app in a Managed Environment without an appropriate entitlement in a selected month, together with the environment and app. It is not a complete list of future users: a person who did not launch the app that month may not appear. A newly licensed user can remain in the report until they launch an app again. Reconcile the export with app owners, planned access and assignment state. A blank report for one month is not a definitive certification of compliance.
Assign by role rather than by the latest error
Build groups around work patterns: ongoing users of several apps, one-app users, occasional roles, Dynamics users and administrators. Verify a qualifying licensing route and volume for each group; compare per-user, per-app and pay-as-you-go where they are genuinely supported. Assignments can be completed before February 2027 so critical apps do not wait for a failure. Microsoft also mentions auto-claim for active users, but that depends on sufficient licence capacity and well-defined policy. Without owners and exception records, automation becomes an opaque purchasing mechanism. Keep the relationship between job role, app and entitlement understandable to both IT and procurement.
- 01
Map environments
List Managed Environments, app owners and critical business processes
- 02
Gather usage
Download the report across several periods and add planned users who have not launched an app yet
- 03
Determine rights
Check the specific licence, capacity or meter and any Dynamics context for each role
- 04
Assign and test
Open apps with pilot accounts after changes and test dependent flows
- 05
Prepare support
Define who handles requests, access blocks and the monthly report review
A pilot should simulate a real working day
Select apps whose outage would halt operations and a few less critical scenarios. Pilot accounts should represent real roles: a standard-app user, a model-driven app user, a Dynamics entitlement holder, someone covered by capacity and a deliberately unlicensed user. Test launch in the browser and normal client, downstream flows, licence assignment and a fresh sign-in. Record environment, app, role, entitlement type and time for every result. Successful access under a trial is not proof that the same route will work after the trial expires. Revisit the pilot after any change to environment type or app dependencies.
What happens at an access block
A user without the right licence sees an in-app notice and an option to request a licence from an administrator. Microsoft describes informational, warning and error stages; from February 2027 the final stage can prevent opening the app. Administrators can act on requests in the Power Platform admin center or Microsoft 365 admin center. Train the service desk not to bypass the incident by moving the app or sharing an account. It should identify the Managed Environment, app, user entitlement and whether a new assignment has propagated. The app remains in place, and access should be recoverable once the suitable entitlement is recognized.
Keep the licensing inventory alive after February
This is an operating change, not a one-off licence purchase. A new employee may start using an app, a Dynamics role may move outside its original context, or an owner may move an app into a Managed Environment. Each such event needs an entitlement check before launch. Monitor usage reports, licence requests, meter capacity, expiring trials and flow dependencies. Audit assignment and removal against actual work. Maintain the view jointly with the Power Platform team, app owners, procurement and support so that a later access failure can be diagnosed with context instead of an improvised purchase.
Frequently asked questions
Does the licensing obligation begin only in February 2027?
No. Microsoft says the appropriate entitlement is already required. February 2027 brings stronger enforcement when apps are opened in the affected scenarios.
Does a user of a standard app need a licence?
Yes, when that user actively runs it in a Managed Environment. The environment matters as well as the app connectors.
Is any Dynamics 365 licence enough?
No. Rights vary by product and usage context. A custom app outside the licensed Dynamics context can need separate Power Apps rights.
Does an access block delete the app?
No. Microsoft says the app remains in the environment and access can resume after an appropriate licence is detected.
