Power Apps Component Framework (PCF) is the TypeScript / React extensibility model for Power Apps. PCF code components themselves do not change the licensing posture of a Power App — the underlying app still licenses per-user ($20/month), per-app ($5/user/app), or against the M365 seeded entitlement. What PCF does change is exposure to the Premium Connector trap. A code component that calls an external API, a custom connector, or any non-Standard data source escalates the entire app into Premium-licensing territory for every user that touches it. PCF is a procurement risk amplifier, not a licensing surface in its own right. The audit defence is a component-by-component connector inventory tied to each app’s licensing model.
What PCF licenses (and what it doesn’t)
Power Apps Component Framework licensing is one of the most misunderstood corners of the Power Platform commercial surface. PCF itself is a developer SDK — the TypeScript / React framework Microsoft ships for building custom visual controls that drop into model-driven Power Apps and canvas Power Apps. PCF code components do not carry a separate licence. There is no "PCF SKU" in the Microsoft price list. What carries the licence is the Power App the component sits inside, and the way the component connects to external systems.
That nuance matters because most enterprise procurement teams treat PCF as licence-neutral — "it’s just custom UI" — and then run into the Premium Connector escalation rule. The escalation rule is unambiguous: if the code component calls a Premium Connector, a custom connector, the HTTP action, or any third-party REST endpoint through a connector wrapper, every user of the app requires a paid Power Apps per-user ($20/month) or per-app ($5/user/app) licence. The M365 seeded entitlement does not cover Premium Connector use under any wrapping, including PCF.
The seeded entitlement boundary
The M365 E3 and E5 seeded Power Apps entitlement covers a narrow set of scenarios: canvas and model-driven apps connecting to Standard connectors only. Standard connectors include SharePoint, Outlook, OneDrive, Teams, Excel Online, Planner, Stream, and a small handful of Microsoft surfaces. Any app that touches Dataverse, SQL Server, Azure Data Lake, Salesforce, ServiceNow, SAP, Oracle, HTTP, custom connectors, or a third-party SaaS provider through a connector requires explicit Power Apps licensing for every user.
PCF components routinely cross that boundary. A code component that renders a custom chart by calling a REST API is using HTTP — Premium. A code component that pulls data from an Azure SQL database through a Dataverse virtual table is using SQL — Premium. A code component that authenticates a user against a third-party identity provider is using a custom connector — Premium. The licensing model does not care that the call is wrapped inside a TypeScript control instead of a Power Fx formula; the connector use is what triggers the escalation.
If any PCF component in your estate makes a network call to a non-Microsoft endpoint or to a Premium connector, every viewer of the containing app is unlicensed under the seeded M365 entitlement. The audit exposure compounds across every embedding of that component.
The three PCF licensing models in practice
| Component pattern | Required licence per user | Per-user cost | Buyer’s notes |
|---|---|---|---|
| Pure UI, no network call | M365 seeded entitlement | $0 incremental | Display-only controls (formatted text, chart of in-context data, custom drag-and-drop). Safe under seeded entitlement. |
| Standard connector data | M365 seeded entitlement | $0 incremental | Reading SharePoint, Outlook, Teams data through the host app’s Standard connector context. Safe under seeded entitlement. |
| Premium connector / HTTP / custom | Power Apps per-user OR per-app | $5–$20/user/month | The Premium escalation. Mandatory for every user touching the app, not just developers. |
The "per-user vs per-app" decision below the escalation line follows the same breakeven equation we cover in the Power Platform Licensing Guide: four apps per user is the breakeven against $20/user unlimited. For PCF-heavy estates the breakeven shifts toward per-user because PCF components are typically reused across multiple apps, which raises app density per user.
Power Apps developer licensing for PCF authors
PCF authors do not require a separate developer SKU. The free Power Apps Developer Plan covers PCF development for individual developers building components for their own learning or for ISV development cycles. For enterprise developers building production components, the licensing path is one of (1) a Power Apps per-user licence for the developer ($20/month) which permits both development and runtime use, (2) a Visual Studio subscription that bundles Power Apps developer entitlements, or (3) the M365 seeded entitlement when the components are non-Premium.
The trap in the developer path is the test-environment-vs-production-environment boundary. Components developed against a Premium connector in a developer environment may run fine for the developer who holds a per-user licence, but the moment those components ship to production and end users start using them, every end user requires the same per-user or per-app licence. The developer’s licence does not grant runtime entitlement for end users. We see this gap exploited in every PCF-heavy estate we have audited.
EA negotiation levers for PCF estates
- Component inventory disclosure. Walk into the renewal with a documented connector list per PCF component and per host app. The licensing case Microsoft will make turns on Premium Connector exposure; documented inventory neutralises the case at the table.
- Component reuse credit. When a single PCF component is reused across many apps, negotiate the per-user pricing against the union of unique users, not the sum of users-per-app. The LSP default is the sum; the buyer’s default is the union.
- Step-up from seeded. If a portion of the estate is escalating out of the M365 seeded entitlement because of new PCF components, Microsoft typically offers a step-up path that is cheaper than retroactive per-user licensing. Capture before the audit cycle starts.
- Per-app coverage for utility components. Single-purpose utility components used in narrow departmental apps are almost always cheaper licensed per-app than per-user. Segment the population by app density before accepting the LSP’s quote.
- ISV licensing for embedded PCF. ISVs distributing PCF components to customers through AppSource need an ISV licensing arrangement, not enterprise per-user licensing. Microsoft surfaces both options at quote time; only one is correct for an ISV scenario.
Anonymised case study: $720K PCF audit settlement
A 6,500-employee professional services firm built a PCF-heavy Power Apps estate over four years: 47 model-driven apps with 22 reused PCF components, ten of which made calls to Azure SQL Server through Dataverse virtual tables, six of which called the firm’s ServiceNow tenant through a custom connector, and four of which made authenticated HTTP calls to a third-party document management system. The estate ran for 18 months against 6,200 internal users on the M365 E3 seeded entitlement with no Power Apps per-user or per-app coverage. A scheduled Microsoft licensing review surfaced the Premium Connector exposure. The initial Microsoft licensing shortfall claim: $1.42M annualised across 6,200 users at the per-user rate. We audited the actual app-and-user mapping: of 6,200 users, 4,800 were on a single high-traffic app (cheaper per-flow logic re-platformed to per-app at $5/user/app saved $1.55M against $20/user); 1,100 were on three or fewer apps (per-app at $5/user/app); 300 were makers and high-density users (per-user). Final settled annualised licensing: $700K. The Premium Connector exposure was resolved inside the EA amendment with no retroactive penalty. Net savings against the initial Microsoft position: $720K annualised.
PCF is the licensing surface where the most expensive Power Platform mistakes hide because the framework is engineering-led and procurement rarely sees the connector list. Pair a quarterly PCF component inventory with the broader Power Platform Licensing Guide discipline and a clear position on the 2026 EA tier-collapse landscape, and the Power Apps Component Framework stops being an audit-exposure vector and starts being a managed line in the renewal model. For the broader Copilot Studio context that increasingly intersects with PCF, see our Copilot Studio 2026 pillar.