Last week at Microsoft Ignite, we announced that publisher verification is now generally available. This capability allows developers to add a verified identity to their app registrations and demonstrate to customers that the app comes from an authentic source. We announced public preview at Build in May, and over 700 app publishers have since added a verified publisher to over 1300 app registrations.
For developers, publisher verification allows them to distinguish their apps to customers by receiving a “verified” badge that appears on the Azure AD consent prompt.
Adminscan also set user consent policies based on if an apps is publisher verified helping streamline adoption. Developers who are building for Microsoft 365 that want to further distinguish their apps can also participate in the Microsoft 365 App Certification program.
User consent updates for unverified publishers
With publisher verification now generally available, we will be making changes that help protect users from app-based attacks. End users will no longer be able to consent to new multi-tenant apps registered after November 8th, 2020 coming from unverified publishers. These apps may be flagged as risky and will be shown as unverified on the consent screen. Apps requesting basic sign-in and permissions to read user profile will not be affected, nor will apps requesting consent in their own tenants.
To prepare for this change if you are an app developer, add a verified publisher to all your multi-tenant app registrations.
General availability of app consent policies
To help admins control what apps their users can consent to, we’re announcing general availability of the new app policies for end user consent. With app consent policies, admins have more controls over the apps and permissions to which users can consent.
Customers can manage settings for user consent by choosing from the following built-in app consent policies in the screenshot below:
Customers can also use Azure AD PowerShell or Microsoft Graph to create custom consent policies for even more control. These policies can include conditions that apply to the app, the publisher, or the permissions the app is requesting. Additionally, custom directory roles now support the permission to grant consent, limited by app consent policies. This can enable scenarios such as delegating the ability to consent only for some permissions, and creating least-privileged automation to manage authorization for apps.
As always, we'd love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below. For additional best practices to protect your organization from app-based attacks, be sure to check out the resources below: