# eUICC security domains — ISD-R, ISD-P, MNO-SD, ECASD

> Inside an eUICC, every cryptographic key and every profile is isolated inside a Security Domain — a logical container with its own keys, its own access rules, and its own privileges. The four domains that matter for eSIM Remote SIM Provisioning are ISD-R (the boss), ISD-P (per-profile), MNO-SD (operator OTA), and ECASD (the certificate root). Understanding them is the difference between debugging an eSIM failure in an hour and debugging it in a week.

- Canonical URL: https://www.broadnet.me/answers/euicc-security-domains
- Language: en
- Last reviewed: 2026-05-28
- Publisher: BroadNet (https://www.broadnet.me)

## What each domain does

ISD-R (Issuer Security Domain — Root) is the master controller. It is created at eUICC manufacture by the EUM (eUICC Manufacturer), holds the keys used to install and manage profiles, and is the only entity that can create or delete ISD-Ps. ISD-P (Issuer Security Domain — Profile) is the per-operator container; one ISD-P per installed profile, isolated by domain keys derived during profile download. MNO-SD (Mobile Network Operator Security Domain) lives inside each ISD-P and holds the operator's OTA (over-the-air) keys for post-install profile updates — file system changes, applet pushes, parameter tweaks via SCP80/SCP81. ECASD (Embedded UICC Controlling Authority Security Domain) holds the GSMA Certificate Issuer (CI) root certificates that anchor every signature check the eUICC performs.

## Why it matters commercially

Domain ownership maps directly to commercial responsibility. The EUM owns ISD-R (and therefore controls which SM-DP+ servers can talk to the device unless authorised). The operator owns MNO-SD inside its own ISD-P. GSMA owns ECASD through the CI certificate chain. When something goes wrong — a profile won't install, an OTA push fails, a certificate expires — knowing which domain owns the failure tells you which party to escalate to. Get this wrong and you spend three weeks blaming the operator for an EUM issue.

## Operational angle

Most production eSIM failures trace to one of four patterns: (a) ISD-R key set out-of-date because the EUM rotated and didn't sync to the SM-DP+; (b) ISD-P creation failing due to memory pressure on a chip with too many profiles; (c) MNO-SD OTA push rejected because the operator changed the OTA keyset without informing the SM-SR; (d) ECASD certificate chain check failing because an intermediate CI certificate expired. BroadNet's eSIM VSM platform monitors all four classes and alerts operators ahead of expiry/sync issues.

## Privacy and compliance considerations

Security-domain keys are the crown jewels of the eSIM ecosystem. Their custody, rotation, and ceremony are exactly what GSMA SAS-SM (/answers/sas-sm-certification) audits. Customer data inside an ISD-P (IMSI, MSISDN, file system contents) is encrypted at rest inside the secure element and never leaves except as authenticated signalling. For PDPL/GDPR scope, the domain isolation itself is a technical guarantee that one operator's customer data is not visible to another operator on the same chip.

## Related

- [All answers](https://www.broadnet.me/answers)
- [Glossary](https://www.broadnet.me/answers)
- [eUICC — the embedded UICC chip explained](https://www.broadnet.me/answers/what-is-euicc)
- [SM-DP+ — Subscription Manager Data Preparation, explained](https://www.broadnet.me/answers/sm-dp-plus)
- [SAS-SM certification — what it means for SIM and eSIM trust](https://www.broadnet.me/answers/sas-sm-certification)
- [Milenage algorithm — 3GPP authentication explained](https://www.broadnet.me/answers/milenage-algorithm)
- [eSIM VSM platform](https://www.broadnet.me/operators/esim-vsm)
- [Trust Center](https://www.broadnet.me/trust)