Contact sales

Platform & architecture

Our own server.
Your devices. Clear lines.

AAMDM runs its own MDM server for company-owned Apple devices.
Here is how the pieces fit, and which phase each one belongs to.

AAMDM architectureAn administrator uses the admin console, which queues commands on the AAMDM MDM server. The server asks Apple Push Notification service to push to the device. The device checks in with the MDM server over HTTPS to collect commands and report status. Apple Business Manager provides a server token to the MDM server in Phase 2.Admin consoleYour IT teamPhase 1AAMDM MDM serverQueue · check-in · auditPhase 1Apple Push (APNs)Apple serviceAppleDeviceiPhone · iPad · MacPhase 1Apple Business ManagerCustomer-controlledPhase 2queue command1push request2wake-up push3check-in over HTTPScommands · status4server tokenautomated enrollment
  1. Admin consoleYour IT teamPhase 1
  2. Queues a command
  3. AAMDM MDM serverQueue · check-in · auditPhase 1
  4. Sends a push request (MDM push certificate)
  5. Apple Push (APNs)Apple serviceApple
  6. Delivers a wake-up push
  7. DeviceiPhone · iPad · MacPhase 1
  8. Checks in over HTTPS, collects commands, reports status
  9. Back to the MDM serverResult recorded in the audit logPhase 1
  10. Apple Business ManagerProvides a server token to the MDM server for automated enrollmentPhase 2
Simplified architecture · Phase 1 is in active development; Apple Business Manager is planned for Phase 2.

Components

What the platform
is made of.

Phase 1

Our own MDM server

AAMDM operates its own MDM server. It holds device records, the command queue and the check-in endpoint that devices talk to.

Phase 1

Push through APNs

Each customer has its own MDM push certificate. The server uses it to ask Apple Push Notification service to wake a device so it can check in.

Phase 1

Enrollment by configuration profile

A configuration profile points the device at the AAMDM server. Once enrolled, it appears in your workspace’s device inventory.

Phase 1

Command queue & check-in

Commands wait in a per-device queue. A push tells the device to check in, collect the next command and report the result.

Phase 1

Multi-tenant isolation

Each customer works in a separate workspace. Permissions decide who can view and manage the devices and settings inside it.

Phase 1

Encrypted secrets & credentials

Certificates, tokens and other service credentials are stored encrypted. Administrator sign-in uses two-factor authentication.

Phase 1

Audit trail

Administrative actions are recorded with an actor, a target and a time, so your team has a history it can review.

Phase 2

Automated Device Enrollment (ABM)

With an Apple Business Manager server token, company-owned devices can be assigned to AAMDM and enrolled during first setup.

Phase 3

Declarative Device Management

Declarations describe the desired state and the device reports its status back, for a clearer view of configuration and compliance.

Planned

API & webhooks

An API and webhooks for connecting AAMDM to your own systems are part of the platform design. Timing will be shared with early-access customers.

AAMDM is in early access. Phase 1 is in active development, and phases describe planned work, not committed release dates.

The path of a command

How a command
reaches a device.

  1. 1

    Admin queues a command

    An administrator picks a device and an action, such as lock. The server places it in that device’s queue.

  2. 2

    Server asks APNs to push

    Using the customer’s MDM push certificate, the server asks Apple Push Notification service to wake the device.

  3. 3

    Device checks in

    The device receives the push, connects to the AAMDM server over HTTPS and collects the next command.

  4. 4

    Device executes and reports

    The device carries out the command and reports its status. The result is recorded in the audit log.

Questions about the architecture?

Talk through your device and deployment needs with the team, or see the security page.

Read the setup guide ›Request early access