Microsoft’s Rights Management (RMS) connector—the critical middleware that links on-premises Exchange, SharePoint, and file servers to cloud-based protection—will stop accepting shared-secret credentials in favor of certificate-based authentication beginning with a preview in July 2026. The change, quietly published to the Microsoft 365 roadmap under ID 564617 on July 13, forces a fundamental shift: every organization that installs or upgrades the connector must first create its own Microsoft Entra ID application registration and upload a certificate. The days of a quick, automated service-principal setup are over.

The End of Automatic Identity Setup

Until now, deploying the RMS connector was relatively straightforward. The installer handled Entra ID provisioning behind the scenes, creating the necessary service principal and issuing a shared secret that allowed on-premises servers to talk to Azure Rights Management. That convenience came with a security cost—a password-like secret that, if compromised, could be used to impersonate the connector.

Under the new model, the setup wizard will no longer perform these identity tasks. Instead, customers must manually register an application in Microsoft Entra ID and upload the public portion of an authentication certificate before running the installer or upgrading an existing connector. The application registration becomes a permanent asset that the organization owns and governs: you’re responsible for its permissions, certificate lifecycle, monitoring, and eventual cleanup.

A new PowerShell module will ease the transition by handling certificate import, registry configuration, and private-key permissions across the connector and its supported workloads (Exchange, SharePoint, and File Classification Infrastructure). But don’t expect a single magic command. Microsoft explicitly states that configuration occurs for each workload, meaning mixed environments will need tailored steps for each server role.

Who Has to Act (and Who Doesn’t)

If your organization doesn’t use the RMS connector, this change doesn’t affect you. But if any of these systems rely on the connector to apply Azure Information Protection labels or rights management to on-premises data, you’re in scope:

  • Exchange Server (email)
  • SharePoint Server (documents)
  • Windows file servers with File Classification Infrastructure (FCI)

Home and small-business users are untouched—this is an enterprise-only affair. But for IT teams already stretched thin, the shift adds a real coordination burden. The connector’s identity, once an afterthought, now demands cross-team collaboration between Purview admins, Entra ID admins, Windows Server admins, and the workload owners.

Why Microsoft Is Making the Switch

The security rationale is straightforward: certificates are stronger than shared secrets. A shared secret is a bearer token—anyone with the string can authenticate. A certificate requires possession of the corresponding private key, which can be stored securely in the Windows certificate store and governed by enterprise PKI policies. Microsoft has been pushing certificate-based authentication across its ecosystem for years, and the RMS connector is simply the next domino.

But there’s also an operational philosophy at play. By making customers own the Entra application, Microsoft is offloading identity hygiene onto the organizations that benefit from it. This mirrors the broader “shared responsibility” model of cloud services: you get more control, but you also get the work.

Your Action Plan: Six Months Before the Deadline

September 2026 may sound distant, but the July preview is the real inflection point. That’s when Microsoft’s implementation details should become testable—and when you need to have a lab environment ready. Here’s a countdown checklist based on what we know today.

Before July 2026

  • Inventory every RMS connector server. Note their OS versions, load balancers, service accounts, and current connector versions.
  • Map all connected workloads. For Exchange, SharePoint, and FCI, document which servers depend on each connector node.
  • Identify the existing service principal. In Entra ID, find the enterprise application that the connector uses today. Record its object ID and any custom permissions. You’ll need to confirm it’s no longer in use after migration.
  • Review your internal PKI. Can you issue certificates with the right key lengths, algorithms, and export controls? If you don’t have a PKI, plan for a publicly trusted certificate or a self-signed certificate with secure distribution.
  • Plan certificate rotation. Decide whether you’ll use overlapping certificates (issuing a new one before the old one expires) and how to monitor expiration.

During the Preview (July–September 2026)

  • Register an Entra application. Use the preview documentation to determine the required API permissions and admin consent scope.
  • Issue and upload a test certificate. Test the PowerShell module to import the cert, set private-key permissions, and configure a single workload.
  • Validate failure scenarios. Deliberately expire the certificate, remove private-key access, or misconfigure the registry, then verify that monitoring tools (Event Viewer, SIEM) catch the errors.
  • Run a parallel node. If you have multiple connector servers, upgrade one while the others run the old shared secret. Test whether both authentication methods can coexist.
  • Test workload failover. For Exchange, SharePoint, and FCI, ensure that content protection and consumption still work after the switch.

Before September 2026

  • Update runbooks and maintenance plans. The old “run the installer and forget” workflow is dead. Document the new certificate renewal process, emergency rollback steps, and dependency chains.
  • Schedule the production upgrade. Coordinate with all workload teams and choose a maintenance window that allows for end-to-end testing.
  • Retire the old service principal. Only after you’ve confirmed certificate-based authentication is stable across all workloads, delete or disable the original shared-secret identity.

The Expiration Clock You Can’t Ignore

Certificates expire—and when they do, unattended authentication stops cold. Unlike a shared secret that might limp along until someone notices a warning, an expired certificate can break RMS protection immediately. If your connector servers can’t authenticate to Azure Rights Management, users may suddenly find they can’t open protected documents or email.

That risk means monitoring must extend beyond the connector itself. You’ll need alerts tied to certificate expiration dates (ideally 30, 14, and 7 days out), plus regular health checks that confirm the connector’s identity is valid. The new PowerShell module promises validation cmdlets; use them in a scheduled script.

Private-key protection becomes part of the threat model, too. Anyone who can export the certificate from a connector server and obtain the private key can impersonate the application. Limit administrative access, set strong export passwords (or block export entirely), and treat those servers with the same care you’d give a domain controller.

Beyond the Setup: Managing Certificates in Production

Once you’ve successfully migrated, the job shifts to lifecycle management. A safe rotation process means you’ll need to:

  1. Generate a new key pair and certificate.
  2. Upload the new public certificate to the Entra app registration without removing the old one.
  3. Deploy the new certificate and private key to all connector nodes.
  4. Validate that authentication works using the new thumbprint.
  5. Remove the old certificate from Entra only after confirming all nodes have been updated and workloads are stable.

The preview documentation must clarify whether Entra ID supports multiple active certificates. If it does, you can run overlapping credentials and de-risk the cutover. If not, you’ll need a tight coordination window—and possibly a brief outage—to swap certificates cleanly.

The Outlook: July Preview Will Make or Break Timelines

While the roadmap marks general availability for September 2026, Microsoft’s track record with preview timelines suggests some flexibility. But the bigger wildcard is how robust the PowerShell module and documentation will be at launch. Key unknowns today include:

  • Supported certificate authorities and key lengths.
  • Whether the new cmdlets handle edge cases like network load balancers or stretched clusters.
  • How Azure Rights Management handles a mix of certificate- and secret-authenticated connectors during coexistence.
  • The exact error codes and event log entries that signal certificate problems.

Smart IT teams will treat the July 2026 date not as a start gun, but as a first test. By then, you should have a lab environment and a draft migration plan. Any delays in the preview or gaps in the tooling will compress your production timeline—so front-load as much preparation as possible.

One thing is certain: when September 2026 arrives, the old shared-secret path will be gone. The only question is whether your organization will be ready.