Deploy Office add-ins from the Microsoft 365 admin center under Integrated apps, and roll out in phases: IT and a few stakeholders first, then more staff, then everyone. Review the add-in before step one, because Microsoft's documentation says marketplace add-ins receive updates automatically after you deploy them.
Why add-ins deserve a design review
An Office add-in sits inside the tools where your staff handle contracts, spreadsheets and mail. It is a third-party web application that can be given access to document content. That is a different risk from a standalone SaaS app, because the data path starts inside a document someone is already editing.
Microsoft's documentation describes centralized deployment through the admin center as the way to push add-ins to users and groups. The Integrated apps portal is called the recommended and most feature-rich route for most customers. Where that is not available, an add-in portal is the fallback.
The rollout, step by step
The documentation recommends a phased approach, which also suits a security review.
- Phase 0, before deployment. Review the add-in. What data does it read? Where is it processed? Who is the vendor? Does it have a security attestation or certification? See Microsoft 365 Certified vs publisher attested apps.
- Phase 1. Deploy to a small set of business stakeholders and members of IT. Watch for problems and unexpected network behavior.
- Phase 2. Deploy to more individuals in the business. Evaluate again.
- Phase 3. Roll out to all users, if the earlier phases went well.
Microsoft notes you can add or remove steps depending on how large the audience is.
The part people miss: how updates arrive
The documentation states that when you add an add-in from Microsoft Marketplace through the admin center, updates and enhancements are automatically deployed to users. You approved version one. You did not approve version two.
| Install route | Who controls updates | What to do |
|---|---|---|
| Marketplace through the admin center | The vendor, automatically | Re-review on a schedule, and watch vendor change notices |
| Custom upload of a manifest | You, by uploading a new manifest | Treat each manifest change like a code change |
For add-ins that call a vendor's web service, the code behind the add-in can change without a manifest change on your side. That is why the review needs to include the vendor's own change process.
Custom add-ins
If you upload a custom add-in, you choose a manifest file. The documentation says the add-in portal supports only add-ins that use the add-in only manifest, and that add-ins using the unified manifest must be deployed through the Integrated apps portal. Pick the portal that matches the manifest type, and record who owns the add-in internally.
What to record
- The add-in name, vendor and version at approval
- Who requested it and who approved it
- The user groups it was deployed to, per phase
- The data it can reach
- The next review date
Removing an add-in
Define the removal path before you deploy. Know who can remove it from the admin center, how fast it disappears from user machines, and what happens to data the vendor already holds. Ask for the vendor's deletion terms during review, not after an incident.
Safeguard covers the software you build, with dependency scanning, SBOMs and policy gates. The habit of staged rollout and a recorded approval carries over to how you adopt new packages as well.
Quick check
Does approving an add-in from the marketplace freeze its version?
According to Microsoft's documentation, no. Updates and enhancements from the marketplace option are deployed automatically, so you need a scheduled re-review.
Which portal do I use for a unified manifest add-in?
The documentation says add-ins using the Microsoft 365 unified manifest must be deployed through the Integrated apps portal, not the add-in portal.
Sources
Last reviewed: 19 October 2026.
