Microsoft Power Pages Licensing: Authenticated Users, Anonymous Sessions, and How to Stop Overpaying

The Core Licensing Problem with Power Pages

Power Pages (formerly Power Apps Portals) solves a real business problem: it allows organisations to build external-facing websites connected to Dataverse and backend Microsoft data sources without requiring a traditional development team. The licensing model that governs Power Pages, however, is unlike anything else in the Microsoft portfolio — and that unfamiliarity is expensive.

Most enterprise teams discover Power Pages costs by accident: a digital team builds a supplier portal or customer self-service site, adopts it enthusiastically, and then receives a renewal or true-up invoice that bears no relationship to the original budget estimate. The reason is almost always the same: someone assumed Power Pages was covered by existing Power Platform licences, or sized the commitment based on the wrong user type (authenticated vs anonymous), or failed to model peak session volumes.

This guide explains how Power Pages licensing actually works, what is genuinely free, what each capacity unit costs, how to model requirements accurately before you commit, and how to negotiate Power Pages capacity into your EA at appropriate commercial terms.

What Power Pages Is — and Is Not — Included In

The first thing to establish clearly: Power Pages is not included in any Microsoft 365 plan, any Power Platform per-user licence, or any Dynamics 365 plan. It is always an additional purchase. There is no "free tier" for production external-facing portals, though internal portals for licensed Power Platform users have different economics (more on that below).

This is one of the most common misunderstandings. Organisations with Power Apps per-user or per-app licences sometimes assume that portals are included. They are not. The confusion arises partly because Power Pages development and design can be done within an environment licensed for Power Platform — you can build the portal without a specific licence — but publishing it and allowing users to access it requires capacity entitlements that are purchased separately.

The Internal vs External Distinction

There is one important free scenario: internal employee portals where all users hold a qualifying Power Apps or Dynamics 365 licence. If every user who will access a Power Pages site is an internal employee with a Power Apps per-user or Dynamics 365 Enterprise licence, those users can access the portal without additional Power Pages capacity. This is because their existing licences already include the entitlement to use Power Platform applications, and an internal portal is treated as an application under that framework.

The moment even one user of the portal is external — a customer, supplier, partner, or anonymous member of the public — Power Pages capacity licensing applies. Given that most Power Pages use cases involve at least some external access, the practical scope of free internal portal usage is narrower than it appears.

The Two Power Pages User Types and Their Pricing

Power Pages capacity is purchased in two distinct pools: authenticated users and anonymous users. These pools are not interchangeable — you cannot apply anonymous session capacity to authenticated user visits, or vice versa. Buying the wrong mix is one of the most common Power Pages over-spend patterns.

Authenticated User Capacity

Authenticated users are individuals who log into your Power Pages site with a verified identity — typically via Entra ID (AAD), social providers (Google, Facebook), or a local username and password. The licensing metric for authenticated users is per authenticated user per month, measured at the tenant level across all Power Pages sites.

Authenticated user capacity is purchased as a monthly pool. As of 2026 EA pricing, authenticated user capacity is approximately £0.90–£1.10 per user per month depending on volume tier and whether purchased as a standalone add-on or bundled into an EA commitment. At list price, Microsoft charges $5/100 authenticated users/month in capacity packs, which at EA discounts typically translates to the range above for UK organisations.

The key planning consideration for authenticated users: this is measured by the number of unique authenticated users who access any Power Pages site in your tenant during the month — not by the number of sessions, page views, or time spent. A user who logs in once counts the same as a user who logs in daily. This means authenticated user capacity is relatively predictable if you know your user population, but you must account for the full population, not just active users in a given month.

Anonymous User Capacity

Anonymous users are individuals who access your Power Pages site without authenticating — public-facing websites, product catalogues, public knowledge bases, and submission forms where the user does not need a login. Anonymous user licensing is per login/session, not per unique user, which creates significant modelling complexity.

A single visitor who makes three separate visits in a month counts as three anonymous sessions. A visitor who fills in a form, leaves, and returns the following day counts as two sessions. This session-based model creates substantial variability risk for high-traffic external sites — a marketing campaign, a product launch, or a regulatory filing deadline can spike session counts far above baseline assumptions.

Anonymous capacity is purchased in packs. Current EA pricing is approximately £0.020–£0.028 per session at volume. At list price, Microsoft charges approximately $100 per 1,000 anonymous logins/month in capacity blocks. For public-facing sites with meaningful traffic, this can accumulate rapidly: a site with 50,000 monthly sessions costs approximately £1,000–£1,400 per month in anonymous capacity alone.

Dataverse Storage: The Hidden Third Cost

Most Power Pages cost models focus on user and session capacity and miss the third cost driver: Dataverse storage. Power Pages sites connect to Dataverse tables for their data, and every record created, updated, or read through the portal consumes Dataverse database, file, and log storage.

For portals that process transactions — customer registrations, application submissions, support cases, supplier onboarding records — Dataverse storage consumption can be substantial. A portal processing 10,000 records per month at 50KB average record size adds 500MB of Dataverse database storage per month. At approximately £0.030–£0.035/GB/month for Dataverse database storage overage, this becomes a material ongoing cost for active transactional portals.

The mitigation is straightforward but requires advance planning: model Dataverse consumption as part of the initial capacity sizing, include storage add-on in the EA negotiation, and implement data retention policies that archive or delete records beyond operational necessity. Organisations that implement archival policies on portal-generated data typically reduce Dataverse storage costs by 40–60% compared to organisations with default retention settings.

For detail on Dataverse storage architecture and capacity optimisation, see our Dataverse Capacity Licensing guide.

Power Pages Capacity Modelling: The Five Variables

Accurate Power Pages capacity modelling requires five variables. Missing any one of them typically leads to either over-commitment (wasted budget) or under-commitment (overage exposure during true-up).

Variable 1: Authenticated User Population

The total number of individuals who will be registered on your portal(s), not the number of active monthly users. If your supplier portal will have 2,000 registered suppliers, you need authenticated user capacity for 2,000 — even if only 400 of them log in actively in a given month. Registration alone triggers the capacity requirement in Microsoft's model.

Variable 2: Monthly Anonymous Session Volume

Sessions per month at baseline, plus modelled peaks. For a public-facing site with marketing campaign exposure, peak sessions may be 5–10 times baseline. Your capacity commitment should cover the 95th percentile of expected monthly sessions to avoid overage charges, not the median. Sessions from automated testing tools and synthetic monitoring count; configure your analytics to exclude known non-human traffic from capacity planning estimates.

Variable 3: Portal Count

Power Pages capacity is pooled at the tenant level — a single authenticated user capacity pool covers all sites in the tenant. However, each separate site (production site) requires its own environment in Power Platform, and each production environment has associated infrastructure costs. For organisations deploying more than two or three sites, the management overhead and environment costs should be factored into total cost of ownership.

Variable 4: Dataverse Storage Per Transaction

Average record size multiplied by monthly transaction volume, aggregated across all portal sites. For portals handling file uploads (application forms, evidence submissions, supplier documents), file storage consumption can dwarf database storage. Model file and database storage separately; they have different overage rates and different solutions.

Variable 5: Growth Rate

Power Pages portals often grow faster than initial projections, particularly customer or partner portals that gain traction after launch. Negotiate a 24-month capacity commitment with annual true-up provisions rather than a monthly variable model. Annual true-up protects against short-term spikes while providing a correction mechanism for sustained growth. Monthly variable billing with no commitment provides flexibility but eliminates negotiating leverage and often results in higher average unit costs.

Power Pages vs Alternatives: The Build Decision

Power Pages is not always the right tool, and the licensing economics should inform the build decision alongside the capability assessment. For many enterprise use cases, there are three alternative approaches worth evaluating before committing to Power Pages capacity at scale.

The decision rule is straightforward: if your portal is primarily a front-end to Dataverse data, a workflow-driven transactional process, or needs to be built and maintained by a team with low development expertise, Power Pages is commercially viable. If your portal is primarily content-driven with high anonymous traffic, or requires design flexibility that Power Pages cannot provide, Azure Static Web Apps or a third-party CMS will typically deliver better cost-per-session economics at scale.

EA Negotiation Strategy for Power Pages

Power Pages is frequently purchased reactively — after a portal is built and already in production, procurement is handed an invoice and asked to negotiate from a position of zero leverage. The correct approach is to include Power Pages capacity in EA negotiations proactively, before the portal goes live.

Bundling with Power Platform EA

Power Pages capacity purchased as part of a broader Power Platform EA commitment consistently achieves 15–25% better unit pricing than standalone purchases. The mechanism is straightforward: your Power Platform spend (Power Apps per-user, Power Automate per-user, Power BI, Dataverse add-ons) contributes to your overall EA volume and therefore your platform discount tier. Power Pages capacity should be negotiated as part of this portfolio, not as a separate line item.

If your organisation is in the process of Power Platform adoption, negotiate Power Pages capacity as a forward commitment with deployment milestones — committing to the capacity at the point of portal design, not at the point of production launch. Microsoft account teams will accept this structure because it locks in revenue before the portal is complete; you benefit because you negotiate before you have usage data that would confirm your dependency.

Authenticated vs Anonymous Mix Negotiation

The authenticated/anonymous split is commercially significant because the two pools have different pricing leverage profiles. Authenticated user capacity is predictable and relatively low-risk for Microsoft, making it easier to negotiate on unit price. Anonymous session capacity is variable and harder for Microsoft to model, making Microsoft more willing to offer overage protections and rate commitments than to discount the headline price.

For anonymous sessions, the priority negotiation targets are: (1) an overage rate cap — so that sessions above committed capacity are charged at the same unit rate as in-commitment sessions, not at list price; (2) a carry-forward provision — unused monthly capacity can apply to subsequent months within the annual term; and (3) a growth true-up at Year 1 — the ability to increase your committed capacity block at mid-year pricing rather than waiting for renewal.

Competitive Leverage

Portals are a competitive market. Salesforce Experience Cloud, ServiceNow Customer Service Portal, and pure-play portal platforms like Bynder, Kentico, and Sitecore all serve similar use cases. If Microsoft cannot provide commercial terms that make Power Pages economically competitive with Azure Static Web Apps plus a modest development investment, the business case for Power Pages deteriorates rapidly.

The effective competitive lever is not to threaten replacement of an existing portal — that is costly and disruptive — but to decline to expand Power Pages to additional use cases pending satisfactory commercial terms. An account team that sees 3–5 additional portal projects in your pipeline will negotiate differently than one that believes they have captured the whole requirement.

Common Power Pages Licensing Mistakes

Mistake 1: Assuming M365 or Power Apps Licences Cover External Portal Access

They do not. Any external user access requires Power Pages capacity. The only exception is internal employee access where every accessing user holds a qualifying Power Apps or Dynamics 365 licence — and even this requires careful verification that the licence type is qualifying (per-user Power Apps, not per-app, and not Teams-limited plans).

Mistake 2: Sizing on Average Monthly Sessions Rather Than Peak

A supplier portal with 8,000 average monthly sessions but 45,000 sessions during annual contract renewal season needs capacity sized for 45,000, not 8,000. Model P95 session volumes, not mean volumes. For new portals with no historical data, add a 3x buffer above projected average during the first year — you can reduce committed capacity at annual true-up once actual patterns are established.

Mistake 3: Treating Authenticated and Anonymous Pools as Interchangeable

They are separate pools. Over-buying authenticated capacity does not provide protection against anonymous session overages. Ensure your capacity model separates the two accurately, and negotiate each pool's terms independently.

Mistake 4: Forgetting Dataverse Storage in the Total Cost Model

A portal that processes 50,000 form submissions per month, each with three 500KB file attachments, is adding 75GB of Dataverse file storage per month. At current EA pricing, that is approximately £900–£1,125 per month in storage costs that typically does not appear in initial portal budget calculations. See the Power Platform cost control guide for storage management approaches.

Mistake 5: Not Including Power Pages in EA Renewal Preparation

Power Pages is often managed by digital or product teams, not IT procurement. When EA renewal negotiations begin, the commercial team frequently does not know the organisation has Power Pages commitments, what the current usage is, or what the growth trajectory looks like. Ensure Power Pages appears in your EA renewal preparation inventory — capacity commitments, actual usage, and planned portal pipeline — at least 18 months before renewal.

Power Pages and Dataverse Integration Architecture

Power Pages connects to Dataverse as its primary data source, and the architectural decisions made at portal design time have direct licensing cost implications. Several patterns are worth understanding before you build.

Portal tables in Dataverse should be modelled to minimise Dataverse database row counts. Using status flags and archiving completed records rather than retaining all historical data in active tables reduces database storage consumption and improves portal query performance. For portals that process document-heavy workflows, store binary files in Azure Blob Storage and reference them from Dataverse rather than storing files directly in Dataverse file columns — this reduces Dataverse file storage consumption and typically reduces costs by 60–70% for document-intensive use cases.

Integration with other Dataverse-backed applications (Dynamics 365, Power Apps model-driven apps) should use shared Dataverse environments where possible. Each additional production environment in Power Platform incurs independent Dataverse capacity consumption and management overhead. Design your portal environment architecture to consolidate capacity rather than fragment it across multiple environments.

Summary: Power Pages Licensing Decision Framework

Power Pages is a commercially viable tool for Dataverse-connected external portals when the licensing economics are modelled accurately and negotiated proactively. The organisations that overpay are those that discover the cost after the portal is in production, build their EA commitment around average rather than peak usage, and treat Power Pages as an afterthought in Power Platform governance.

The organisations that extract value from Power Pages licensing do three things differently: they model authenticated and anonymous capacity separately with peak buffers, they negotiate Power Pages as part of the broader Power Platform EA portfolio before production launch, and they implement Dataverse storage governance from day one rather than discovering storage overages at true-up.

Frequently Asked Questions

Does Power Pages require a separate licence for every Power Pages site?

No. Capacity is pooled at the tenant level — a single authenticated user capacity pool and a single anonymous session capacity pool cover all Power Pages sites in your tenant. However, each production site requires its own Power Platform environment, which has separate Dataverse storage allocation and management considerations.

Can I use Power Pages with a Power Apps per-app licence?

Power Apps per-app licences do not include entitlement for external portal access. Internal employees accessing a portal may be covered if the per-app licence covers the specific portal application, but this requires careful verification. External users always require Power Pages capacity regardless of the portal host's licensing.

Is Power Pages capacity included in any Dynamics 365 plan?

The Dynamics 365 Customer Service Enterprise licence includes entitlement to one Power Pages site specifically for Customer Service self-service scenarios. This entitlement is limited in scope — it covers the standard Customer Service portal configuration, not general-purpose portal development. For any use case beyond Customer Service self-service, separate Power Pages capacity is required.

How is Power Pages licensing enforced — will my portal go offline if I exceed capacity?

Microsoft does not enforce capacity limits by taking portals offline. Exceeding committed capacity results in overage charges billed at list price. Portals remain accessible. This means you will not receive an availability incident if you exceed capacity — you will receive an unexpected invoice. This is why capacity modelling and overage rate protections in your EA are more important than buffer headroom on committed capacity.

For assistance modelling Power Pages capacity requirements and negotiating appropriate commercial terms in your EA, engage our team. We have structured Power Pages commercial terms for organisations ranging from single-portal deployments to enterprises with 15+ active portal sites across global operations.