A company deploys IRM for files shared with external partners. Partners report they cannot open the protected files because they have no identities in the company's directory. What is the best way to address this?
Select an answer to reveal the explanation.
Short Explanation
IRM can only enforce rights for people it can recognize. So you give partners a way in, either federating with their identity provider or setting up guest accounts, and then the rules apply to each person. Shared logins and emailed keys just throw away the whole point.
Full Explanation
IRM decisions depend on identity: the policy service must authenticate each user before deciding which rights to grant. Provisioning is therefore a central IRM objective and a known challenge with external parties who are not in the organization's directory. The appropriate solution is to establish trusted identities for partners, typically by federating with the partner's identity provider or by creating guest or external accounts with proper lifecycle management, so each person authenticates individually and receives only the rights the policy grants. Removing IRM protection for partner files abandons persistent control precisely where data leaves the organization and is most exposed. A single shared account eliminates individual accountability, makes revocation for one partner employee impossible without affecting all, and violates basic access management principles. Emailing the decryption key bypasses authentication and usage control entirely; anyone who obtains the key or the email can open the files, defeating IRM. Exam caveat: federation also simplifies deprovisioning, because disabling a partner account at the partner's identity provider removes access. Operational check: confirm each external user authenticates with an individual identity and that IRM logs show per-user access to protected files.