A pricing model that charges a flat fee for each enterprise identity-provider connection, regardless of how many users sit behind it. In practice, it aligns cost with customer count, which can make budgeting more stable for B2B SaaS teams that sell to a smaller number of larger accounts.
What per-connection pricing means in enterprise identity integrations
Per-connection pricing charges a fixed amount for each enterprise identity-provider connection, rather than for every end user behind that connection. For B2B SaaS buyers, it shifts the commercial unit from individual seats to customer-owned identity boundaries.
Why this pricing model changes buying and budgeting behavior
This model often feels more predictable because cost scales with the number of enterprise accounts or federation links, not with fluctuating employee counts inside those accounts. That can simplify forecasting for vendors selling into larger customers, but it can also make procurement discussions focus on architecture, tenant structure, and the number of integrations rather than pure headcount.
It is especially relevant where one customer may represent thousands of users but only one identity-provider relationship. In that setup, the price reflects integration footprint and contract value instead of internal adoption volume.
How per-connection pricing differs from user-based and platform-based models
User-based pricing charges by active or provisioned people, which can reward broad adoption but becomes harder to align with enterprise SSO and federation. Platform-based pricing usually bundles access to the whole service, while per-connection pricing isolates a specific infrastructure boundary, the identity connection itself.
That difference matters because identity integrations are not always proportional to usage. Two customers can generate the same user volume but require very different setup, support, and maintenance effort if their identity topologies, federation protocols, or governance requirements differ.
When per-connection pricing is a good fit, and when it is not
This model tends to fit products where the main delivery cost is associated with establishing and maintaining a secure enterprise connection, especially for SSO, directory sync, or federation-heavy deployments. It is less suitable when usage intensity, transaction volume, or feature consumption is the real cost driver.
Buyers should also watch for cases where “connection” is defined loosely, since a single enterprise account may contain multiple IdPs, tenants, or environments. Clear commercial definitions matter because ambiguity can create pricing disputes even when the technical integration is straightforward.
Risk and Threat Considerations
Per-connection pricing can create commercial pressure to minimise the number of identity integrations, which may tempt teams to over-consolidate access paths or treat a shared connection as a shortcut. That can increase operational dependency on a small number of federation links and make outages or misconfigurations more consequential.
Failure mechanism: If a connection becomes the billing unit, organisations may try to route multiple trust relationships through one shared integration or keep stale connections alive to avoid commercial churn. That increases blast radius when a connection is misconfigured, compromised, or not retired cleanly.
Impact: The result can be weaker access segmentation, harder offboarding, and a larger recovery burden if an enterprise IdP link, certificate, or trust configuration fails. Commercial incentives should therefore be balanced against identity architecture and lifecycle controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Per-connection pricing centers on enterprise identity-provider connections used for user authentication. |
| IA-5 — Authenticator Management | Identity connections depend on credentials, certificates, and lifecycle-managed authenticators. | |
| AC-6 — Least Privilege | Connection-based access decisions can expand blast radius if shared trust paths are overused. | |
| Recommendation — Align federation pricing with authenticated enterprise access paths and document who is covered by each trust relationship. Manage the credentials and certificates behind each connection with explicit rotation and retirement controls. Limit what each identity-provider connection can access and avoid broad shared trust scopes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | This pricing model is directly tied to enterprise identity connections and access governance. |
| GV.RM-01 — Risk Management Strategy | Commercial incentives can influence identity architecture and operational risk appetite. | |
| Recommendation — Map each priced connection to a controlled identity and access relationship with clear ownership. Include pricing-driven dependency and concentration risk in your governance review of identity integrations. | ||
Practitioner Guidance
Governance implication: Define “connection” precisely in the commercial and technical sense, including what counts as a separate IdP, tenant, environment, or federation trust. The cleaner that boundary is, the easier it is for sales, security, and procurement to avoid mismatched expectations.
What to watch for: Track whether pricing pressure is encouraging shared trust paths, delayed deprovisioning, or exceptions that would not be acceptable in a normal identity design review. A pricing model should not quietly reshape the organisation’s access architecture.
Related resources from NHI Mgmt Group
- What do teams get wrong about per-data AI SOC pricing?
- How should teams choose between AI models when per-token pricing looks misleading?
- Why do organisation membership changes create billing risk in per-seat pricing models?
- What is the difference between a flat AI security license and per-token pricing for investigation work?