Business Central Dual Use Rights Key Rotation: The MSP Field Guide

Business Central Dual Use Rights used to feel like a one-time licensing detail. A customer had Business Central online, kept an on-premises deployment running under Dual Use Rights, and somebody found the key when the deployment needed it.

That model is now too loose. In its June 2026 Partner Center announcement, Microsoft says Dynamics 365 Business Central online customers running on-premises deployments through Dual Use Rights license keys must download and replace those keys every six months.

For MSPs, this is not just a licensing footnote. It is recurring admin work with real client risk attached. If you support Business Central, sell Microsoft CSP, or inherit on-prem accounting systems during client onboarding, you need to know which clients are exposed, who owns the key, where the reminder lives, and how the work gets quoted.

If the answer is “someone in finance probably knows,” you do not have an operating process. You have a future ticket with bad timing.

Quick answer: Business Central Dual Use Rights key rotation is now a six-month operational task. MSPs should audit exposed clients, confirm where each DUR key is downloaded, assign an accountable owner, replace the key before it creates disruption, document proof of completion, and quote the recurring admin work instead of absorbing it as vague support.

What changed with Business Central Dual Use Rights?

Business Central Dual Use Rights allow eligible Business Central online customers to run an on-premises Business Central deployment under specific license rights. Microsoft’s change does not turn every MSP into an ERP partner overnight, but it does change the support expectation for clients who still have an on-premises Business Central footprint.

Microsoft says the new rule is effective June 5, 2026. Customers running on-premises Business Central through Dual Use Rights must download and replace license keys every six months to keep using the on-premises product.

Microsoft also says those keys are meant to prevent continued use of the on-premises environment beyond the subscription term plus a buffer period, and that using the DUR license after the Business Central online subscription expires is prohibited, even during the buffer period.

That last sentence matters. The six-month rotation is not just a technical chore. It is a subscription control.

What changed	What MSPs should do
DUR keys now need replacement every six months	Add every exposed tenant to a recurring license-key work queue
The key is tied to continued subscription rights	Confirm the Business Central online subscription is active before replacement
The key has an operational install path	Decide who downloads, stores, imports, restarts, and verifies
Microsoft names partner responsibility	Put the task in a quote, agreement, roadmap item, or support scope

If you already run a Microsoft NCE renewal process, treat this as the Business Central version of the same problem. The client does not care whether the risk started in Partner Center, the Microsoft 365 admin center, or a Business Central administration shell. They care that you caught it before something broke.

Which MSP clients are exposed?

The exposed client is not “anyone with Business Central.” Start narrower.

Look for clients with all of these conditions:

1. They have Business Central online licensing.
2. They also run an on-premises Business Central deployment.
3. That on-premises environment depends on a Dual Use Rights license key.
4. Your team, the client, an ERP consultant, or another partner is expected to keep the environment usable.

Microsoft’s Business Central licensing overview says Business Central licenses are purchased through CSP and explains that Business Central online uses entitlements instead of classic Dynamics NAV license files. That is why this issue is easy to miss. The cloud tenant and the on-premises deployment do not behave the same way.

A pure Business Central online client may not need this process. A client with an old on-premises deployment, a partner-hosted environment, a reporting dependency, a warehouse workflow, a legacy add-on, or a slow ERP migration might.

Do not wait for the client to self-identify. They may not know what “Dual Use Rights” means. They may only know that the accounting system still has an on-prem server nobody wants to touch.

Use these discovery prompts during onboarding and QBR prep:

• Do you have any Business Central or NAV servers still running outside Microsoft’s cloud?
• Is that environment production, archive, reporting, integration, warehouse, or test?
• Who currently downloads license files or registration keys?
• Is the Business Central online subscription active and reconciled to the on-prem usage?
• Do you have a calendar reminder for the next DUR key replacement?
• Is this work covered in our agreement, or does it need a project line item?

This is also a good moment to clean up the client roadmap. If an old on-prem ERP environment is still important enough to license every six months, it is important enough to show up in the roadmap instead of living in one engineer’s memory.

Where do Business Central DUR keys come from?

Microsoft says customers can download new and replacement DUR license keys from the Microsoft 365 admin center. The Microsoft 365 admin documentation for CSP software and license keys says Dual Use Rights keys are a benefit of some specific Dynamics 365 subscription licenses.

The documented path is:

1. Go to Billing and then Your products in the Microsoft 365 admin center.
2. Choose the Dynamics 365 service that has a Dual Use Right key.
3. In Registration Keys, select the version to download.
4. Download the software or the activation file as needed.

The same Microsoft 365 admin article says Global Administrator access is required for the software and product license key workflow, and it cautions that Global Administrators have almost unlimited access to the organization’s settings and data.

That creates a real service-design question. You probably do not want every service desk tech holding broad admin access just because a license key needs rotation twice a year. But you also do not want the process blocked because only one person knows where the key lives.

A clean owner model looks like this:

Role	Responsibility
Client business owner	Confirms the Business Central subscription still maps to active on-prem usage
MSP account owner	Makes sure the work is quoted, approved, and scheduled
Technical owner	Downloads, imports, restarts, and verifies the key
Security or admin owner	Controls privileged access and secure key storage
ERP partner, if separate	Confirms application-specific timing and post-change checks

If there is another ERP partner in the account, do not silently take over their work. Define the handoff. The risk is not that two partners care too much. The risk is that everyone assumes somebody else owns the key.

What actually needs to happen every six months?

Do not reduce this to “download key.” That is the beginning of the task, not the scope.

Microsoft’s Business Central license upload documentation says on-premises Business Central deployments use a license file supplied by Microsoft. It also notes that license files can be .flf or .bclicense, with .bclicense recommended when available, and that the file is typically uploaded once per database installation rather than once per client installation.

The Import-NAVServerLicense reference says the cmdlet imports a license file into a Business Central database and that Business Central Server instances must be restarted after importing a new license for client users to use it.

That means the six-month workflow has more moving parts than a calendar invite.

A practical MSP checklist

1. Find exposed clients. Search your PSA, documentation platform, CSP records, and server inventory for Business Central, Dynamics NAV, on-premises ERP, registration keys, .flf, and .bclicense references.

2. Confirm the subscription. Verify that the Business Central online subscription is active, current, and mapped to the on-premises usage. If the subscription is expired, do not treat the buffer period as permission to keep using the on-premises product.

3. Identify the admin path. Confirm who can access the Microsoft 365 admin center path for the customer and whether the access model is secure enough for a recurring process.

4. Download the right key. Capture the product, version, download date, responsible person, and storage location. Avoid loose files on desktops, inboxes, or ticket attachments that outlive the task.

5. Plan the install window. Coordinate with the client and any ERP partner before importing the key. If the server instance needs a restart, do not schedule the work like harmless admin cleanup.

6. Import and restart. Use the documented Business Central license import path for the client’s version and deployment model. Record what was changed and which instance or tenant was affected.

7. Verify. Confirm Business Central opens for the expected user roles, critical integrations still run, scheduled tasks are healthy, and the license information matches the expected entitlement.

8. Document proof. Save the date, key source, operator, affected environment, verification evidence, next due date, and any exceptions.

9. Create the next reminder. Set the next rotation before the ticket closes. A six-month recurring task without a next date is not a process.

This is the kind of small operational job that quietly eats margin when it is not scoped. If your team needs a stronger pattern for sizing admin work, use the MSP project scoping guide and turn this into a repeatable service item.

What should MSPs quote?

Quote the work the client actually needs, not just the Microsoft step.

A small client with one clean Business Central on-prem instance, clear admin access, and no separate ERP partner may need a short recurring admin line item. A client with multiple environments, old NAV history, custom integrations, or unclear ownership needs a proper mini-project.

Here is the difference:

Scope item	Include when	Why it belongs in the quote
Exposure audit	You do not know which clients use DUR keys	Prevents surprise tickets and missed clients
Access review	Global Admin or delegated admin access is unclear	Keeps the process from depending on unsafe shortcuts
Key download and storage	Every exposed client	Creates a controlled source of truth
Import and restart window	Any live on-premises environment	Reduces avoidable disruption
ERP partner coordination	Another partner owns Business Central app support	Prevents handoff confusion
Post-change validation	Production, warehouse, finance, or integration use	Confirms the task actually worked
Documentation update	Every exposed client	Makes the next six-month rotation cheaper
Recurring reminder	Every exposed client	Keeps the task from becoming emergency support

For a fully managed client, this might become a recurring operations item inside the agreement. For a co-managed or project-only client, it may be a scheduled admin block twice a year. For a messy inherited environment, it might start as a paid discovery engagement before you promise ongoing support.

This is where margin protection matters. A license key rotation is not glamorous, but it still consumes privileged access, documentation time, client coordination, and verification. If you bundle all of that into “covered support” without naming it, you train the client to undervalue the work and train your team to hide the cost.

A clean quote can be plain:

Twice-yearly Business Central Dual Use Rights license key rotation, including subscription check, key download from Microsoft 365 admin center, secure storage, scheduled import, server instance restart if required, post-change validation, documentation update, and next rotation reminder.

That is the work. Name it.

The risks MSPs should explain to clients

Do not scare clients. Do explain the operating risk in normal words.

Risk 1: The on-premises environment becomes a surprise dependency

The client may think Business Central is “in the cloud” while a reporting database, warehouse workstation, integration server, or legacy process still relies on an on-premises environment. The DUR key forces you to identify that dependency.

Risk 2: The key owner is unclear

If the client, MSP, CSP partner, and ERP consultant all touch the account, key ownership gets blurry. The next rotation should have one accountable owner and one documented backup.

Risk 3: Privileged access gets handled casually

The Microsoft 365 admin documentation requires Global Administrator access for its software and key workflow. That does not mean the process should be casual. Limit access, document who used it, and keep key storage out of personal inboxes.

Risk 4: A technical step becomes after-hours work

Importing a license file and restarting server instances may be routine for the right engineer, but it still has a change window. If the client uses Business Central during business-critical periods, schedule accordingly.

Risk 5: The work gets absorbed instead of quoted

This is the most common MSP failure. A vendor changes a requirement, the service desk handles the first one under pressure, and six months later nobody remembers whether the client pays for it. Treat the first rotation as the moment to define the service, not the moment to give away the process.

How Scopable fits this workflow

Scopable is built for MSPs that need to turn fuzzy client work into clean scopes, roadmap items, and quotes. Business Central Dual Use Rights key rotation is a perfect example: the value is not the key itself. The value is identifying the exposed client, pricing the admin path, documenting ownership, and making sure the next cycle is already on the calendar.

Use Scopable when a licensing change creates a small but real operational obligation. Capture the client risk, attach the right scope, and move it into the roadmap or quote before it becomes free support.

A simple client-facing explanation

Use wording like this in a QBR, renewal note, or project scope:

Microsoft now requires Business Central Dual Use Rights license keys for on-premises deployments to be replaced every six months. We found this affects your Business Central environment, so we are adding a scheduled license-key rotation task. The work includes confirming the active subscription, downloading the replacement key, applying it during an approved window, verifying access, documenting the result, and setting the next reminder.

That is enough. No panic. No giant licensing essay. Just the change, the risk, and the work.

If the client asks why this is billable, the answer is equally simple:

This is recurring privileged administration for a production business system. The Microsoft download is one part of the task, but the full scope includes access control, scheduling, application coordination, validation, documentation, and future reminders.

That sentence protects the service desk from turning a real process into a favor.

What to do this week

Start with a quick internal sweep.

1. Search your PSA for Business Central, Dynamics NAV, on-premises ERP, .flf, .bclicense, registration key, and Dual Use Rights.
2. Pull any Business Central online customers from CSP or billing records.
3. Match those customers against server inventory and documentation.
4. Flag clients with on-premises Business Central or unclear ERP ownership.
5. Create a ticket or roadmap item for each exposed client.
6. Decide whether each client needs agreement coverage, a project quote, or a one-time discovery call.
7. Set the next review cadence before closing the task.

If you only find one exposed client, this is still worth doing. One missed accounting-system dependency can turn into a noisy support event at exactly the wrong time.

If you find several, build the recurring service item now. The second rotation should be calmer, faster, and easier to quote than the first.

For broader Microsoft licensing cleanup, pair this with your renewal review, NCE checks, and roadmap planning. For the workflow side, join Scopable early access and turn license changes like this into scoped, priced client work instead of another undocumented admin scramble.