Microsoft Graph Command Line Tools to become verified in Entra

In Message center post ‘MC804763‘, Microsoft has announced that they are getting ready to migrate the Microsoft Graph Command Line Tools application to new infrastructure which will allow it to be published with a ‘Verified’ status, later this June.

Looking at the current state of the Microsoft Graph Command Line Tools app in Microsoft Entra. If you connect to the application and need to provide consent to a formerly unconsented permission, you will be asked to provide consent, however the built-in application reports as ‘Unverified’. 

Microsoft Graph Command Line Tools Unverified
Microsoft Graph Command Line Tools Unverified

Digging a little deeper into this, you can find more information on the application by extracting it from Microsoft Graph. Follow along with this by opening the Microsoft Graph Explorer tool, and then making a GET request to the following endpoint. (Replace %appid% with the ObjectId of the application taken from the Entra portal).

The result provides us some useful information about the app, key information has been highlighted below:

    “@odata.context”: “$metadata#servicePrincipals/$entity”,
    “”: “Use $select to choose only the properties your app needs, as this can lead to performance improvements. For example: GET servicePrincipals(‘<guid>’)?$select=accountEnabled,addIns”,
    “id”: “6e635873-f25b-4a14-892e-0c7e84776d17”,
    “deletedDateTime”: null,
    “accountEnabled”: true,
    “alternativeNames”: [],
    “appDisplayName”: “Microsoft Graph Command Line Tools”,
    “appDescription”: null,
    “appId”: “14d82eec-204b-4c2f-b7e8-296a70dab67e”,
    “applicationTemplateId”: null,
    “appOwnerOrganizationId”: “72f988bf-86f1-41af-91ab-2d7cd011db47”,
    “appRoleAssignmentRequired”: false,
    “createdDateTime”: “2024-06-22T08:14:22Z”,
    “description”: null,
    “disabledByMicrosoftStatus”: null,
    “displayName”: “Microsoft Graph Command Line Tools”,
    “homepage”: “”,
    “loginUrl”: null,
    “logoutUrl”: null,
    “notes”: null,
    “notificationEmailAddresses”: [],
    “preferredSingleSignOnMode”: null,
    “preferredTokenSigningKeyThumbprint”: null,
    “replyUrls”: [
    “servicePrincipalNames”: [
    “servicePrincipalType”: “Application”,
    “signInAudience”: “AzureADandPersonalMicrosoftAccount”,
    “tags”: [
    “tokenEncryptionKeyId”: null,
    “samlSingleSignOnSettings”: null,
    “addIns”: [],
    “appRoles”: [],
    “info”: {
        “logoUrl”: “”,
        “marketingUrl”: null,
        “privacyStatementUrl”: “”,
        “supportUrl”: null,
        “termsOfServiceUrl”: “”
    “keyCredentials”: [],
    “oauth2PermissionScopes”: [],
    “passwordCredentials”: [],
    “resourceSpecificApplicationPermissions”: [],
    “verifiedPublisher”: {
        “displayName”: null,
        “verifiedPublisherId”: null,
        “addedDateTime”: null

appOwnerOrganizationId – This is the tenant where the application is registered. By running this through the AADInternal OSINT tool, we know that this ID belongs to the domain name where many other domain names are registered. 

CreatedDateTime – This refers to the time when the application was first registered with your tenant. As the application can be deleted and re-added, this does not represent when the application was created. When consenting to the application, you can identify this by hovering over the ‘Unverified’ status.

servicePrincipalNames – This is the ID of the service principal as it is registered in the owner tenant. This value represents the common endpoint for the application which is the same for every tenant.

signInAudience – This details that the application is a multi-tenant application which can be logged into by any Microsoft 365 or Microsoft (personal) account.

Why is the application not verified currently

As the application is common for all tenants and also owned by Microsoft’s own Microsoft 365 tenant, it begs the question of why the application is not verified, which usually leads to some concern for first-time users.

Well, a post by a Microsoft Product Manager in an old GitHub issue provides some level of detail as to why this is.

To add visibility here, Microsoft Graph PowerShell SDK uses a third-party appId as part of our security concerns on having incremental consent for permissions.
Unfortunately, we have limitations on getting a 3rd party app publish verified under Microsoft Tenant (even though it’s a Microsoft application). The Microsoft security team has not allowed us to do this as the Microsoft Graph PowerShell appID is public and could be used in ways to break security and get access to Microsoft data.
And we can’t use first-party appId as incremental consent has not been implemented yet.

So, being a published verified application in our case is something with no precedent, and even looking as an ‘easy’ thing to address and something that couldn’t cause a regression, we do need yes, dig in and analyze the situation from every possible angle as well as have an agreement with Microsoft Security team.

With that said, I would like to let you know that we have been working on it, yes, for quite some time, to figure out the path and finally become a publish verified application.

On the other hand, the great thing about Microsoft Entra is that organisations have always been provided with the ability to register their application to facilitate Microsoft Graph PowerShell, which they can also go through the process to become a verified publisher. Personally, registering your application for Microsoft Graph PowerShell is something I recommend in the security chapter of my book ‘Microsoft Graph PowerShell for Administrators‘.

What does this upcoming change mean?

This upcoming change means that Microsoft will be performing some maintenance on the Microsoft Graph Command Line Tools application to ensure it is verified for all organisations. Unfortunately, it has not been shared how they plan to do this, but it could be that the tenant of the application is changing hands and/or the ID of the application will change to support this work.

The notice from Microsoft highlights that this will be non-user impacting. For organisations that utilise their own registered application to facilitate a connection with Microsoft Graph PowerShell, there will be no impact. For organisations who do use the built-in Microsoft Graph Command Line Tools application, they may be asked to re-authenticate to the application but this would be expected with interactive authentication anyway.

Daniel Bradley

My name is Daniel Bradley and I work with Microsoft 365 and Azure as an Engineer and Consultant. I enjoy writing technical content for you and engaging with the community. All opinions are my own.

Leave a Reply