🛒🧑💼OS - User-Owned Apps and Services
Take the shopping trip off the menu: no store add-ins, no self-started trials, no credit-card licenses spun up behind your back.
What this policy is about 🛒
Every tenant ships with the shop open, the lights on, and nobody at the register. A user can wander into the Office Store, bolt a third-party add-in onto their mailbox, start a trial of a service you have never heard of, and put a real subscription on a real invoice, all before the coffee goes cold and all without an admin, a ticket, or a heads-up.
This tile is where two of those doors live, and a third hides one module over:
- Let users access the Office Store. The on-ramp to the Marketplace, where anyone can grab and install add-ins for Word, Excel, PowerPoint and Outlook.
- Let users start trials on behalf of your organization. The button that quietly spins up a trial subscription in your tenant, in your name.
- Self-service purchase. The one that is not on this tile at all. Buying Power BI, Power Apps, Power Automate, Copilot, Project or Visio on a card lives in the commerce module, per product, and it ships wide open.
This page shuts all three and keeps the single honest use case, the add-ins you actually vetted, on a path you control.
"User-owned" is the polite phrasing. What it means is that a random Tuesday-afternoon click can grant a third party standing access to a mailbox, land company data in a service with no DLP and no backup, or start a bill nobody approved. Self-service is a feature for the vendor and a gap for you.
Why this matters 🕵️
Three doors, three different ways the day goes wrong.
Store add-ins are OAuth apps wearing a productivity costume. 🧩 When a user clicks Add on a store add-in, they are often consenting to permissions: read this mailbox, read the documents I open, talk to this outside service. The consent screen is three lines of grey text between the user and "get back to work," so it gets the same read every consent screen gets, which is none. The add-in then runs inside the client, can move content out, and holds a token that a password reset does not touch. Consent-phishing has worn the add-in costume for years precisely because the Store makes granting access feel like installing a helpful gadget. And even the honest vendors are a supply chain: their breach becomes your breach, on your data, through a door you left open. This is the client-side cousin of blocking user consent for applications; the Store is just the friendliest place to walk through it.
Trials are shadow IT with an expiry date that nobody reads. ⏳ A user starts a trial, and suddenly there is a live service in your tenant holding real data, with no retention policy, no DLP, no conditional access story, and no line in your offboarding runbook. When the trial ends, one of two things happens, and both are yours to clean up: the data strands, or someone waves the "but we already use it" business case and the trial converts to a purchase you never scoped. Either way the decision got made by whoever had a deadline, not by whoever owns the tenant.
Self-service purchase is a bill and a data estate you didn't approve. 💳 Give it a default tenant and a credit card, and a user can stand up Power BI or Power Automate in an environment you do not manage, wire it to company data, and hand you the governance problem after the fact. You inherit the licenses, the renewal, and the ungoverned Power Platform environment, frequently without owning the subscription that spawned it. Microsoft keeps adding products to this list, and each one arrives with the door open.
The reason closing all three is an easy call: the legitimate version of each already has a better home. The add-ins you want get pushed centrally. The services you want get bought properly, in a governed environment. What you are switching off is the self-service path, not the capability.
🛠️ Configuration
Three levers in two places. The admin center handles the Store and trials; the commerce module handles purchase. Do all three, because a tenant that blocks the Store but leaves self-service purchase open has locked the front door and left the garage up.
Microsoft 365 admin center
Where: Microsoft 365 admin center → Settings → Org settings → Services tab → User owned apps and services.
Role: Global Administrator or SharePoint Administrator can set this tile. Prefer the narrower one.
| Setting | Value | Why |
|---|---|---|
| Let users access the Office Store | Unchecked | Blocks user-initiated add-in acquisition from the Marketplace across Office apps. Admin-deployed add-ins are unaffected. |
| Let users start trials on behalf of your organization | Unchecked | Stops users spinning up trial subscriptions in your tenant, in your name. |
Click Save. Tenant-wide, effective on the next client refresh.
Self-service purchase (Exchange it isn't, commerce it is)
The purchase door is not on the tile. It lives in the commerce module, it is set per product, and new products land Enabled, so this is a recurring job, not a one-time flip.
Install-Module -Name MSCommerce
Import-Module MSCommerce
Connect-MSCommerce
# Where are the doors currently open?
Get-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase |
Format-Table ProductName, ProductId, PolicyValue
# Shut every product that isn't already shut.
Get-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase |
Where-Object { $_.PolicyValue -ne 'Disabled' } |
ForEach-Object {
Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase `
-ProductId $_.ProductId -Value 'Disabled'
}
Note -Value 'Disabled', not a boolean. And note the loop: you cannot disable "all self-service purchase" with one switch, you disable each product, which is exactly why a new product Microsoft adds next quarter arrives open and stays open until this runs again.
The add-in sledgehammer you do not pick up 🔨
There is a tempting one-liner in Exchange Online that looks like the real off switch:
# Do NOT run this as your control.
# Set-OrganizationConfig -AppsForOfficeEnabled $false
It overrides every admin and user add-in setting and stops every new add-in from activating for everyone, including the vetted ones you deployed on purpose. Microsoft flags it as not recommended, and for once that label is right. The correct lever is the Store checkbox above: it closes the self-service on-ramp while leaving centralized deployment fully working. Block the shopping trip, not the supply chain you actually manage.
The paths that stay open ✅
Switching self-service off is only defensible because the real needs have better homes. Point people at them in the same breath, or the checkboxes come back on with a business case stapled to them.
The add-ins you want: centralized deployment. Under Settings → Integrated apps, an admin deploys a vetted add-in to the users or groups that need it. They open Outlook and it is simply there, no store trip, no consent gamble, and you keep the list of what is running instead of discovering it during an incident. One vetted deployment beats forty users each rolling the dice on the same gadget. 🎯
The services you want: bought properly. If the business genuinely needs Power BI or a Copilot seat, an admin procures it into a governed environment with an owner, a DLP story, and a place in the offboarding runbook. Same capability, minus the surprise. 🧾
The trial you want: run it on purpose. Nothing stops an admin evaluating a product deliberately, scoped, time-boxed, and visible. What you removed is the version where the evaluation is a side effect of someone's Tuesday. 🔬
Caveats ⚠️
The AppsForOfficeEnabled trap. Covered above and worth repeating: $false is a blast radius, not a setting. It kills admin-deployed add-ins too. Use the Store checkbox and centralized deployment. 🔨
Self-service purchase drifts by design. It is per-product, and Microsoft ships new products into the list Enabled. Copilot arriving self-service-purchasable is the kind of surprise that made a lot of admins re-run this script. Schedule the loop, do not run it once and call it done. 📅
Off is not "undo." Clearing the boxes and disabling purchase stops new self-service activity. It does not retract trials already started or subscriptions already bought. Before you close the change, inventory what is already live: existing self-service subscriptions show up in the admin center billing, and existing store add-ins show up under Integrated apps. A clean switch on top of a dirty tenant still leaves the mess underneath. 🧹
Outlook add-ins have a second management surface. Who may install and manage add-ins for Outlook is also governed in Exchange Online. The Store checkbox is the tenant-wide user-facing lever and the one that matters for the MKB baseline; the Exchange controls are there if a customer needs finer per-role handling. 📬
License fit (MKB lens). All three levers are Business Premium with room to spare. The Store checkbox, the trials checkbox, and the commerce policy cost nothing and require no tier-up. There is no upsell here, only defaults nobody changed. 💼
Reversibility. Clean-revert, which is exactly the problem. Re-checking a box leaves no residue and no fingerprint, so the Store reopens the afternoon someone decides the marketing team is a special case, and stays open for everyone else by accident. Watch the boxes on a schedule, not your memory of having ticked them. 🔁
👥 Assignment scope
Tenant-wide by default. Store closed, trials off, every purchasable product disabled, no exceptions until someone signs for one.
The exception path, done properly. When a team genuinely needs an add-in, do not re-open the Store for everyone. Deploy that specific add-in through centralized deployment to a group, so the exception is one named, vetted app for one named set of people, not an open marketplace for the tenant. An exception is a smaller door, not the shop back open.
Check it on a schedule. Two things drift here and both drift quietly:
- New self-service products default to Enabled. Re-run the
AllowSelfServicePurchaseloop on a schedule so the product Microsoft added last month does not sit open for a quarter.Get-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase | Where-Object { $_.PolicyValue -ne 'Disabled' }returning rows is your signal. 🚨 - The Store checkbox reappears. A tenant migration or a helpful vendor "fixing Office" has a habit of turning it back on. Pair a scheduled read of the tile with an alert on the change, because the person flipping it back is rarely the person who mentions it.
🔗 Related
- 🧩🧑💼AC - User Consent for Applications: the deeper layer under the Store, where OAuth add-ins ask for standing access to mail and files.
- 🤖🧑💼AG - Agent Builder Sharing: the same Share-and-acquire reflex, one workload over.
- 📅🧑💼OS - Calendar External Sharing: the sibling Org settings tile that closes another self-service door.
- 🏢🧑💼TS - Default User Permissions: the self-service instinct one layer down, closing the doors that ship open in identity.
Nobody signed up to run a marketplace, a trial factory, and an unapproved purchasing desk. Close the counters; keep the one shelf you actually stocked. 🛒