APNs (Apple Push Notification Service) is the backbone of every MDM operation on Apple devices. Without it, your MDM server can't talk to a single iPhone, iPad, or Mac. Every command you send, from deploying a Wi-Fi profile to triggering a remote wipe, starts with an APNs notification that wakes the device and tells it to check in with your server.
If you manage Apple devices at scale, understanding how APNs works isn't optional. It's the difference between an MDM that responds in seconds and one that silently fails because a certificate expired on a Friday afternoon.
How APNs Actually Works in MDM
The mechanics are simpler than most documentation makes them sound. Your MDM server doesn't push commands directly to devices. Instead, it sends a lightweight notification through Apple's APNs infrastructure, and the device responds by opening a secure connection back to your MDM server to fetch whatever's waiting.
Here's the flow:
- An admin triggers an action in the MDM console (install an app, push a config, lock a device).
- The MDM server sends a push notification to APNs using the device's unique push token.
- APNs delivers the notification to the device over a persistent TLS connection.
- The device wakes up, connects to the MDM server over HTTPS, and pulls the queued command.
- The device executes the command and reports the result back to the MDM server.
The push notification itself carries almost no data. It's essentially a "call home" signal. All the sensitive payload (profiles, commands, app manifests) travels over the direct device-to-server channel, encrypted end to end.
The APNs Certificate: Your MDM's Identity Card
Before any of this works, your MDM server needs a valid APNs certificate. This certificate proves to Apple that your server is authorized to send push notifications to your enrolled devices. No certificate, no communication.
Getting one takes a few steps:
- Your MDM platform generates a Certificate Signing Request (CSR).
- You upload that CSR to Apple's Push Certificates Portal using an Apple ID.
- Apple issues a signed certificate (.pem file) that you download.
- You upload the certificate back into your MDM platform.
With Appaloosa, this process is guided step by step in the admin console. You don't need to handle raw certificate files or wrestle with OpenSSL commands.
The Apple ID Trap
One detail catches many IT teams: the Apple ID you use to generate the certificate is permanently tied to it. You'll need that same Apple ID every year to renew. If an employee creates the certificate with their personal Apple ID and then leaves the company, you're locked out at renewal time.
Best practice: use a shared, organization-owned Apple ID (ideally a Managed Apple ID from Apple Business Manager). Document which Apple ID was used and store the credentials somewhere your team can access them.
Certificate Renewal: The Annual Deadline You Can't Miss
APNs certificates expire after exactly one year. When they do, your MDM loses all communication with every Apple device in your fleet. Not gradually. Instantly. Devices won't receive commands, won't get new profiles, won't check in. They keep running their last-known configuration, but you lose all control.
Renewal must happen with the same Apple ID, on the same certificate entry in Apple's portal. If you accidentally create a new certificate instead of renewing the existing one, you'll need to re-enroll every device because the push tokens are tied to the original certificate.
Set a calendar reminder at least 30 days before expiration. Most MDM platforms, including Appaloosa, display the certificate expiry date prominently in the admin dashboard and send email alerts as the deadline approaches.
Network Requirements
APNs needs specific network ports open, both on your devices and on your MDM server. If your organization uses strict firewalls or web proxies, this is where things can break.
Managed devices need outbound access to:
- TCP port 5223 to Apple's APNs servers (primary channel)
- TCP port 443 as a fallback if 5223 is blocked
Your MDM server needs outbound access to:
- TCP port 443 or 2197 to send notifications to APNs (api.push.apple.com)
Apple uses the entire 17.0.0.0/8 IP range for APNs, so you can't whitelist individual IPs. You'll need to allow the full range or, better, use domain-based rules for *.push.apple.com.
Devices behind captive portals or aggressive content filters often fail silently. The device appears enrolled but never receives commands. If you're troubleshooting an unresponsive device, network connectivity to APNs is the first thing to verify.
What Changed in 2025: New Certificate Authority
In February 2025, Apple migrated APNs server certificates from its legacy root to a new certificate authority (USERTrust RSA Certification Authority, SHA-2 root). If your MDM server or any middleware component pins or manually validates APNs server certificates, the trust store needs to include the new root.
Most cloud-based MDM platforms (Appaloosa included) handled this automatically. But on-premise deployments or custom integrations that hardcoded certificate expectations had to update their trust anchors before the cutover date. If your APNs connection dropped in early 2025 and you're still investigating, this is likely the cause.
Common APNs Issues and How to Fix Them
Devices not receiving commands
Check that port 5223 (or 443) is open from the device's network. Try with the device on cellular data to rule out firewall issues. Verify the APNs certificate hasn't expired in your MDM console.
Certificate renewal fails
You're probably using a different Apple ID than the one that created the original certificate. Log in to identity.apple.com/pushcert with the correct Apple ID and renew (not replace) the existing certificate.
Devices need re-enrollment after certificate change
This happens when a new certificate was created instead of renewing the existing one. The push tokens from enrollment are bound to the original certificate. The only fix is re-enrollment, which is why getting renewal right matters so much.
Intermittent connectivity
Often caused by proxies that intercept TLS. APNs uses certificate pinning, so MITM proxies break the connection. Add *.push.apple.com to your proxy's bypass list.
APNs and Zero-Touch Enrollment
APNs is especially critical if you use Zero-Touch Enrollment (Apple's Automated Device Enrollment through Apple Business Manager). When a new device powers on for the first time and contacts Apple's activation servers, the enrollment profile it receives includes your MDM server's APNs topic. From that first moment, the device-to-MDM communication channel depends on a working APNs certificate.
For organizations deploying hundreds of devices at once (a school distributing iPads, a retailer equipping store associates), an APNs issue during a rollout means every device stalls at setup. Test your APNs connectivity before any bulk deployment.
Setting Up APNs with Appaloosa
Appaloosa simplifies the APNs setup to three steps:
- Download the CSR from your Appaloosa admin console.
- Upload it to Apple's Push Certificates Portal and download the signed certificate.
- Upload the certificate back into Appaloosa.
The dashboard shows your certificate's expiry date, and you'll receive automatic renewal reminders starting 30 days before expiration. If you manage both iOS and macOS devices, one APNs certificate covers all Apple platforms.
For a broader look at managing Apple devices in an enterprise context, see our guide on Apple Mobile Device Management.