Cloud Marketplace Purchasing Security: Private Offers, Subscriptions and the Roles They Create

Buying software through a cloud marketplace is quick, and that speed lets subscriptions, deployment templates and third-party access land in production accounts without passing through procurement, security review or identity governance. A marketplace purchase is rarely just a billing event. It can create service-linked roles, deploy templates that create IAM roles, give a publisher standing access to a resource group, or start a SaaS relationship that shares tenant details with the seller. This guide is for cloud platform, procurement and security teams who want marketplace buying governed like any other route to production. It covers who can buy, how to curate what can be bought, what each purchase type can create in your environment, and how to review and retire it. Platforms are listed alphabetically by provider: AWS Marketplace, Google Cloud Marketplace and Microsoft Marketplace (Azure). Order is never a ranking.

This is an independent guide from NHI Mgmt Group, based on the public documentation of AWS, Google Cloud and Microsoft as of November 2026. It is not sponsored or reviewed by AWS, Google or Microsoft. Role names and features change, so confirm settings against each provider's current documentation.

Key takeaways

• Purchase rights are privileged rights. The permission to subscribe commits spend and can trigger deployments, so give it to a small procurement role, not to every developer with broad console access.
• Curate before you open the store. Each platform has a private marketplace feature that limits new purchases to an approved list. Turn it on with a default collection or experience that covers the whole organisation.
• A curated catalogue governs buying, not deploying. Private marketplace controls stop unapproved subscriptions. They do not replace guardrails on what identities can create, so keep organisation policies and IAM controls in place.
• Every subscription can leave an identity behind. Deployment templates, service-linked roles, managed application publisher access and SaaS connectors are non-human identities. Inventory them, give each an owner and review them like any third-party access.
• Private offers move the risk into contracts. Negotiated terms, renewals and upgrades are accepted in the console. Decide in advance which account accepts them and who approves, and check the security terms before acceptance.

What a marketplace purchase can create

The security impact depends on the delivery model, not on the price. Map each model to the identities and access it can introduce before writing policy.

Treat every role or connector created by a purchase as a third-party non-human identity. See the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide and the Third-Party Access Guide for the wider lifecycle.

Who can buy: purchase permissions by platform

Start by separating three personas: people who browse and request, a procurement role that subscribes, and a curation administrator who decides what is approved. Each platform documents roles that support this split.

AWS Marketplace

AWS documents managed policies for buyers: AWSMarketplaceRead-only to view subscriptions, AWSMarketplaceManageSubscriptions to subscribe and unsubscribe, and AWSMarketplaceFullAccess for complete control of subscriptions. Two further managed policies, AWSPrivateMarketplaceRequests and AWSPrivateMarketplaceAdminFullAccess, cover users who request products and administrators of Private Marketplace. AWS recommends separate IAM roles per persona, each with the policy it needs, and custom policies for anything the managed policies do not fit. Viewing full subscription details also needs license-manager:ListReceivedLicenses.

Watch for: broad administrator policies that include aws-marketplace:* actions. Some AWS services start a marketplace subscription in the background when a user first calls a third-party model or product, so subscription permissions in a developer role are a purchasing right. The Amazon Bedrock Security Guide covers that case.

Google Cloud Marketplace

Google Cloud documents Consumer Procurement roles, including roles/consumerprocurement.orderAdmin to manage purchases, roles/consumerprocurement.orderViewer to inspect them, roles/consumerprocurement.procurementAdmin for purchases and consents at billing account and project level, and entitlement and licence pool roles. The order roles must be granted at billing account or organisation level. Google recommends the Billing Account Administrator role for users who purchase, and custom purchaser roles need billing.accounts.get plus consumerprocurement permissions such as placing orders and granting consents. Managing Private Marketplace needs roles/commerceorggovernance.admin with roles/resourcemanager.organizationViewer at organisation level.

Watch for: Billing Account Administrator is a powerful role that also controls billing account access. Where purchasers do not need that, build the custom purchaser role Google documents and keep billing administration with finance.

Microsoft Marketplace (Azure)

Buying a SaaS offer in the Azure portal needs a user with access to a subscription that handles billing and, to deploy into a resource group, at least Contributor on it. Microsoft documents a minimum custom role at subscription scope that can create a SaaS resource but not manage it, built from Microsoft.SaaS, Microsoft.Resources/deployments and Microsoft.MarketplaceOrdering agreement actions. Managing the private Marketplace needs the Marketplace Admin role, which a Global Administrator assigns at tenant scope.

Watch for: Contributor at subscription scope is common in engineering teams, and it is enough to purchase. Use the documented minimum custom role for a procurement group, and keep Contributor for deployment work under separate review.

Curating what can be bought: private marketplaces

All three platforms let administrators publish an approved catalogue so users can only subscribe to listed products, with a request route for anything else. These are customer-side settings: you decide the scope, the approved list and who approves.

AWS Marketplace: Private Marketplace

Private Marketplace uses experiences, each with its own approved products, associated with the whole organisation, organisational units or individual accounts. AWS recommends a default experience associated with the organisation root so that any OU or account without its own experience is still governed. It works through AWS Organizations integration, and the management account can register a trusted member account as delegated administrator so day-to-day curation does not use the management account. Users can request products, and Private Marketplace publishes Amazon EventBridge events when requests are created, approved or declined. AWS states that the website for managing Private Marketplace was scheduled for deprecation on 17 March 2026; manage it from the AWS Marketplace console, which needs an Organizations integration created from the management account.

Scope to know: AWS states that Private Marketplace governs new subscriptions, and changes to existing subscriptions, for products not approved in the governing experience. Usage of existing subscriptions, products whose terms are governed by the AWS Customer Agreement, and what can be deployed in accounts are governed through other controls, such as IAM policies and service control policies. Add products already in use to the approved list before turning governance on, and plan how to retire unapproved ones.

Google Cloud Marketplace: Private Marketplace

Google Cloud Private Marketplace uses collections shared with the organisation, folders or projects. Google's recommended setup is to create and publish a default collection, add further collections where needed, optionally turn on product requests, then turn on Private Marketplace at organisation level, after which users can deploy only products in collections shared with them. Since 26 March 2025 it can block new API deployments of unapproved third-party products, on by default for organisations that enable it after that date; organisations that enabled it earlier must upgrade to get that blocking.

Scope to know: Google documents which product types are in scope (Google-provided public images and datasets, Google-owned products and the API Library are among those managed elsewhere) and describes the service as fail open. For GKE images pulled by tag from repositories outside the marketplace, Google recommends Binary Authorization. Google also states that removing approval for a procurable Vertex AI model hides it in Private Marketplace while users can still procure it, so review model approvals before you grant them.

Microsoft Marketplace (Azure): private Marketplace

The private Microsoft Marketplace is created once per tenant and starts disabled with a Default Collection scoped to all subscriptions in the tenant, which cannot be renamed, rescoped or deleted. Administrators add further collections for chosen subscriptions, approve offers and specific plans within them, and can use rules such as auto-approving products under the Microsoft standard contract or all private products. Microsoft solutions and endorsed Linux distributions are approved by default and are not managed there. Users see approved items and submit requests with a justification; the Notifications centre shows approval requests and new or removed plans for approved offers. Enable the marketplace in Settings when the collections are ready.

Scope to know: the auto-approve rule for private products is on by default in new private Marketplaces. Decide whether privately negotiated plans should still pass a security review, and turn the rule off if they should.

Reviewing the access a purchase creates

The curated catalogue decides what may be bought. The review below decides what each product may do once bought. Run it before approval and again at each renewal.

AWS Marketplace

• Guided deployment: SaaS Quick Launch deploys CloudFormation templates that the seller provides and uses the AWSServiceRoleForMarketplaceDeployment service-linked role to manage deployment parameters stored as secrets in AWS Secrets Manager. Read the template before launch: list every IAM role and policy it creates and the principals in each trust policy.
• Cross-account roles: when a seller asks for a role it can assume, require an sts:ExternalId condition with a value the seller issues, as AWS recommends against the confused deputy problem, and scope permissions to the resources the product needs. See How to review AWS cross-account trust policies for confused deputy.
• Guardrails: keep service control policies and resource control policies in force for accounts that run marketplace products. See the AWS Organizations and SCPs Guide.

Google Cloud Marketplace

• Consents and entitlements: purchasing involves granting consents and managing entitlements for consumer projects. Grant entitlement manager roles only to the project owners who run the product, and use the viewer roles for audit.
• Project-level roles: Google lists products that need Project Editor in the project. Treat that as a broad grant: place such products in a dedicated project with its own billing and monitoring.
• Workload controls: for Kubernetes applications and container images, keep Binary Authorization and organisation policies in force alongside Private Marketplace, as Google recommends for images outside its blocking scope.

Microsoft Marketplace (Azure)

• Managed applications: the publisher's access to the managed resource group follows the role in the application definition, for example Owner or Contributor, and can be permanent or limited to a time period through just-in-time access. Check the permission scenario before purchase: publisher managed, publisher and customer access, locked, or customer managed. Prefer just-in-time access where the publisher offers it, and record the publisher identities that hold access.
• SaaS activation: after purchase you configure the account on the publisher's website, and Microsoft states that it is not responsible for the publisher site's content, security or privacy practices. Review any Microsoft Entra application consent the publisher requests as a separate third-party grant. See the Entra ID Applications and Consent Guide.
• Delegated management: where a publisher manages resources through Azure Lighthouse, review it as delegated access. See the Azure Lighthouse Security Guide.

Private offers, renewals and contract terms

Private offers carry negotiated pricing and licence terms that are not public. They are accepted in the console, which makes acceptance an access-controlled action with legal effect.

• Choose the accepting account. Where an organisation has several accounts or subscriptions, decide which one accepts private offers and keep that right with procurement, so negotiated terms are not accepted from an engineering account.
• Treat upgrades and renewals as new decisions. An accepted upgrade or renewal offer can change the terms that apply to an existing subscription, so review it as you would a new purchase and track renewal dates in the contract register.
• Review the security terms before acceptance. Download the licence terms, check data processing, breach notification, sub-processors and termination assistance, and record the security review against the offer, not only the product.
• Check auto-approval paths. If private products are auto-approved into a private marketplace collection, a negotiated offer can bypass curation. Route private offers through the same review queue.

For security clauses and assurance evidence, use the SaaS Security Guide and the Third-Party Attestation Comparison Map.

Detection and monitoring

Marketplace charges can be a security signal in their own right, so give third-party marketplace spend its own budgets and alerts. See Cloud Cost Anomalies as Security Signals and FinOps Security.

Rolling out marketplace governance

A phased rollout avoids breaking teams that already depend on marketplace products. The phases below are NHI Mgmt Group recommendations.

1. Inventory: export current subscriptions, agreements and private offers from every billing account, and list roles, service-linked roles, managed application access and SaaS connectors they created.
2. Assign owners: give each subscription a business owner and a technical owner, and record the data the product handles.
3. Split permissions: move purchase rights into a procurement role, and remove subscription actions from general engineering roles.
4. Build the default catalogue: add products already in use to the default experience or collection, so turning governance on does not disrupt them.
5. Turn on curation: enable the private marketplace and the request route, with a named approver group and a review checklist.
6. Review and retire: review approved products and the access they hold on a fixed cycle, our suggestion is quarterly, and before each renewal; remove products no one owns and delete the roles they left behind.

Common failure patterns

• Purchase rights inside administrator roles: anyone with broad console access can subscribe and commit spend.
• Curation without guardrails: a private marketplace is in place, but workloads can still deploy unapproved images or call third-party services that are out of its scope.
• Orphaned seller roles: a subscription is cancelled but the cross-account role, managed application access or SaaS connector remains.
• Templates launched unread: guided deployment creates roles with broad permissions and trust that nobody reviewed.
• Stale approved lists: products stay approved after the business need ends, which AWS addresses in its advice to audit experiences regularly.

Practitioner checklist

• Separate browse, purchase and curation roles on each platform and keep purchase rights with procurement.
• Remove marketplace subscription actions from general engineering and administrator roles where they are not needed.
• Create a default private marketplace experience or collection that covers the whole organisation before enabling it.
• Read every deployment template and list the roles, trust policies and service-linked roles it creates.
• Require an external ID and scoped permissions on any cross-account role a seller assumes.
• Prefer time-limited publisher access for managed applications and record publisher identities.
• Route private offers, renewals and upgrades through security and contract review before acceptance.
• Alert on subscription, approval and private marketplace changes, and on unexpected marketplace charges.
• Review approved products and their access on a fixed cycle and remove leftover roles after cancellation.

Standards and references

• AWS: Controlling access to AWS Marketplace subscriptions
• AWS: Private Marketplace
• AWS: Private Marketplace best practices
• AWS: The confused deputy problem
• Google Cloud: Access control for Cloud Marketplace
• Google Cloud: Private Marketplace
• Microsoft: Create and manage private Microsoft Marketplace
• Microsoft: Azure Managed Applications overview

Related NHI Mgmt Group resources: Cross-Account and Cross-Tenant Access Guide · Shadow SaaS and Unsanctioned App Discovery Guide · SaaS Security Policy Template · Third-Party Access Guide