Applications are now key actors in every Microsoft 365 environment: they run automations, connect services and touch sensitive data. But many of them are over-permissioned, use weak authentication methods or reach far more data than they need.
Traditional app trust models no longer hold up. Microsoft offers controls that enforce how apps authenticate and which resources they can reach, in line with Zero Trust principles. These are the three most practical ones:
- Entra application management policies: control how apps authenticate.
- Selected permissions: scope SharePoint and OneDrive access to specific sites.
- RBAC for Applications in Exchange Online: limit apps to specific mailboxes.
1App authentication policies in Entra ID
Why it matters: Many organizations rely on client secrets and certificates for app authentication, and those easily become liabilities. Poor lifecycle management or overly permissive defaults lead to credential sprawl, shadow IT and exposure.
What’s new: You can configure Application Authentication Method Policies through Microsoft Graph. They allow or block specific credential types, enforce expiry rules and stop insecure practices, either tenant-wide or per app. Microsoft provides a set of preset restriction types that make enforcement practical:
| Restriction | What it does | Example |
|---|---|---|
| asymmetricKeyLifetime | Maximum lifetime for a certificate (asymmetric key) | Certificates of 30 days at most for apps created after 01/01/2019 |
| audiences | Restrict creating or promoting apps by signInAudience | Stop new apps from being configured as multi-tenant |
| customPasswordAddition | Restrict custom password secrets when creating an app or service principal | Block secrets not generated by Azure on apps created after 01/01/2015 |
| nonDefaultUriAddition | Block identifier URIs that don’t follow the default format | Only api://{appId} or api://{tenantId}/{appId} |
| passwordAddition | Block password secrets completely | No passwords on any new app created after 01/01/2019 |
| passwordLifetime | Maximum lifetime for password secrets | 30-day maximum for secrets issued after 01/01/2015 |
| symmetricKeyAddition | Block symmetric keys | No new symmetric keys on apps created after 01/01/2019 |
| symmetricKeyLifetime | Maximum lifetime for symmetric keys | 30-day maximum for new symmetric keys |
| trustedCertificateAuthority | Allow certificates only from trusted CAs | Reject any certificate from an authority not on the list |
- Short-lived certificates for automation apps Cap certificate lifetime at 30 days for internal automation tools, so a stolen or leaked certificate is useful for far less time.
- No multi-tenant apps by default The tenant blocks multi-tenant app creation unless explicitly approved, which cuts supply-chain risk.
Tip: These controls are especially valuable when several dev teams create and register apps on their own.
2Selected permissions in SharePoint and OneDrive
Why it matters: Apps that need file access have traditionally been given tenant-wide permissions such as Sites.Read.All or Files.ReadWrite.All. That is unnecessary risk, because most apps only need a handful of resources.
With Selected permissions, admins scope an app explicitly to the SharePoint sites or OneDrive drives it actually needs. How it works:
- Assign the app the Sites.Selected permission.
- Grant access site by site or per drive, using the Graph API or PowerShell.
- The app cannot reach anything else unless explicitly approved.
- External partner tool limited to one site A marketing agency’s app gets access to its campaigns site only, with no access to other business units.
- Power BI dashboard limited to one user’s OneDrive A BI tool reads from the sales director’s folder only, with no visibility into anyone else’s content.
Tip: You can automate the permission grants with provisioning scripts as part of the app’s CI/CD pipeline.
3Limiting app access to Exchange mailboxes
Why it matters: By default, a Graph permission like Mail.Read or Mail.Send gives an app access to every mailbox in the organization. That is dangerous, especially for apps that only need shared inboxes or system accounts.
RBAC for Applications in Exchange Online lets you grant an app access to specific mailboxes only. It replaces Application Access Policies, which Microsoft now calls legacy and says not to use for new configurations. How it works:
- Create a management scope that defines which mailboxes the app may reach, for example by group membership.
- Assign the app an Exchange Online role (for example Application Mail.Read) restricted to that scope.
- Remove the broad Graph permission granted in Entra ID. Otherwise it still applies to every mailbox, because permissions from the two systems add up.
- Helpdesk app limited to support mailboxes The app reaches only support@company.com and techdesk@company.com, and cannot read executive mailboxes.
- HR automation limited to the onboarding inbox The system only works with hr-onboarding@company.com for its automated email flows.
Tip: Combine this with Conditional Access and App Enforced Restrictions for a model that is bounded on every side.
Wrapping up: Zero Trust for apps too
These controls are the foundation of modern app governance in Microsoft 365, and each maps directly to Zero Trust principles:
- Never trust by default, least of all apps.
- Always verify: which authentication method, which scope.
- Limit exposure to exactly what is needed.
Security, identity and compliance teams should review existing app permissions now and make sure they match actual use. These tools make that process automatable, auditable and enforceable.
Want to know which of these settings are missing in your tenant? Griffin31 checks your tenant continuously and shows you what to fix first.