Custom OTT Development: Netflix-Style Device Management

Why Fora Soft wrote this playbook

Ship a Netflix-style service with a broken device layer and you find out the expensive way: households running eleven streams on a two-stream plan, studios refusing to license because your DRM logs do not add up, and a CDN bill that scales faster than revenue. Custom OTT development lives or dies on this invisible layer: the Multi-Device Management (MDM) backend that binds a subscription to the right screens and enforces concurrent-stream caps per tier.

We have built streaming products since 2005 — 250+ delivered projects, from OTT backends and white-label Smart TV apps to WebRTC clusters and DRM-protected VOD libraries. One of them is Mangomolo, an end-to-end OTT platform we extended for Discovery MENA, Dubai Media, and SABC+ that now serves 30M+ daily viewers, where we built the Wowza module for SCTE-35 ad-marker recognition and server-side ad insertion. Across those builds, one question comes back in almost every kickoff: how do we manage devices, streams, and entitlements the way Netflix does — without a Netflix-sized team?

This playbook is what we would tell a founder or a product VP on a first call. It covers the architecture, the DRM choices, the cost math, the off-the-shelf alternatives, and the five pitfalls that turn OTT launches into post-mortems. If you want the short version, our Internet TV & OTT platform development page summarises our OTT development services, scope, and deliverables; if you are weighing build vs. buy, keep reading. Every number below is sourced from public benchmarks, our own project ledgers, or vendor pricing sheets; where we are not certain, we say so.

What a custom MDM layer actually does

In OTT, the Multi-Device Management layer is the invisible contract between a subscription and a screen. It answers three questions for every playback request: Who is asking? On what device? Under which plan? Every other decision (bitrate ladder, DRM choice, ad insertion, recommendations) assumes those answers are correct.

Concretely, a custom MDM layer handles:

• Device enrollment and fingerprinting — capturing a stable identity for each phone, browser, smart TV, or console.
• Concurrent-stream enforcement — 1, 2, or 4 simultaneous streams per plan, across any device mix.
• Profile and parental-control binding — which profile is on which TV right now, and what can it watch.
• Entitlement checks — subscription valid, geo allowed, content windowed for this region and device.
• DRM license brokering — requesting Widevine, FairPlay, or PlayReady keys only after entitlement is confirmed.
• Session lifecycle — create a session, heartbeat it, migrate it, then clean it up across devices.
• Device deactivation and cool-downs — letting users sign out of lost devices, and preventing device-swap abuse.

The name confuses buyers because it collides with enterprise mobile device management (Intune, Jamf). Those are irrelevant here. If you are building a streaming product, MDM means the layer that stops one Standard-tier household from running eleven streams. The diagram below is the whole control plane on one page — five services on the play path, with the concurrency check sitting inside the DRM broker where a reverse-engineered client cannot reach it.

Figure 1. The five-service MDM control plane. Every playback request flows left to right; the concurrent-stream check lives in the DRM license broker.

What leading OTT services actually enforce

Before designing your own MDM policy, look at what the majors do today. The numbers below are from each service’s public help and pricing pages, cross-checked in July 2026 — and they moved in 2026, so old blog posts will mislead you.

Two patterns jump out. First, concurrent streams are the product. They are how every service differentiates pricing tiers, and 2026 sharpened that: Amazon put 4K and a fifth stream behind the new Prime Video Ultra tier, and Netflix quietly dropped its old Basic plan. Second, device registration is effectively unlimited. Only the number of simultaneous sessions is gated. Your MDM layer has to hold both truths at once: log every device a subscriber ever used, but block only the N+1st active playback.

Reference architecture: five services that carry the load

A production-grade OTT MDM is five cooperating services plus a streaming delivery stack (Figure 1). Swap any one of them for a SaaS, but understand the trade-off first.

1. Device Registry

The canonical store of every device a user has ever enrolled. Each record holds a stable device ID (Android ID, IDFA, app-generated UUID for web), a device fingerprint (user agent, screen, WebGL hash), model, OS, app version, last-seen IP, and last-seen timestamp. Netflix-scale clusters run this on Cassandra with multi-region replication; a 1–5M-subscriber platform can start on PostgreSQL or DynamoDB and migrate later. Read path is the hot one — every session check hits the registry.

2. Session Manager

Creates playback sessions, keeps them alive, and tears them down. This is the only service that actually answers “how many streams is user X running right now?” and it has to answer in under 50 ms at the 99th percentile. Redis is the default: atomic INCR/DECR on per-user counters, TTL-based auto-expiry, sub-millisecond reads. A Redlock or a Lua script guards against the race when two sessions start in the same tick.

3. Entitlement Service

Given a user, a device, and a title, can this play? This service joins four inputs: subscription state (from billing), content rights (from CMS), geo (from IP lookup), and concurrent-stream count (from the session manager). It is the gatekeeper for the DRM license request; no entitlement, no license, no playback. Keep it synchronous and stateless, cacheable for 30–60 seconds per user.

4. DRM License Broker

A thin proxy in front of Widevine, FairPlay, and PlayReady license servers. The broker attaches session and device claims to each license request, so the DRM can deny or short-license a session that has already exceeded its tier cap. This is also where output-protection policy (HDCP 2.2, screen-capture block) is injected into the license response. It is the one place account-sharing enforcement is genuinely hard to defeat.

5. Analytics & QoE pipeline

Every client sends start, heartbeat (10–60 s), quality switch, buffer and error events. These flow into Kafka or Kinesis, get aggregated by Flink or Spark Streaming, and land in Snowflake or BigQuery. Netflix’s Keystone moves trillions of events per day through this pattern; a 1M-subscriber platform will process tens of billions per month. Your MDM layer consumes the same stream for anomaly detection — impossible-geo logins, rapid device churn, session heartbeat loss.

Around these five sit the streaming delivery stack — packager, multi-CDN, origin shield, and player SDKs, plus the client apps for iOS, Android, web, tvOS, Android TV, Fire TV, Roku, and smart TVs. Each is its own OTT app development track, with its own store review and certification path. For the encode-and-deliver layer specifically, we cover patterns in scalable video streaming development and edge computing in live streaming.

Multi-DRM: Widevine, FairPlay, PlayReady

Premium studios require all three major DRMs. The trick is that you do not encode your library three times. Package once in CMAF with Common Encryption in cbcs mode (CENC, ISO/IEC 23001-7), then serve DASH manifests to Android, Chrome, and smart TVs and HLS manifests to Apple devices from the same segments. Widevine and PlayReady both accepted cbcs back in 2018, and FairPlay has always used it — so one encode covers everyone except a few legacy set-top boxes that still need cenc.

Figure 2. One CMAF mezzanine, three DRM systems. Package with cbcs once; fan out to Widevine, FairPlay, and PlayReady by manifest, not by re-encode.

Practical advice. Almost no one builds their own license server. Managed multi-DRM covers all three at a fixed monthly rate — EZDRM’s Universal Complete tier (Widevine + PlayReady + FairPlay over CMAF) runs about $299.99/month for 20,000 licenses, which works out near $0.003–$0.005 per issued license once you are at volume. You still own the license broker: the service that injects your session and device context into each request. That part is non-negotiable: without it, you cannot enforce concurrent streams or output protection. For the packaging mechanics behind this, our team’s deep dive on DRM packaging and common encryption walks through cenc vs cbcs in detail, and Apple documents its side in the FairPlay Streaming spec.

Concurrent-stream enforcement patterns

Streaming services enforce concurrent-stream limits three ways: a token checked at license time, heartbeat sessions that expire, and a Netflix-style soft-cap with grace. All three work at scale; they differ in UX, attack surface, and operational cost, so in production you ship all three (Figure 3).

Figure 3. The three enforcement patterns and where each one earns its keep. The counter is always server-side, ideally in the DRM broker.

1. Token-at-license-time. The player requests a short-lived (5–15 min) playback token from your entitlement service. The token is presented at the DRM license endpoint; the broker denies or short-licenses if the concurrent-stream counter is already at cap. Simple and deterministic, but vulnerable to token replay unless you bind the token to a device fingerprint. This is the pattern castLabs documents as short-license-plus-renewal.

2. Heartbeat sessions. The player pings the session manager every 10–60 s. Missed heartbeats expire the session within ~5 min, freeing a concurrent slot. Good at catching an abandoned session on a locked iPad. It adds 1–5% control-plane traffic — usually invisible.

3. Soft-cap with grace. Netflix-style: allow the N+1st stream for 10–30 s so a family member switching rooms is not punished, then terminate the oldest session if the user does not stop it themselves. Best UX, most complex to implement correctly.

Token-at-license-time is your legal wall; heartbeat catches the real world; soft-cap is what separates you from cheaper services that kick users mid-episode. Whichever you lead with, the counter lives server-side. The player can lie, cache, or be reverse-engineered — count there and it is theatre.

Device fingerprinting and account-sharing detection

Netflix’s paid-sharing rollout from 2023 is the reason this matters commercially. Analysts credit it with tens of millions of net new paid members; Netflix itself stopped breaking out subscriber counts in early 2025 (it ended 2024 at 301.6M and now talks about ~700M viewers), so treat the exact figure as an estimate. Disney+, Hulu, and Max have all since shipped their own enforcement. All of it depends on device fingerprinting done at the MDM layer.

A practical fingerprint combines a stable device ID (IDFA, Android ID, or an app-issued UUID for web and TV), a user-agent hash, a screen and WebGL hash for browsers, an IP + ASN lookup for home-network clustering, and a timezone. No single field is unique; the tuple is. Store the tuple at enrollment and compare on every session creation.

For account-sharing detection, the heuristics that actually work:

• Impossible geo. Two active sessions from IPs more than 1,000 km apart within 60 minutes.
• Device churn. More than 30–50 unique device fingerprints per account per month. Legitimate households rarely hit 10.
• ASN diversity. More than three distinct home ISPs in a rolling 30 days. Travelers hit this; shared passwords hit it twice as often.
• Timezone drift. Timezone changes faster than a human can fly.

None of these should trigger a hard block. Netflix’s public approach is a soft warning, then a one-time code on the primary TV, then an upsell to a paid extra-member seat. The false-positive rate on legitimate travelers is roughly 0.5–2%; the revenue lift more than covers the churn. Log the IP trail so you can audit the false positives instead of guessing.

Packaging: CMAF, HLS, DASH, and low-latency

CMAF is the right default for any new OTT in 2026. One fragmented-MP4 segment set, two manifests (MPD for DASH, M3U8 for HLS, RFC 8216), three DRMs covered. Typical segment length is 2–6 s for VOD and 1–2 s chunks for low-latency live. Storage and CDN costs drop roughly in half compared with separate HLS/DASH pipelines.

For live, low-latency HLS (LL-HLS) and low-latency DASH close the gap to ~3–5 s glass-to-glass, versus 10–30 s for legacy HLS. Players that support LL-HLS include Safari 14+, ExoPlayer, Shaka, and Video.js with hls.js. Our guide to custom video player development covers the player-side trade-offs in detail.

Codec choice depends on device reach. H.264 is still the safety net; HEVC cuts bitrate 30–40% where supported; AV1 cuts roughly another 30% again. AV1 hardware decode has quietly become normal — it now covers around 80% of active streaming devices, and Netflix reports even higher on certified TVs — but pre-2020 smart TVs still lack it, so keep an HEVC or H.264 fallback rung. We keep a running tally in our note on the state of AV1 in 2026. The pragmatic ladder: H.264 baseline for legacy, HEVC for primary delivery, AV1 where the CDN and player chain support it.

Security, compliance, and content protection

Premium-content licensing brings auditors. The MPA/CDSA Trusted Partner Network (TPN) evaluates platforms on DRM implementation, key management, logging and incident response before major studios license new releases. Practical implications:

• Widevine L1, PlayReady SL3000, FairPlay with HDCP 2.2. Anything below is a blocker for 4K and for most new studio windows.
• Hardware-backed key storage. License servers must sign keys with HSM-protected certificates; vendors like EZDRM and Axinom handle this.
• Audit logs for every license issued. Studios can and will ask. Retain 12–24 months of license logs.
• GDPR on device fingerprints. IP, IDFA, and Android ID are PII. Document retention, consent and deletion; two years is a common ceiling.
• Geo enforcement. Content windows are territorial. Check IP + ASN per entitlement request; keep the rules out of the player.

None of this is exotic, but all of it is discovery in month six of a build that started without compliance on the roadmap. Plan it in from week one.

Analytics hooks that pay for themselves

Analytics is where the MDM stream earns its second keep. The control-plane data (session starts, heartbeats, quality switches, errors) is exactly the stream a QoE dashboard needs. Plumb it once, use it for both enforcement and insight.

Six metrics earn dashboard space on day one:

• Startup time. Time from play tap to first frame. Under 2 s is good; over 8 s predicts churn.
• Rebuffering ratio. Buffer-wait seconds divided by total session seconds. Stay under 1%; 5% is a crisis.
• Exit-before-video-start. Users who tapped play and left before a frame. Almost always a manifest or DRM error.
• Bitrate switches per minute. Signals an unstable network or ABR algorithm.
• Dropped frames by device model. Surfaces the one smart TV chipset that hates your HEVC profile.
• License failure rate by DRM. Above 0.5% is a licensing-config bug hiding in plain sight.

Plug in Conviva, NPAW, Mux Data, or a Kafka-to-Snowflake pipeline of your own. For the first 100K subscribers, a managed QoE platform is the cheaper option. Above 1M, owning the pipeline often wins on both cost and latency.

Build vs. buy: vendor comparison matrix

Most founders overestimate how much they have to build. Most enterprises underestimate how much off-the-shelf will cost at scale. The honest answer for OTT development usually lies in splitting the stack (Figure 4).

Figure 4. Indicative first-year cost and control by path. The custom control plane pays back around 500K–1M subscribers.

Our typical recommendation: use Mux, Bitmovin, or AWS Elemental for encode and packaging; use EZDRM or Axinom for license servers; build the MDM, entitlement, and analytics layers yourself. That is the split where custom engineering compounds, and where our Agent Engineering approach (AI agents assisting our engineers across design, code, and test) makes us faster than headcount-only agencies. For a broader cost view, see our breakdown of video streaming app development cost.

Cost model: a realistic 12-month build

Numbers below reflect our own 2026 estimates for a custom OTT with a Netflix-class MDM, delivered with Agent Engineering. They are deliberately conservative; we would rather come in under than quote high.

Phase 1 — MVP (4 months). Device registry, session manager on Redis, entitlement service, multi-DRM broker wired to a managed license vendor, HLS/DASH via CMAF, web + iOS + Android apps. Budget: ~$80K–$140K depending on design scope and integration count.

Phase 2 — TV + Smart TV (2–3 months). tvOS, Android TV, Fire TV, Roku, and LG/Samsung where the business case holds. Each additional platform is two to six weeks; smart TVs add QA and certification overhead. Budget: ~$40K–$80K.

Phase 3 — Scale and analytics (2 months). Kafka pipeline, QoE dashboard, account-sharing model, admin tooling, observability. Budget: ~$30K–$60K.

Running costs at 1M subscribers. Here is the arithmetic that surprises people. CDN egress dominates. A heavy viewer who watches ~40 hours/month at an average 5 Mbps pulls 40 h × 3,600 s × 5 Mbit / 8 ≈ 90 GB. At a blended $0.006/GB (about $6/TB with volume commits) that is ~$0.55 per heavy viewer per month. Not every subscriber streams every month, but with a few hundred thousand active on a mid-engagement catalogue, egress alone lands in the low-to-mid six figures per month, the single biggest line item. Transcoding, license fees, and cloud compute add another $10K–$40K/month. The MDM layer itself is cheap to run; most of the cost is the pixels it protects.

Mini-case: fixing a concurrent-stream counter that drifted

A recent engagement asked us to rebuild a subscription video product whose concurrent-stream counter drifted under load. The symptom was classic: users on the Standard tier (2 streams) could occasionally start a third; on Premium (4 streams), a seventh would sneak through. The root cause was a non-atomic counter updated through a REST call that ran in ~120 ms, just enough for two simultaneous sessions to both read “1” and both write “2.”

We migrated the counter to Redis with Lua scripts for atomic check-and-increment, bound every session token to a device-fingerprint hash, and pushed the concurrency check into the DRM license broker so it ran after the entitlement stamp but before a key was issued. Twelve weeks end to end. The overshoot rate dropped from about 2.3% of sessions to zero within a week of ramp, support tickets tagged “wrong stream count” fell 94%, and the client raised pricing tiers without a wave of refunds.

That is the same control plane we shipped for Worldcast Live, an HD concert platform that holds sub-second latency for 10,000 simultaneous viewers with pay-per-view and donation monetisation. Want a similar review on your stack? Book a 30-min concurrency audit — bring your architecture diagram, leave with a punch list.

A decision framework — pick your path in five questions

1. What is your 18-month subscriber target? Under 100K, start on Vimeo OTT or JW Player. 100K–500K, Mux or Bitmovin plus a thin custom MDM. Over 500K, build the control plane yourself.

2. Do you need premium studio content? If yes, multi-DRM (Widevine L1 + FairPlay + PlayReady SL3000) is mandatory and a managed license vendor is the fastest path. If no, Widevine L3 alone may be enough for day one.

3. How many device platforms on launch day? Every platform beyond iOS/Android/web adds 4–8 weeks and certification overhead. Prioritise by CAC payback, not coverage vanity.

4. Will you use tier-based concurrent streams? If yes, your MDM has to own the session counter atomically — not the player, not the billing system.

5. Do you need geo or content-window control? If yes, the entitlement service has to see IP + ASN + country claim per request. Retrofit is painful; design it in from week one. If four of your five answers point at custom, that is your signal to scope a build — and where we can help.

Five pitfalls that derail OTT launches

1. Counting streams in the player. The player can lie, cache, or be reverse-engineered. The concurrent-stream counter must live server-side, ideally in the DRM broker. Anything else is theatre.

2. Long-lived DRM tokens. A 24-hour license token is a replay attack waiting to happen. Keep playback tokens at 5–15 minutes, bound to a device fingerprint, and rotate on session transitions.

3. Using the same encryption mode for FairPlay and Widevine the old way. FairPlay requires cbcs; Widevine historically shipped cenc (AES-CTR). CMAF reconciles this with a single cbcs encode both ecosystems accept, but older toolchains still mis-package. Test on an actual Apple TV before launch.

4. Ignoring smart TV fragmentation. Samsung Tizen 2019, LG webOS 4, and pre-2021 Roku models have non-trivial DRM and HEVC gaps. Decide up front which years you support; every year back is another six weeks of QA.

5. Treating analytics as a post-launch project. Without QoE data from day one, you cannot tell whether a 3% rebuffering rate is your CDN, your packager, your player, or one broken HEVC profile on a single TV chipset. Plumb the pipeline before you open beta.

KPIs to put on the dashboard

Quality KPIs. Startup time under 2 s p75 on broadband, under 4 s on mobile; rebuffering ratio under 1%; exit-before-video-start under 0.5%. Break all three down by device family — one bad smart TV profile can ruin a global number.

Business KPIs. Concurrent-stream utilisation per tier (are Premium users actually using the four streams they pay for?); account-sharing conversion to a paid extra-member seat; tier-upgrade rate driven by device-limit warnings. These are the numbers that pay for the MDM layer.

Reliability KPIs. DRM license failure rate under 0.5%; session-manager 99th-percentile latency under 50 ms; overshoot incidents per million sessions at zero. If you cannot get overshoot to zero, your counter is not atomic.

When not to build a custom MDM

A full custom MDM is the wrong investment if you are launching niche SVOD with a handful of creators, running a time-boxed marketing campaign, or publishing an internal corporate learning library. The economics do not work below ~50K paying users. Use Vimeo OTT, JW Player, or a turnkey white-label platform, ship in weeks, and revisit the build question only after you have product-market fit and a CDN bill that justifies the headcount.

Similarly, if your monetisation is advertising-only and you do not care about concurrent-stream caps, focus engineering on ad insertion, SSAI, and frequency capping, not MDM. The enforcement problem changes when the seat is free.

FAQ

Does “MDM” in OTT mean mobile device management, like Intune?

No. In OTT, MDM means Multi-Device Management — the backend that registers user devices, enforces concurrent-stream caps, and brokers DRM licenses across phones, tablets, TVs, and consoles. It has nothing to do with enterprise MDM products like Intune or Jamf.

Do we need Widevine, FairPlay, and PlayReady — or can we pick one?

If your catalogue includes premium studio content, you need all three. Widevine covers Android, Chrome, and most smart TVs; FairPlay covers the Apple ecosystem; PlayReady covers Windows, Xbox, Roku, and many TVs. With CMAF and cbcs you encode and store the content once and serve all three with different manifests.

What is a realistic budget for custom OTT development with a Netflix-style MDM?

An MVP with device registry, session manager, entitlement service, DRM broker, and web/iOS/Android apps typically lands in the $80K–$140K range over about four months. A full build with Smart TV apps, analytics, and account-sharing models usually adds $70K–$140K and three to four more months. Ongoing CDN and license costs dominate opex at scale.

How many concurrent streams should we allow per tier?

The industry default is 1/2/4 for Basic/Standard/Premium, though Netflix retired its Basic tier in 2024 and now runs 2 on Standard and 4 on Premium. Start near that and adjust after you see real utilisation. Over-provisioning hurts upsell; under-provisioning triggers cancel-and-resubscribe behaviour that damages LTV. Watch utilisation per tier for 90 days before moving the caps.

Can we add account-sharing enforcement after launch?

Yes, but it is far easier if the MDM already captures device fingerprints and IP+ASN per session. Retrofitting fingerprinting across live client apps is a release-train problem — your oldest client versions will not report the data. Capture from day one, enforce when you are ready.

What do we do when users legitimately travel abroad?

Do not hard-block. Follow Netflix’s pattern: soft-warn after an impossible-geo signal, require a one-time confirmation on a primary home device, and allow a rolling travel window. Log the IP trail so you can audit false positives — expect 0.5–2% of legitimate travelers to trigger the heuristic.

Should the MDM live in the same service as billing?

No. Keep them separate services with a clean contract. Billing owns subscription state; MDM owns device and session state; the entitlement service joins them. This separation pays off the first time you swap billing providers or enter a new market with different tier logic.

How does Fora Soft deliver OTT faster than most agencies?

Two reasons. First, we reuse a hardened device-registry, session-manager, and license-broker core from past OTT projects, so each engagement starts near the 30% milestone. Second, our teams apply Agent Engineering across design, code generation, test authoring, and QA, which compresses the build phase without cutting corners on architecture or compliance.

What to Read Next

Ready to build an OTT platform that scales?

A custom Multi-Device Management layer is not the flashy part of an OTT platform, but it is the layer that decides whether your pricing tiers hold, whether studios will license to you, and whether your CDN bill stays rational. The five-service reference architecture (device registry, session manager, entitlement, DRM broker, analytics) is the same pattern Netflix, Disney+, and HBO Max use. Your job is to implement it honestly and make it invisible to the user.

If you are below 100K subscribers, buy. If you are above 500K or heading there, build — and stage the build so you ship something playable in four months, not twelve. Multi-DRM via CMAF is solved; off-the-shelf license servers are cheap; the art is in the control plane. That is where we spend most of our time on OTT engagements.