Disaster recovery licensing in Citrix audits is one of the most common places the vendor inflates exposure, and one of the easiest to get wrong if you do not prepare. Auditors routinely count DR and standby instances as though they were full production, which can double the apparent license requirement for an environment that exists only to sit idle until a crisis. The good news is that DR exposure is usually challengeable, because the real licensing position depends on what the environment actually does, not on the auditor's default assumption. As of June 2026, the guidance below reflects how DR is treated in the audits we defend.
Disaster recovery licensing in Citrix audits: why it is a soft target
Every serious Citrix estate has a disaster recovery footprint, because the workloads that run on Citrix tend to be the ones a business cannot lose. That makes DR universal and complex, and complexity is where audit claims grow. Standby environments are often built quickly, documented loosely, and rarely revisited, so when an auditor asks for an inventory, DR instances appear in the data with little context. The auditor then applies the reading that maximises the count, treating idle standby capacity as if it were serving users. The buyer, unprepared, struggles to prove otherwise, and the inflated number sticks.
Cold, warm, and hot standby: the distinction that decides the number
The single most important concept in DR licensing is the state of the standby environment, because the licensing treatment differs across the three common states.
Cold standby
A cold standby is powered off and dormant until a disaster is declared. It holds no live sessions and serves no users in normal operation. This is the state with the lightest licensing footprint, and counting a true cold standby as active production is the clearest form of audit inflation.
Warm standby
A warm standby runs and is kept current, but does not serve users in normal operation. It exists to fail over quickly. Its treatment sits between cold and hot, and the detail of your contract and subscription model matters here.
Hot standby
A hot standby actively serves users alongside production, often for load distribution as well as resilience. Because it delivers live sessions, it generally carries a licensing requirement closer to production. The point is not that DR is free, it is that the requirement should match the real state, and only a hot standby behaves like production.
The auditor counts standby as production by default. Your job is to prove what it actually does.
Where the vendor inflates DR exposure
Several patterns recur. Standby user capacity is counted on top of production users, even though the same people would use the DR environment only if production failed, never both at once. Powered off cold standby servers are counted as if running. DR test events are treated as ongoing production use rather than scoped, time bounded exercises. And entitlements that already cover DR under existing use rights are ignored, so the same capacity is charged twice. Each of these is a counting assumption, not a fact, and each is challengeable with evidence.
The April 2026 LAS change and DR environments
The move away from file based licensing matters for DR. File based .lic licensing ended on April 15, 2026 with the mandatory move to the cloud connected License Activation Service, affecting CVAD, NetScaler, XenServer, Provisioning, WEM, and XenMobile. Disaster recovery environments that were stood up on the old model and never migrated can now show up as undocumented or non compliant in an audit, creating exposure that has nothing to do with real usage. If your DR estate predates the LAS migration, it deserves a close look before any audit, not during one. The broader change is covered across our LAS guidance.
How to defend disaster recovery licensing
Defending a DR finding follows the same discipline as the rest of an audit, applied to the standby footprint specifically.
First, read the use rights. Your contract and subscription model define how DR and standby capacity are treated, and those terms, not the audit letter, govern. Read them before you respond to anything. Second, document the real state. Evidence that a standby is cold and powered off, or warm but not serving users, is what collapses an inflated DR count. Third, measure independently. Separate real production usage from idle standby capacity, and reconcile DR instances against the entitlements that already cover them. Fourth, never let DR users be added on top of production users as if both run at once. The whole point of DR is that it activates only when production does not.
This is the same counter measurement approach that shrinks audit claims generally, applied to a specific and frequently abused part of the estate. The wider method is in our guide on challenging vendor calculations, and the data collection risks that surround it are covered in usage data collection tools, risks, and alternatives.
Disaster recovery testing and audit risk
DR testing is necessary and should continue, but it should be run in a way that does not manufacture exposure. A test that activates a standby environment and serves real sessions can create a genuine usage event. Keeping tests scoped, time bounded, and documented limits the risk, and any exposure that does arise should be measured against your entitlements rather than assumed. A documented testing regime is also evidence in your favour during an audit, because it shows the standby environment's normal state is dormant.
Getting independent help
We are independent Citrix licensing experts, 100% buyer side, with no reseller or vendor affiliations. We separate real usage from standby capacity, read your DR use rights, and contest any finding that counts idle resilience as production. The full process sits in our Citrix audits guide, and the cost of getting it wrong is set out in our piece on the real cost of failing a Citrix audit.
Frequently asked questions
Does Citrix disaster recovery need to be licensed?
It depends on the state of the DR environment and your contract terms. A cold standby that is powered off and never used to deliver sessions is treated differently from a warm or hot standby that runs alongside production. As of June 2026, the licensing position for DR is governed by your agreement and your subscription model, not by the auditor's default assumption.
How does Citrix count disaster recovery in an audit?
Auditors frequently count DR and standby instances as if they were fully active production, doubling the apparent license requirement. This is one of the most common inflation points in a Citrix audit and is usually challengeable with evidence of the environment's real state and purpose.
What is the difference between cold, warm, and hot standby for Citrix licensing?
A cold standby is powered off until a disaster, a warm standby runs but does not serve users, and a hot standby actively serves alongside production. The licensing treatment differs across these states, and the distinction is central to defending a DR finding in an audit.
How do you defend disaster recovery licensing in a Citrix audit?
Document the DR environment's real state and usage, read the DR and use rights in your contract before responding, and never let the auditor count standby capacity as production by default. Independent measurement separates real usage from idle standby capacity.
Can disaster recovery testing trigger Citrix licensing exposure?
DR testing can create exposure if a standby environment is activated and used to serve sessions during a test without the right entitlements. Keeping tests scoped, time bounded, and documented limits the risk, and any exposure should be measured rather than assumed.