Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Microsoft Device Ecosystem Platform (MDEP) is an enterprise-grade device platform for building secure, manageable, and consistent devices across multiple product categories. It combines an Android Open Source Project foundation with platform capabilities for device trust, configuration, provisioning, management, servicing, diagnostics, and controlled partner integration. The platform includes built-in management and security capabilities, including Microsoft Intune and Microsoft Entra ID, intended to support enterprise device scenarios.
MDEP delivery is based on the Unified Component Model (UCM), which defines how platform capabilities are packaged, versioned, and consumed as modular components across device programs. UCM provides a consistent contract for dependency management, update cadence, and compatibility between Microsoft-delivered components and OEM integrations.
Figure 1: MDEP Platform Architecture
The architecture is organized as a layered system. Each layer has a defined responsibility and communicates through supported interfaces. This separation reduces dependencies between applications, privileged platform functionality, and hardware-specific implementations. It also allows individual parts of the platform to evolve while preserving expected behavior and compatibility.
Relevant Links
Hardware and trust foundation
The lowest layer contains the device hardware, system-on-chip firmware, boot components, and trusted execution capabilities. This layer establishes the foundation for device identity and integrity before the operating system and applications run.
Typical capabilities include:
- Hardware-backed key generation and protection
- Secure storage for credentials and other protected material
- Verified boot and measurement of boot components
- Device-state evidence used to evaluate integrity
- Trusted execution for security-sensitive operations
Device manufacturers provide the hardware-specific implementation and integrate it with the platform trust requirements. The platform consumes these capabilities through defined interfaces rather than depending directly on a particular chipset or firmware design.
Hardware abstraction and native integration
The hardware abstraction and native integration layer separates platform functionality from device-specific hardware implementations. It exposes consistent interfaces for security, display, camera, audio, input, connectivity, and other hardware capabilities.
The layer may provide:
- Device identity and attestation functions
- Security and cryptographic capabilities
- Display, camera, audio, and input integration
- Network and peripheral connectivity
- Hardware health and diagnostic signals
- Product-specific hardware features exposed through supported adaptation interfaces
This boundary allows higher platform layers to operate consistently across different hardware designs while preserving room for device differentiation. Native components and hardware abstraction layers expose device-specific functionality through defined interfaces rather than direct application-to-driver access.
Privileged platform functionality
Core system functionality runs with the privileges required to coordinate device-wide behavior and access protected platform resources. This functionality enforces platform policy, permission boundaries, and lifecycle rules on behalf of applications and system experiences.
Responsibilities include:
- Applying device configuration and administrative policy
- Coordinating setup and provisioning
- Establishing and maintaining trusted relationships between devices
- Synchronizing configuration and operational state
- Coordinating software and firmware updates
- Collecting diagnostic information and health signals
- Recovering critical device experiences after failures
- Migrating persistent data when platform schemas change
Applications do not directly implement these privileged operations. They request supported capabilities through platform contracts. Centralizing privileged behavior provides consistent security, policy enforcement, and lifecycle behavior across device categories.
Framework and application-facing capabilities
The framework layer exposes stable, high-level capabilities to system applications and approved partner applications. It validates access, routes requests to the appropriate privileged functionality, and returns results through supported interfaces.
Framework capabilities include:
- Device configuration and administration
- Network and connectivity management
- Setup and provisioning state
- Device association and secure communication (pairing)
- Cross-device synchronization
- Diagnostics and support-data collection
- Update initiation and status
- Accessibility and user-interface configuration
Applications depend on these contracts rather than on individual implementation components. The framework validates the caller identity and permissions, applies platform policy, and coordinates the required operation. This boundary allows underlying implementations to change without requiring applications to understand those changes.
System and product experiences
The experience layer contains user-facing applications supplied by Microsoft, device manufacturers, and solution providers. These experiences present platform capabilities to users and administrators while relying on lower layers for privileged operations.
Common experiences include:
- Initial device setup
- Local and remote configuration
- Restricted or dedicated application experiences
- Accessibility experiences
- Device enrollment and service selection
- Diagnostics and support workflows
- Administrative controls
Applications remain separated from privileged platform implementations. They request capabilities through supported contracts and operate within platform policy and permission boundaries.
Device setup and provisioning
MDEP provides a coordinated setup model for preparing a device for its intended use. The setup experience determines the required configuration, establishes necessary relationships, applies platform settings, and prepares the selected solution.
A setup flow can:
- Discover available device configurations
- Select a supported solution or device profile
- Enable the required software packages
- Apply permissions and platform policies
- Establish administrative and management context
- Complete setup across one or more related devices
Provisioning logic is separated from the user interface. This allows setup to be initiated from different platform experiences without duplicating lifecycle and policy logic.
Associated-device operation
For products composed of more than one device, MDEP can establish and maintain a trusted association between the devices. The association allows platform functionality to coordinate configuration and operational state across the product.
The platform can:
- Discover compatible devices
- Establish an authenticated and encrypted relationship
- Maintain the relationship when network addressing changes
- Provide secure communication channels
- Synchronize settings, setup state, and selected control operations
The association layer supplies secure transport, coordination, and lifecycle handling. Feature components remain responsible for the meaning, validation, and persistence of the data they exchange.
Configuration and policy
MDEP uses a centralized configuration model for user settings, administrator settings, device policy, and product-specific extensions. Applications and management components access configuration through supported platform contracts rather than writing protected state directly.
The configuration model can:
- Validate access based on caller identity and permissions
- Apply device-wide and user-level settings
- Enforce administrative restrictions
- Coordinate local and remote configuration
- Synchronize selected settings across related devices
- Preserve configuration across updates and migrate data when schemas change
This model provides a consistent policy boundary and allows manufacturers to add supported settings modules without changing the core configuration implementation.
Security and device trust
MDEP applies security across the architecture, from hardware-backed trust through privileged platform functionality, framework access controls, and managed application workflows. These layers establish device identity and integrity, protect sensitive operations, and enforce policy throughout the device lifecycle. For the security model, responsibility boundaries, and enforcement mechanisms, see Platform security.
Updates and lifecycle management
MDEP coordinates software and firmware updates across a device lifecycle. The architecture separates update policy and orchestration from the operating-system mechanisms that apply an update.
The update model can:
- Identify the device and its current software state
- Determine whether an update applies
- Authorize access to update content
- Download and validate update packages
- Coordinate installation with system update mechanisms
- Manage reboot and post-update processing
- Report progress and failure information
- Support staged deployment and rollback where applicable
- Provide an offline update path for disconnected devices
Manufacturers can integrate hardware-specific update handling through controlled extension points. Those implementations remain subject to platform policy, trust, and lifecycle boundaries.
Diagnostics, logging, and telemetry
MDEP separates diagnostic signal production from authorized collection and consumption across framework, system, application, and partner integration boundaries. Platform policy governs access, data minimization, storage, transmission, and retention. For diagnostic trail requirements, see Logging. For health signals, telemetry controls, and operational monitoring, see System health and telemetry.
Partner integration and differentiation
MDEP separates platform-owned behavior from partner-provided implementations through defined contracts and extension points. This model allows device manufacturers to integrate hardware-specific functionality and differentiate product experiences while preserving required platform security, manageability, compatibility, and lifecycle behavior. For partner responsibilities and supported customization boundaries, see Platform integration and customization.
The MDEP layered architecture provides a common foundation for enterprise devices without prescribing a single product implementation. Hardware-specific behavior remains in the lower layers, privileged platform functionality is protected behind controlled boundaries, applications consume stable high-level contracts, and partners extend the platform through defined integration points.
Together, these boundaries support device differentiation while preserving consistent expectations for security, management, provisioning, updates, diagnostics, compatibility, and lifecycle operation.