DRM for Offline Video: Persistent Licenses on iOS & Android

TL;DR

• Offline playback works because the device stores a persistent license next to the encrypted download, not because the video file itself gets unlocked.
• A persistent license runs on two separate timers, rental duration and playback duration, and treating them as one "expiration date" is the most common implementation mistake.
• Android uses Widevine through Media3's OfflineLicenseHelper, which returns a keySetId your app has to store and restore. iOS uses FairPlay through AVContentKeySession and AVPersistableContentKeyRequest.
• Copying a downloaded encrypted file to a second device does not transfer playback rights, because the license is bound to the device that requested it.
• Vendor license URLs typically expose rental duration and playback duration as separate query parameters, which is the actual control surface a security review will ask about.
• Offline DRM needs a teardown plan for logout, reinstall, and cancellation. Most implementations skip this and find out the hard way during a security audit.

Offline DRM is not a single expiration date bolted onto a downloaded file. It's a second playback path with its own license type, its own storage rules, and, on both major mobile platforms, two independently configurable timers that most implementations collapse into one.

That collapse is the single most common failure mode in offline video downloads: a license configured with one expiration date instead of two either stays valid indefinitely after first watch or revokes unopened downloads days before anyone gets a chance to open them.

Most teams treat offline DRM as a checkbox their video vendor either has or doesn't. The real question is narrower and far more useful: does the vendor expose rental duration and playback duration as independent, configurable parameters, or is offline playback an all-or-nothing switch with one hardcoded timer underneath it?

This article breaks down exactly how the persistent-license mechanism works on iOS and Android, what the license actually contains, and the specific parameter-level questions that separate a vendor who has really built this from one who is checking a box.

If you're building or evaluating offline video downloads for a SaaS, EdTech, or media app, here's what you'll be able to decide after reading: whether your current DRM vendor exposes the controls you actually need, and what a production-ready offline license implementation looks like on both platforms.

What is Offline DRM?

Offline DRM is a security model that lets a device play downloaded, encrypted video without a live internet connection, because the device holds a persistent license that authorizes decryption locally.

The video file itself is encrypted exactly the same way whether it's streamed or downloaded. What changes is the license: a streaming session gets a temporary license that dies when playback stops, while an offline download gets a persistent license that survives on the device until its own rules say otherwise.

This distinction gets lost constantly in vendor marketing copy that talks about "secure downloads" without ever naming the mechanism. Persistent licensing is the actual term, and it maps directly to real APIs on both platforms, which we'll get into below.

Gumlet, the all-in-one video hosting platform, is a Certified Widevine Implementation Partner listed on Google's public register and operates its own direct FairPlay integration with Apple, which means a project doesn't need a separate certification process with either company before shipping persistent licenses on both platforms.

Video protection platforms that lack this authorized-vendor status typically route DRM requests through a third-party intermediary, which adds a layer of latency and an extra point of failure to every license acquisition. 

What is a Persistent DRM License, and How is it Different From a Streaming License?

A persistent DRM license is a license file stored securely on a device that authorizes offline playback for a defined duration, in contrast to a streaming license, which is requested fresh for each session and discarded when playback ends.

A streaming license exists for the length of one viewing session. A persistent license is designed to outlive the session, sometimes by weeks, which is exactly why it needs its own set of rules.

Three things separate the two:

• Lifespan: Streaming licenses last one session. Persistent licenses last until an explicit expiration condition is met.
• Storage: Streaming licenses live in memory and vanish on app close. Persistent licenses are written to secure, hardware-backed storage on the device.
• Trust requirements: Because a persistent license sits on the device indefinitely, content owners generally demand a higher security bar to issue one, which is why offline playback is commonly blocked on rooted Android devices and jailbroken iPhones.

A persistent license is the entire reason offline playback works. Get its two timers wrong and you either ship downloads that never expire or downloads that die mid-view for no reason the user can see.

Gumlet, the all-in-one video hosting platform, issues persistent licenses through the same DRM infrastructure it uses for streaming, so offline playback doesn't require a separate protection pipeline to set up. 

The Two-Timer Model: Rental Duration and Playback Duration

Every production offline DRM implementation runs on two separate, independently configurable timers, not one expiration date:

1. Rental duration controls how long an unopened license can sit on the device before it's revoked.
2. Playback duration controls how long the license stays valid after the viewer presses play for the first time.

Treat these as one number and you'll either leave licenses valid indefinitely or cut off a viewer mid-episode with no relationship to their actual behavior.

Here's a worked timeline using Gumlet's actual offline licensing parameters, which apply directly to both Widevine and FairPlay license URLs:

1. September 1: User downloads the module. rental_duration is set to 2,592,000 seconds, 30 days.
2. September 1 to September 30: The license sits unopened on the device. If the user never presses play, it self-revokes on September 30.
3. September 20: User opens the module for the first time. This triggers playback_duration, set separately to 172,800 seconds, 48 hours.
4. September 22, same time: The 48-hour playback window closes. The content is no longer playable, regardless of how much of the 30-day rental window remained.

Once playback starts, rental_duration stops applying entirely. Only playback_duration governs the license from that point.

This is the single most common mistake in offline DRM setups: configuring only one duration and assuming it covers both scenarios. It doesn't. A 30-day-only policy leaves licenses playable indefinitely after first watch. A 48-hour-only policy revokes unopened downloads within two days, which frustrates anyone who downloaded a course module for a flight next week instead of tonight.

On Gumlet, these parameters attach directly to the license URL as query strings:

• https://widevine.gumlet.com/licence/5f2bdde3e93619b8859d8831/abcde123456?rental_duration=2592000&playback_duration=7200
• https://fairplay.gumlet.com/licence/5f2bdde3e93619b8859d8831?storage_duration=2592000&playback_duration=7200

Widevine uses rental_duration, FairPlay uses the equivalent storage_duration, and both accept playback_duration as a separate parameter.

If you're evaluating a vendor for offline DRM, ask to see the actual license URL structure and confirm both timers are independently settable.

How Offline DRM Playback Works, Step-by-Step

Offline DRM playback follows a fixed sequence: the device requests a persistent license while online, downloads the encrypted media, stores both locally, then decrypts and plays without a network connection until the license's own rules say otherwise.

1. Authenticate the user: The app confirms the viewer is entitled to the content through your existing auth layer.
2. Request an offline-capable license: The client explicitly asks the DRM system for a persistent license, not a streaming one. This is a different API call on both platforms, covered below.
3. Download the encrypted media: The same encrypted HLS or DASH segments used for streaming get pulled to local storage. No separate encoding pipeline is needed.
4. Store the license and its key reference securely: On Android this is a keySetId. On iOS it's persistable key data. Both go into secure, sandboxed storage.
5. Restore the license when offline: When the viewer opens the app without connectivity, the player loads the stored license reference instead of requesting a new one.
6. Decrypt and play until the policy expires: Playback proceeds locally until rental duration or playback duration runs out, whichever applies.

The architecture behind this is straightforward once you see it laid out: your app talks to an entitlement or auth server, which talks to a DRM license server, which issues the persistent license. That license and the encrypted media both land on the device, and the offline player reads both when the network is gone.

Teams often build the download pipeline first and treat the license request as an afterthought bolted on later. Build them together. A downloaded file with no matching license is not a partial feature, it's a black screen with no error message, and no amount of retry logic on the download side fixes a license that was never requested correctly in the first place.

How Offline DRM Works on Android With Widevine

Android handles offline DRM through Widevine, using the Media3 library's OfflineLicenseHelper class to request, store, and restore a persistent license identified by a keySetId.

This is Google's DRM system, and it's the one your app talks to for any Android device running Chrome, Edge, or a native Widevine-integrated player.

The implementation checklist looks like this:

• Call OfflineLicenseHelper.downloadLicense() to request a persistent license for the target content.
• Store the returned keySetId, a small opaque identifier, alongside your download record. This is not the decryption key itself, it's a reference the DRM stack uses to look up the stored license.
• Attach that keySetId to the DownloadRequest object so the downloaded media and its license stay linked.
• When restoring playback offline, load the session using the stored keySetId rather than requesting a fresh license.
• Call renewLicense() or releaseLicense() when the license needs to be extended or explicitly revoked.

Media3 also defines four license modes worth knowing by name, because vendor documentation and your own logs will reference them constantly:

Mode	What It Does
MODE_PLAYBACK	Uses an existing stored license to play content, online or offline
MODE_QUERY	Checks a license's remaining validity without triggering playback
MODE_DOWNLOAD	Requests a new persistent license during the download step
MODE_RELEASE	Explicitly revokes a stored license, freeing the device-side storage

Media3 also exposes getOfflineLicenseKeySetIds() on supported implementations, which lets your app enumerate every stored offline license on the device.

Don't treat this as your primary source of truth. Your own download records in your app's database should remain the authoritative mapping between content and licenses. Use the Media3 enumeration as a verification check, not a dependency.

A keySetId is not a decryption key and should never be treated like one. It's a lookup reference. The actual key material stays inside the platform's secure DRM storage, which is exactly the separation that keeps a copied file useless on another device, more on that below.

Gumlet's Widevine implementation supports Widevine L1 hardware-backed security, the level Netflix and Disney+ require for HD and above, so persistent licenses issued through Gumlet aren't capped to a lower-security fallback tier on supported devices. 

How Offline DRM Works on iOS With FairPlay Streaming

iOS handles offline DRM through Apple's FairPlay Streaming, using AVContentKeySession to request a persistent key and AVPersistableContentKeyRequest to convert a standard content-key request into one that can be stored and reused offline.

This is the iOS-side mirror of Widevine, and the two systems solve the same problem with different object names.

The implementation flow:

1. Set up an AVContentKeySession for the asset you're about to download.
2. When the system delivers a content-key request, call the method that converts it into an AVPersistableContentKeyRequest instead of a standard, session-only request.
3. Send the resulting SPC (Server Playback Context) to your FairPlay key server.
4. Receive the CKC (Content Key Context) response from your license server.
5. Generate persistable key data from that response.
6. Store the persistable key data in your app's secure storage, tied to the downloaded asset.

For renewal, AVContentKeySession's delegate includes callbacks specifically for handling expiring response data, which means your app can be notified before a key lapses rather than discovering it only when playback fails.

That renewal logic has to be coordinated with whatever policy your key server enforces, since the delegate tells you a renewal is needed but doesn't decide the business rule for whether to grant one.

One detail worth clearing up because it trips up a lot of implementations: Apple does not require a separate key ID purely because a request is persistent. The same content and the same key ID can support both an ordinary streaming session and a persistable offline download. Your app decides which kind of request to make, not the content itself.

Because Gumlet holds direct FairPlay authorization from Apple, its license server can issue persistable content keys without routing through a third-party FairPlay proxy, which is the step that adds the most latency and the most operational risk in implementations built on non-authorized vendors. 

Widevine Offline License vs. FairPlay Persistable Content Key

The two systems solve the same problem, but the terminology and APIs diverge enough that a side-by-side comparison saves real confusion, especially for teams shipping both platforms from one codebase.

Feature	iOS / FairPlay Streaming	Android / Widevine
Persistent-license artifact	Persistable content key data	keySetId
Main framework or API	AVContentKeySession, AVPersistableContentKeyRequest	Media3 OfflineLicenseHelper
Encrypted media format	HLS with cbcs encryption (CMAF/fMP4)	DASH or HLS with CENC (CMAF/fMP4)
Renewal support	Delegate callbacks for expiring response data	renewLicense()
Expiration handling	Enforced by FairPlay and the OS DRM layer	Enforced by Widevine and the Android DRM layer
Offline playback trigger	Load stored persistable key data, no live session	MODE_PLAYBACK with stored keySetId

Neither system is meaningfully more or less secure for offline playback when correctly implemented. The practical difference is developer experience: FairPlay's flow is tighter to Apple's own APIs and harder to test outside real hardware, while Widevine's Media3 integration gives you more visibility into license state through query modes and explicit key enumeration.

If your team is shipping both platforms, budget more implementation and QA time for FairPlay, since Apple explicitly recommends testing on physical devices rather than simulators for DRM flows.

Encryption format details above reflect Gumlet's current DRM implementation as documented in its developer docs; confirm against your own vendor's documentation if evaluating a different platform.

For a deeper platform-by-platform breakdown, our guide on FairPlay vs. Widevine DRM covers the decision outside the offline-specific context covered here.

Does Copying a Downloaded Video Transfer the License?

No. Copying a downloaded, DRM-protected video file to another device does not transfer playback rights, because the persistent license is bound to the specific device and account that requested it, and the copied file is unusable without a matching, valid license already present on the receiving device.

Say a user downloads a protected course module to their Android tablet, then copies the encrypted file to a second Android phone using a file transfer app. The video file arrives intact, but it will not play. The keySetId on the original tablet points to license material stored in that device's secure DRM storage, and that storage does not travel with the file. The second phone has an encrypted blob and nothing that can decrypt it.

This is the actual security boundary that matters, and it's worth stating clearly because it's the question people ask most often when they're deciding whether offline DRM is worth building at all: the app stores encrypted media and DRM authorization material as two separate systems, and content should remain unusable if the media file alone is copied out of that context.

This is also why device binding, not just encryption, is the control that matters most in a security review. An encrypted file with no device-bound license is still just a file waiting for a key. 

Gumlet's video protection suite has blocked more than 150 million downloader-app install attempts across its customer base, and the pattern holds consistently: attempts spike specifically around content that lacks persistent-license binding, not content that has it. Once the license is tied to the device and account that requested it, a copied file has no path to playback, regardless of how many times it gets moved or shared. 

How License Expiration and Renewal Work

An offline DRM license expires when either its rental duration or its playback duration runs out, whichever condition is reached first, and renewal requires the device to reconnect and successfully request an updated license from the server.

Renewal follows a predictable four-step sequence:

1. Device reconnects to the internet.
2. App validates the user's continued entitlement, subscription still active, course still purchased, whatever your access model requires.
3. Client requests a renewed license from the server.
4. Server issues an updated license that replaces the stored one, extending validity under the current policy.

Should you renew before expiration or wait until it happens?

Renew proactively. Attempt renewal during any normal online app session once remaining validity drops below a threshold your product team sets. A 30-day rental window might renew at the 5-day mark for a course platform where learners download modules in batches.

A media app with daily active users might not need proactive renewal at all, since the user reconnects constantly anyway.

Revocation before natural expiration is also possible and worth planning for separately from expiration. If a subscription lapses, the license itself doesn't self-destruct instantly since it's sitting offline on a device with no way to receive that signal.

The next time the device reconnects and the app performs its normal entitlement check, that check should fail and trigger revocation instead of waiting for the stored license's own timer to run out naturally. This is a product decision your team makes, not something the DRM system enforces automatically.

Can Offline DRM Be Bypassed by Changing the Device Clock?

No, not on a correctly implemented system. Production DRM systems do not rely solely on an app-readable wall clock for expiration enforcement, because that clock is trivially editable by the user.

Widevine and FairPlay both enforce expiration at the DRM and secure hardware layer rather than trusting the operating system's visible clock setting alone.

This matters for a security review specifically because it's the first thing a technically literate evaluator will ask. If a vendor's answer to "what stops a user from setting their clock back a year" is a shrug, that's a signal their offline implementation is checking a UI box rather than using the platform's actual secure clock and CDM (Content Decryption Module) enforcement path.

What Happens on Logout, Reinstall, or Subscription Cancellation?

On Logout

Hide downloaded titles from the account immediately in the UI, and prevent playback until the matching user entitlement is restored on next login.

Whether you also actively release or delete the underlying license at logout time is a security policy decision your team makes based on how sensitive the content is.

Regulated or IP-sensitive content generally warrants immediate release. Lower-stakes content can tolerate leaving the license dormant until it expires naturally.

On App Reinstall

On app reinstall or app data clearing: offline availability is lost, because the stored license references and the downloaded files both live in app-scoped storage that gets wiped.

Treat offline downloads as recoverable entitlements, not permanent files. The user's underlying access to the content doesn't change, only their locally cached copy does.

Design the re-download flow to be fast and unsurprising rather than treating this as an edge case.

On Subscription Cancellation

The license itself has no way to know cancellation happened while the device is offline. The correct enforcement point is the same entitlement check described in the renewal section: the next time the app reconnects, that check fails, and playback stops or the app prompts a renewal or reacquisition flow depending on your business rules.

---

Don't build a system where an offline license, once granted, has no path to revocation short of its own natural expiration. That design might pass a demo, but it will not pass a serious security audit, and it will not survive a scenario where a customer needs a license pulled immediately for a compliance reason.

For teams building the broader access-control layer around this, our guide on building a Multi-DRM Setup walks through the entitlement and license-server architecture this section assumes.

How to Delete an Offline DRM Download Correctly

Deleting a download is not just removing a file from disk. A correct teardown removes playback access first, then the license, then the media, in that order, so there's no window where a stale license outlives its associated content.

1. Remove playback access in the app's UI immediately, before touching any stored data.
2. Release or revoke the offline license where the platform supports it, MODE_RELEASE on Android or the equivalent explicit invalidation on iOS.
3. Delete the persistent license reference from your app's local database.
4. Remove the downloaded encrypted media file from device storage.
5. Clear any app-level metadata tied to that download, expiration timestamps, download-state flags, and so on.

Skipping step two and jumping straight to deleting the file leaves an active license sitting in the device's secure DRM storage with nothing to apply it to.

That's not a functional problem, since there's no file left to decrypt, but it's sloppy hygiene that shows up when Media3's key enumeration or an internal audit checks for orphaned licenses.

How to Test Offline DRM Before Production

Test offline DRM across a defined matrix of scenarios on real devices, not simulators, because Apple and Google both document unreliable DRM behavior on virtual devices. The most common production failures trace back to a scenario nobody tested before launch.

Test Case	Android / Widevine Expected Behavior	iOS / FairPlay Expected Behavior
First download	License and media both download, keySetId stored	Persistable key data generated and stored
Airplane-mode playback	Plays using stored keySetId, MODE_PLAYBACK	Plays using stored persistable key
Expired license	Playback fails, app prompts renewal	Playback fails, delegate signals expiration
Renewal	renewLicense() succeeds, validity extended	Delegate handles expiring response, key updated
Logout	Title hidden, playback blocked	Title hidden, playback blocked
Subscription expiry	Next entitlement check fails, license revoked	Next entitlement check fails, key invalidated
Device reboot	License persists in secure storage	License persists in secure storage
App restart	Download state and license both restore	Download state and license both restore
App data removed	License and file both lost, re-download required	License and file both lost, re-download required
Corrupted download	App detects and prompts re-download	App detects and prompts re-download
License-server outage	Existing offline licenses keep working until their own expiry	Existing offline licenses keep working until their own expiry
Delete and re-download	Old license released, new one issued	Old key invalidated, new one issued

What telemetry should you actually track for this? Six events cover the operational surface without exposing sensitive key material: license acquisition success or failure, download completion, offline playback start, expiration-triggered rejection, renewal result, and license release or delete result.

Log these with content ID, user or account ID, and timestamp. Never log raw key material or license payloads.

Evaluating an Offline DRM Vendor: What to Actually Ask

Most vendor pages describe offline DRM in terms like "enterprise-grade" and "studio-approved" without naming a single API, parameter, or control surface. That's the gap this whole article has been closing, and it's also the exact gap to probe when you're choosing who builds this for you.

Ask any offline DRM vendor to show you the actual license URL structure and confirm rental duration and playback duration are independently configurable. If they can't produce a working example like the one shown earlier in this article, the offline support is theoretical, not production-ready.

A few more decision rules worth applying during evaluation:

• Avoid vendors whose offline documentation covers only one platform: If you can find detailed Widevine implementation guidance but nothing substantive on FairPlay, or the reverse, that's a signal their cross-platform offline support is thinner than the marketing page implies.
• Ask what happens to an active offline license on subscription cancellation: If the honest answer is "it plays until it naturally expires with no revocation path," decide whether that's acceptable for your content sensitivity before you build on it.
• Confirm the vendor's offline DRM works with your existing paid plan tier rather than requiring a separate infrastructure migration: on Gumlet, video DRM is available as an add-on starting at the Creator tier, which means teams can add offline licensing without re-platforming their entire video stack.Information on tier-wise feature availability is available on Gumlet’s pricing page.

Gumlet's tokenized delivery model and offline licensing parameters both operate at the same session and device-binding level, which is the architecture that makes a copied file useless without a matching license, the exact point covered earlier in this article.

Teams evaluating this for an OTT app, an EdTech platform with offline lessons, or an internal training tool with airplane-mode access can check out Gumlet’s video protection features in full, or book a walkthrough of the offline licensing setup directly.

OTT teams carry the sharpest version of this evaluation, because downloaded content is often premium, licensed material with contractual obligations attached. A studio licensing agreement will frequently specify exact rental and playback windows, which means a vendor that can't independently configure both timers cannot satisfy that contract term, full stop.

That's the same rental-duration-versus-playback-duration question from earlier in this article, just with a studio's legal team asking it instead of your own security review.

Frequently Asked Questions

1. Does offline DRM require internet access when I press play?

No, not if the encrypted media and a still-valid persistent license are already stored on the device. Internet is required for the first license acquisition, for renewal, and for revalidation after a cancellation or revocation event.

Once both pieces are in place and the license hasn't hit its rental or playback expiration, playback works entirely offline, which is the whole point of the persistent-license model covered throughout this piece.

2. Can I renew an offline DRM license before it expires?

Yes. Android's Media3 exposes renewLicense() directly, and iOS's AVContentKeySession delegate includes callbacks for handling expiring response data before a key lapses.

Attempt renewal during any normal online session once remaining validity drops below a threshold your product sets, rather than waiting for expiration and forcing a re-download. Proactive renewal during normal app use beats reactive re-acquisition after a failed playback attempt.

3. What happens when an offline DRM license expires but the file is still on my device?

The encrypted file stays on disk, but it becomes unplayable the moment the license's rental or playback duration runs out. The app should either offer a one-tap "renew download" action if the user is back online, or automatically remove stale files past a defined grace period rather than leaving orphaned encrypted files with no working license sitting on the device indefinitely.

4. Can DRM limit how many devices can hold offline downloads?

The DRM license itself handles local, per-device authorization, but device-count limits across an account are typically enforced by your service backend, not the DRM system directly.

If your policy is three offline devices per account and a fourth device requests a download, your entitlement server should reject that request before it ever reaches the DRM license server. Build the device-count check into your backend, not into the DRM layer.

5. What telemetry should I track for an offline DRM implementation?

Track license acquisition success or failure, download completion, offline playback start, expiration-triggered rejection, renewal result, and license release or delete result, tagged with content ID and account ID.

Never log raw key material, license payloads, or decryption keys in any telemetry system, since that defeats the entire security model this piece has walked through.

6. What should I look for in a video DRM vendor to support offline downloads?

Confirm the vendor holds direct Apple and Google authorization for FairPlay and Widevine rather than reselling through an intermediary, and confirm rental duration and playback duration are exposed as independently configurable parameters on the license URL.

Gumlet meets both criteria and provisions working DRM credentials automatically on signup, so testing offline licensing doesn't require a separate approval process with either platform.

Closing Thoughts

Offline DRM works because the device holds two things separately, encrypted media and a persistent license, and because that license runs on two independent timers rather than one vague expiration.

If you're building offline downloads right now, the next step is concrete: pull up your current vendor's license URL structure and check whether rental duration and playback duration are actually separate, settable parameters.

If they're not, you're one edge case away from a blank-screen support ticket with no clear cause. Gumlet's DRM offline licensing documentation shows the working parameter set, and it's available as an add-on on any paid Gumlet plan starting at Creator tier, so testing it against your own content doesn't require a full platform migration first.