MOBILECONFIG File Documentation

Summary

A .mobileconfig file is an Apple configuration profile: an XML property list (plist) that configures an iPhone, iPad or Mac in one step, setting up Wi‑Fi, VPN, email accounts, certificates, restrictions or MDM enrollment. You install it by opening it on the Apple device (Settings › General › VPN & Device Management on iOS). Its MIME type is application/x-apple-aspen-config. Only install profiles from a source you trust, because they can take broad control of the device.

Technical details

Feature	Value
Full name	Apple Configuration Profile
File extension	`.mobileconfig`
MIME type	`application/x-apple-aspen-config`
Format type	XML property list (plist); optionally CMS-signed or encrypted
Developer	Apple
Category	System / configuration file
Introduced	2010 (iPhone Configuration Utility, iPhone OS)
Applies to	iOS, iPadOS, macOS, tvOS, watchOS
Base format	Apple plist (XML, `-//Apple//DTD PLIST 1.0//EN`)
Signed / encrypted form	Binary CMS (PKCS #7) container per RFC 5652
Root element	`<plist><dict>` with a `PayloadContent` array
Open standard	No — proprietary Apple schema (payload keys documented)
Encoding	UTF‑8 text (unsigned); binary for signed/encrypted
Authoring tools	Apple Configurator 2, iMazing Profile Editor
Install path (iOS)	Settings › General › VPN & Device Management
Install path (macOS)	System Settings › Privacy & Security › Profiles
Related extensions	`.plist`, `.xml`, `.p12`, `.cer`, `.mobileprovision`
Specification	`developer.apple.com/documentation/devicemanagement`

Structure at a glance

An unsigned profile is plain XML: it opens with <?xml version="1.0" ...?>, then <!DOCTYPE plist ...> and a <plist><dict> root. The root dictionary holds a PayloadContent array, where each entry is one payload (Wi‑Fi, VPN, certificate, restriction, MDM ...) with its own PayloadType and PayloadIdentifier. A signed or encrypted profile is instead a binary CMS/PKCS #7 blob with no readable XML — that is normal and means the issuer signed it, which is why the OS can show a green “Verified” badge. There is no fixed magic number; identify the file by the leading <?xml and <plist text, or by opening it in a profile editor.

What is a mobileconfig file?

A .mobileconfig file is an Apple configuration profile: the standard mechanism Apple uses to push settings onto an iPhone, iPad, Mac, Apple TV or Apple Watch. Apple introduced the format in 2010 alongside the iPhone Configuration Utility, and it is now the shared profile format across iOS, iPadOS, macOS, tvOS and watchOS. Technically it is an XML property list whose root dictionary carries an array of payloads, each of which configures one subsystem of the device. Its MIME type, application/x-apple-aspen-config, is what tells Safari and Mail to hand the download to the profile installer rather than saving it as a document.

A profile does not contain an app or a document. It contains declarative settings: a Wi‑Fi network and its password, a VPN configuration, an Exchange or IMAP account, a passcode policy, a root certificate, a Safari content filter, or an MDM enrollment record that hands ongoing management of the device to an organisation’s server. Because those payloads can reach so deep into the device, the format is best understood as a small, signed policy document that the operating system applies with the user’s consent.

The plist container and the payload dictionary

An unsigned profile is an ordinary Apple XML plist. It begins with the XML declaration, then the plist DOCTYPE (-//Apple//DTD PLIST 1.0//EN), then a single <plist version="1.0"> element containing one <dict>. plist stores typed values using paired tags: <string>, <integer>, <true/> / <false/>, <data> (Base64), <date>, <array> and nested <dict>. A configuration profile is just a plist that follows Apple’s profile schema on top of those primitives.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "...">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict> ... one payload ... </dict>
  </array>
  <key>PayloadDisplayName</key>   <string>Corp Wi-Fi</string>
  <key>PayloadIdentifier</key>    <string>com.example.wifi</string>
  <key>PayloadType</key>          <string>Configuration</string>
  <key>PayloadUUID</key>          <string>A1B2C3D4-...</string>
  <key>PayloadVersion</key>       <integer>1</integer>
</dict>
</plist>

The outermost dictionary is itself a payload of PayloadType Configuration: it is the profile as a whole. Its important keys are PayloadDisplayName and PayloadDescription (the human text the install screen shows), PayloadIdentifier (a reverse‑DNS string that uniquely names the profile so a later profile with the same identifier replaces it), PayloadUUID (a GUID), PayloadOrganization (who issued it, also shown at install), and PayloadVersion. Nested inside is PayloadContent, the array of the individual payloads described below.

PayloadContent: how one payload configures one subsystem

Every element of the PayloadContent array is a dictionary that shares five common keys and then adds keys specific to its type. The common keys mirror the top level: PayloadType names the subsystem, PayloadIdentifier and PayloadUUID give it identity, PayloadDisplayName labels it, and PayloadVersion versions it. The PayloadType string is the switch that tells the OS which manager consumes the rest of the dictionary.

`PayloadType`	What it configures
`com.apple.wifi.managed`	A Wi‑Fi network: SSID, security type, password, hidden flag
`com.apple.vpn.managed`	A VPN connection and its authentication
`com.apple.security.root` / `...pkcs1` / `...pkcs12`	A certificate or root CA (the PKCS #12 form carries a private key)
`com.apple.applicationaccess`	Restrictions (disable camera, app installs, etc.)
`com.apple.webcontent-filter`	A Safari / system web-content filter or DNS proxy
`com.apple.mdm`	MDM enrollment: hands ongoing management to a server

A certificate payload stores the certificate itself in a PayloadContent <data> element as Base64 DER. This is the mechanism behind the most serious abuse case: a root-certificate payload adds a certificate to the device trust store, and once trusted, that authority can issue certificates for any site, enabling interception of otherwise encrypted traffic. The MDM payload is the other high-trust one; installing it enrolls the device into a management server that can subsequently install apps, apply further profiles, and, depending on enrollment type, remotely wipe the device.

Signing and encryption: the CMS wrapper

A profile can be delivered plain, signed, or signed-and-encrypted. When it is signed, the XML plist is no longer at the top of the file: the whole plist is wrapped in a Cryptographic Message Syntax (CMS / PKCS #7) container defined by RFC 5652, and the file becomes a binary blob. That is why a signed .mobileconfig opened in a text editor looks like garbage rather than readable XML. The signature lets the OS verify the issuer and display a green “Verified” label with the signer’s name on the install screen; an unsigned profile instead shows “Unsigned” or “Not Verified” in red.

Encryption goes a step further: the payloads (or specific values such as a Wi‑Fi password) are encrypted to the target device’s certificate so that only the intended device can read them. To inspect a signed profile you unwrap the CMS layer first (verify and strip the signature), which exposes the same plist described above. Apple Configurator 2 and the iMazing Profile Editor do this for you and present the decoded payloads.

How a device installs a profile

Installation is deliberately explicit and consent-driven. A profile arrives as a Mail attachment, a web download, or a push from an MDM server. On iOS and iPadOS the download does not apply anything by itself; the profile sits pending until the user opens Settings › General › VPN & Device Management, taps the downloaded profile, and confirms Install. The install screen renders PayloadDisplayName, PayloadOrganization, the signature status, and a summary of what each payload will do, so the user sees, for example, that the profile adds a certificate and a VPN before agreeing. On macOS the file is double-clicked and then approved in System Settings › Privacy & Security › Profiles. Removing a profile happens on the same screen, and removing it cleanly reverses every setting it applied, because the OS tracks which settings each profile owns by its PayloadIdentifier.

Security: why a profile is a real attack vector

The same power that makes profiles useful for IT makes a malicious one dangerous, so the risk here is genuinely high and worth stating in technical terms. A hostile .mobileconfig can do several concrete things once installed. A root-certificate payload inserts a CA into the trust store, after which a man‑in‑the‑middle proxy holding that CA’s key can decrypt HTTPS traffic without a browser warning. A web-content-filter or DNS payload can silently redirect or proxy all name resolution and web requests. An MDM enrollment payload can hand the device to an attacker’s management server that then installs apps, pushes further profiles, tracks location, and issues a remote wipe. These are the reasons “free internet”, “free VPN”, game-hack and jailbreak sites so often try to talk a user into installing a profile.

The defences are procedural because the OS cannot judge intent. Only install a profile from a source you genuinely trust, such as a real employer, school or carrier. Read the payload summary and issuer on the install screen before tapping Install, and treat an Unsigned profile that requests certificate or MDM payloads with particular suspicion. To audit a device, open Settings › General › VPN & Device Management on iOS or System Settings › Profiles on macOS: a device with nothing installed shows no such entry at all, so any profile you do not recognise should be removed.

Creating and reading a profile

Apple retired the old iPhone Configuration Utility, so it is not the tool to look for. The current authoring apps are Apple Configurator 2 (free, macOS only) and the cross-platform iMazing Profile Editor (free, macOS and Windows), both of which expose every payload key with a form UI and validate the result. Because an unsigned profile is an XML plist, you can also read one in any text editor, or on macOS inspect and re-serialise it with plutil. Windows cannot apply a profile — only an Apple device can — but it can read and build one with the iMazing editor. A signed profile must be unwrapped from its CMS container before the XML is visible, which is again what the dedicated editors handle.

Frequently asked questions

Why does my .mobileconfig look like binary garbage instead of XML?

It is signed or encrypted, so the plist is wrapped in a binary CMS/PKCS #7 container rather than stored as plain XML. That is normal and means the issuer signed it (which is what lets the OS show a “Verified” badge). Open it in Apple Configurator 2 or the iMazing Profile Editor to view the decoded payloads.

What is the difference between a profile and MDM?

A .mobileconfig is a static settings file. MDM is an ongoing management protocol between the device and a server. You cannot convert one into the other, but a profile can contain an MDM-enrollment payload (com.apple.mdm) that enrolls the device into an MDM server, after which the server manages the device dynamically.

Why does installing a new profile sometimes replace an old one?

Profiles are keyed by their PayloadIdentifier. If a new profile carries the same identifier as one already installed, the OS treats it as an update and replaces the old profile rather than adding a second copy, which is how administrators push revised settings.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents