Modernized Microsoft 365 Authentication for Better Security & Ease of Use

Update : We have upgraded our document migration authentication to modern authentication standards for SharePoint, Teams, and OneDrive.

This enhancement strengthens security, improves reliability, and aligns our migration platform with current Microsoft 365 identity best practices. As part of this upgrade, legacy authentication mechanisms such as SharePoint IDCRL are no longer used.

Customer Impact:
Migration projects using delegated permissions (SharePoint, Teams, or OneDrive) will fail until permissions are re-consented. To continue, customers must re-consent the delegated permissions and then re-run the migration.

For more information, please review our release note.
We remain committed to continuously improving the security, reliability, and quality of our migration platform.

If you have any questions, please feel free to reach out to our Support team.

We are continuing to work on a fix for this issue

Update : Our teams continue to actively investigate and address the remaining items identified after deployment. Below are the latest updates and recommendations.

M365 Mailbox Issue: Scoping

Some customers using scoping functionality may encounter the error:
“Your migration failed while checking source credentials. Validate Token failed, please check EWS Application Permissions in Azure App.”
This remains under investigation.

Recommendation:
If possible, run your project without using scoping. The migration should complete successfully.
If scoping is required and the above recommendation does not resolve the issue, ensure the source application includes the additional permission Exchange.ManageAsApp, and follow the steps outlined in below document.

Document Link: [M365 Mailbox and Archive Migrations - Scoping Option for API Permissions](https://help.bittitan.com/hc/en-us/articles/27712633347099-M365-Mailbox-and-Archive-Migrations-Scoping-Option-for-API-Permissions#h_01J3NXCYXSE6V647FTHKRPR2KX)

-----

Tenant-to-Tenant (T2T) Coexistence – Organizational Relationship Creation

Tenant-to-Tenant coexistence projects are currently unable to complete the required cross-organizational free/busy setup process.

Workaround:
If free/busy availability between tenants is not required (typically only needed for large, long-running coexistence projects), we recommend creating a standard MigrationWiz mailbox project without coexistence while we work to resolve this issue.

-----

We appreciate your patience and continued cooperation as we work to fully resolve these items. Additional updates will be shared as progress is made.

Update: Resolved Issues, Known Issues & Workarounds

Following the recent deployment, we have identified a small number of edge-case scenarios that may affect specific configurations. Most have simple workarounds, and our teams are actively addressing these issues.

Resolved Issues :

The following issues identified after deployment have been resolved:
1. SSO sign-in for SSO-enabled domains
An issue that prevented users from logging in using SSO-enabled domains has been resolved.

2.SharePoint auto-discovery
SharePoint site auto-discovery is now functioning as expected.

We are actively working to address these scenarios and will provide updates as improvements are rolled out. If you experience issues outside of the cases described above, please contact Support for assistance.

Known Issues :

M365 Mailbox Issue: Scoping
Some customers, who are using scoping functionality, are receiving the error: “Your migration failed while checking source credentials. Validate Token failed, please check EWS Application Permissions in Azure App.” This is currently under investigation.

Recommendation:
If possible, run your project without using scoping. The migration should complete successfully.

Delegated Consent may return a 500 error :
In some cases, attempting delegated consent may result in an internal server error.

Workaround:
Edit the project, save it without making changes, and then retry the consent flow. This resolves the issue in most cases.

Consent may reference a previously configured tenant after changing endpoints :
If a project’s source or destination endpoint is edited to point to a different tenant, the consent flow may still attempt to authorize the previously configured tenant.

Workaround:
If the project has not been started, create a new project using the updated tenant details.

Consent banner may not appear for specific Google → Microsoft 365 (v3) document migration scenarios
In certain edge cases, the consent-required banner may not display even when consent has not yet been provided.

Recommendation:
Review the Project Summary page and confirm that the consent status shows Authorized / Consented before starting the migration

Consent banner may not refresh after editing project endpoints
When editing a project and changing tenant or permission settings, the consent banner may not immediately reappear.

Recommendation:
Verify the consent status from the Project Summary page to ensure authorization is complete.

We’ve upgraded our Microsoft 365 authentication experience to adopt Microsoft’s modern identity platform (v2), bringing stronger security, improved reliability, and a smoother configuration experience.

What’s New
• A modern PKCE-based authentication flow
• Enhanced security with Azure Key Vault
• Support for Microsoft’s latest identity platform (OAuth2)
• Simple, UI-based permission selection
• A guided in-UI consent experience for faster setup
• Better compatibility with MFA-enabled tenants

Action Required:
Some customers may need to re-authenticate depending on their configuration.
Required Actions & Resolution Guide [https://help.bittitan.com/hc/en-us/articles/43575952076827-Post-Deployment-Action-Items]
Endpoint Settings Guide [https://help.bittitan.com/hc/en-us/articles/42628192621211-Endpoints-Setting-Guide]
Project Summary - Consent Flow Guide [https://help.bittitan.com/hc/en-us/articles/42629928893851-Project-Summary]

The rollout is now expected to begin in the early part of the next week. No additional customer action is required beyond what was previously communicated.

Private Chat History (PCH) will not be supported following this deployment as part of an ongoing re-implementation initiative. This work is intended to deliver an improved PCH experience, and PCH support will be reintroduced in a planned upcoming release.

Late next week, we will begin rolling out a security-enhancing update to our authorization flow. As part of this update, a small set of workloads require user action to continue running successfully. OneDrive, SharePoint and Teams Collaboration endpoints using delegated permissions will need the Tenant ID added in the Endpoint Settings page and PKCE consent completed. BYO app registrations will no longer function and must be switched to the BitTitan app.

For full instructions and details, please refer to the guidance pages below:
Required Actions & Resolution Guide [https://help.bittitan.com/hc/en-us/articles/43575952076827-Post-Deployment-Action-Items]
Endpoint Settings Guide [https://help.bittitan.com/hc/en-us/articles/42628192621211-Endpoints-Setting-Guide]
Consent Flow Guide [https://help.bittitan.com/hc/en-us/articles/42629928893851-Project-Summary]

This notice is informational to ensure customers can complete the necessary updates.