It is possible to disable the Office 365 service account that Okta used to initially grant consent for the Microsoft Graph API. However, there are some implications, and admins need to follow the correct procedures to avoid disrupting the Okta-M365 integration.

• Office 365
• Provisioning
• Okta Integration Network (OIN)

Understanding the Role of the Service Account

• When Okta is integrated with Microsoft 365 and enables features that rely on the Microsoft Graph API (for example, provisioning, some SSO configurations, and importing users), admins typically grant Okta permissions to the O365 tenant.
• Involves authenticating with a Microsoft 365 Global Administrator account(which is done when the Provisioning is enabled).
• This account, or the permissions granted through it, allows Okta to create service principals (application registrations) in Azure AD. These service principals allow Okta to interact with the Microsoft Graph API.
• Disabling the initial Global Administrator account used for the initial consent does not necessarily revoke the permissions granted to the Okta service principal. The service principal acts as its own security identity once consent is given.

Consequences of Disabling the Initial Account

Loss of the ability to re-authenticate or modify the integration within Okta. If the account used for the initial authentication is disabled or loses the necessary permissions, issues may be encountered when trying to:

• Re-authenticate the M365 connection in Okta.
• Provisioning Troubleshooting (an example of troubleshooting that requires the account to be active and have the rights to make the call can be found in the Microsoft Office 365 New Licenses Do Not Appear in Okta documentation).
• Grant new permissions to Okta.

Related References

• Microsoft Office 365 New Licenses Do Not Appear in Okta