How to ensure encrypted M365 contents readable after users separating from source to new target tenant?

Question

Hi There,

working on Divestiture project. as part of separation, we need to carve out a users from particular business from parent M365 to new greenfield M365 tenant. there won't be any relationship between source & target after separation. S/MIME & AIP are enabled for secured email communication & data security. how can i ensure the encrypted mails & encrypted file/document accessible after migrating the users to target? we are planning for new certificate in the target. How can we import keys from source to target? is that possible? what solutions/options we have ?

Appreciate your solutions/suggestions. Thanks in advance.

regards,

Manickam

Answer 1

Cross-tenant mailbox migration and Azure Information Protection (AIP)/S/MIME encryption are separate concerns. Mailbox content can be moved, but key material and labels do not move between tenants, and there is no supported way to “import” the tenant encryption keys from one Microsoft 365 tenant into another.

Key points from the available information:

1. Cross-tenant mailbox migration moves only user-visible mailbox data
   • Cross-tenant mailbox migration moves email, contacts, calendar, tasks, and notes to the target tenant.
   • It does not move labels, policies, or other protection configuration.
   • After a successful cross-tenant migration, the source mailbox is deleted and is no longer available or discoverable in the source tenant.
2. Labels and protection configuration must be recreated in the target tenant
   • Cross-tenant migrations do not export labels and there is no way to share labels between tenants.
   • To have the “same” labels in the new tenant, they must be recreated there.
3. Azure Information Protection / Azure Rights Management tenant keys
   • For AIP, migrating tenant keys is treated as a “rekeying” or “rolling your key” operation, not as a cross-tenant key import.
   • To move content to a new key, protection must be removed with the old key and then reapplied so that the new key protects the content.
   • It is not safe to delete the old tenant key until content protected with that key is no longer needed or has been reprotected.
4. S/MIME behavior
   • S/MIME uses public key certificates where the private keys remain with the user/organization and are not transmitted to Microsoft 365.
   • Encrypted mail can only be decrypted by the recipient who has the corresponding private key.
   • There is no mechanism in the provided material to move S/MIME private keys between tenants via Microsoft 365; access depends on the user still having their private key in their client/PKI environment.
5. Access to encrypted content across organizations
   • If encrypted content is protected with Azure RMS/AIP and relies on Microsoft Entra ID for authorization, users in another organization may be unable to open it if the Entra configuration or trust does not allow it.
   • When there will be no relationship between source and target tenants after separation, continued access to content encrypted under the source tenant’s keys becomes a design and planning issue: either maintain some form of access to the source tenant/keys for as long as that content is needed, or decrypt and re-protect content under the new tenant before the relationship ends.

From the provided information, supported options are:

• For mailbox data: use cross-tenant mailbox migration to move user-visible content to the new tenant.
• For labels and AIP policies: recreate them in the target tenant; labels are not shared or migrated.
• For AIP-encrypted documents that must remain readable after separation: remove protection with the old tenant key and reapply protection so that the new tenant key protects the documents, and do not delete the old tenant key until this is complete.
• For S/MIME-encrypted mail: ensure users retain access to their S/MIME private keys in their client/PKI environment; decryption is tied to those keys, not to tenant migration.

There is no supported mechanism in the provided material to import or clone the source tenant’s AIP/RMS tenant keys or S/MIME keys into the new tenant so that the new tenant can transparently decrypt old content. Continued access requires either maintaining the old keys and identity context or decrypting and re-protecting content before or during the transition.

---

References:

• Cross-tenant mailbox migration
• Customer-managed encryption features
• Microsoft Entra configuration for encrypted content
• How to migrate key workloads