Skip navigation
Duo Labs

Weak Apple DEP Authentication Leaves Enterprises Vulnerable to Social Engineering Attacks and Rogue Devices

Over the last few months, Duo Labs has been researching the security of Apple's Device Enrollment Program (DEP). In this research, we discovered an authentication weakness in DEP, used by many organizations to automatically enroll devices in their Mobile Device Management (MDM) server. Simply put, enterprises use DEP to bootstrap the provisioning of Apple devices.

This has a few real-world implications:

  • Leveraging this authentication weakness, an attacker can potentially enroll any device into an organization's MDM server - which could allow them to obtain privileged access used to further pivot within the network. Whether the attacker will be able to automatically enroll their device into the MDM server depends on how the server is configured, and whether the device was previously enrolled. Since the MDM protocol doesn't require user authentication, not every organization has implemented this protection, even though Apple publicly documents these best practices in their Apple Business Manager Help documentation.
  • Or, an attacker could use serial numbers obtained through open-source intelligence (OSINT), social engineering or generating them via brute force to query the DEP API for device profiles. The DEP profiles contain information about the organization, such as phone numbers and email addresses, which could be used to launch a social engineering attack against the organization's help desk or IT team.

See the full report for an in-depth, technical overview of our findings.

Device Enrollment Program

DEP is a free service offered by Apple for organizations using MDM to manage and configure their users' devices, including devices purchased directly from Apple or authorized resellers. DEP gives users a zero-touch setup experience of their new company-provided devices.

Authentication Weaknesses in DEP

Our research focused on the details of how some of the undocumented DEP APIs work, specifically those that are used by Apple devices to communicate and enroll with the DEP service. Through this research, we found that because of the way DEP is implemented, it only uses a device's serial number to authenticate to the service prior to enrollment. Also, while Apple’s MDM protocol supports user authentication prior to MDM enrollment, it does not require it - meaning some organizations could be protecting device enrollment with the serial number alone.

The key issue is that serial numbers are used to authenticate devices to the DEP service, but are not data that should be considered secret. Additionally, because not everyone expends the effort to protect serial numbers, it's not uncommon to find them online.

Furthermore, serial numbers are predictable and are constructed using a well-known schema. This means that an attacker does not have to find serial numbers that have been inadvertently leaked; they can instead generate valid serial numbers and use the DEP API to test if they are registered with DEP.

With this in mind, an attacker armed with only a valid DEP-registered serial number can use it to query the DEP API to glean organizational information. Or, in configurations where an associated MDM server does not enforce additional authentication, a malicious actor can potentially enroll an arbitrary device into an organization’s MDM server. The ability to enroll a chosen device to an organization’s MDM server can have a significant consequence, subsequently allowing access to the private resources of an organization, or even full VPN access to internal systems.

Who Does This Affect?

It's impossible for us to know the full size or scope of devices that this DEP issue impacts, but every customer using Apple's DEP service is affected. However, it's worth remembering, not every Apple enterprise customer that deploys Apple devices in their corporate IT environment uses Apple’s DEP service.

Disclosure Timeline

Below is a summary of the timeline starting with when we discovered the authentication weakness in DEP and leading up to this research being published:

  • 2018-05-16: Initial report to Apple.
  • 2018-05-17: Acknowledgement from Apple.
  • 2018-08-16: 90 days since first report.
  • 2018-09-27: Research published.
  • 2018-09-28: Public Disclosure at ekoparty Security Conference.


So what can be done to protect both the organizations using DEP and their users? The full security research provides several remediation options, covering steps that both Apple and organizations using DEP can take.

Our recommendations to Apple center on ensuring strong authentication of devices and not relying on serial numbers as a sole authentication factor to retrieve the DEP profile. Until the core issue is resolved, Apple can help make their DEP APIs more resilient to misuse by implementing rate limits on requests and limiting the information returned by the API endpoints. Additionally, Apple could strongly authenticate users as part of the DEP enrollment process, using modern authentication protocols such as SAML or OIDC. This would prevent DEP profiles from being retrieved if the device’s associated user is not authenticated.

If your organization uses DEP, one of the best steps you can take is to ensure you enforce authentication on any MDM server used with DEP, so that knowledge of a serial number alone does not allow device enrollment. Additionally, embracing a zero-trust approach can help to ensure that the privileges afforded to devices that have been enrolled in MDM are not excessive. Put another way, just because a device is managed by your MDM server should not automatically afford it a higher degree of trust.


Regardless of the authentication weaknesses in the current implementation of Apple's Device Enrollment Program, there's no question that it still provides value for organizations with large fleets of Apple devices. The benefits of ensuring that devices are securely configured and managed via MDM and bootstrapping that process via DEP outweigh the risks associated with this authentication weakness.

There are a number of steps that can be taken by Apple to establish strong authentication and trust while still ensuring a relatively frictionless, streamlined user experience and device deployment process. However, some of these mitigations (such as device attestation) only recently became feasible due to new hardware capabilities. It will take time for these changes to be fully realized, and for Apple's customers that are leveraging DEP to benefit from them, but the future looks bright.

In the meantime, Apple customers using DEP can protect themselves by requiring user authentication prior to MDM enrollment, or by not trusting devices simply because they're enrolled in MDM.