Two EU regulations took effect within months of each other. NIS2 hit in October 2024, DORA in January 2025. Both push organizations to tighten cybersecurity, report incidents faster, and prove they've done their homework on risk management. And both have a blind spot that most compliance teams discover too late: mobile devices.
Your employees check corporate email on their iPhones. Field technicians run diagnostic apps on Android tablets. Executives approve contracts from airport lounges. Every one of those interactions falls under NIS2 or DORA scope if your organization qualifies. This article covers what both regulations require, where mobile device management fits, and what you can do right now to close the gaps.
NIS2 in 90 Seconds
The Network and Information Security Directive 2 (NIS2) replaces the original NIS Directive from 2016. It covers two categories of organizations: essential entities (energy, transport, banking, health, water, digital infrastructure) and important entities (postal services, waste management, food production, manufacturing, digital providers). If you have 50+ employees or over EUR 10 million in revenue and operate in one of these sectors within the EU, NIS2 applies to you.
The requirements break down into four buckets:
- Risk management measures. Identify, assess, and mitigate cyber risks across all IT systems. That includes mobile endpoints.
- Incident reporting. Notify your national CSIRT within 24 hours of a significant incident. A full report is due within 72 hours.
- Supply chain security. Vet your suppliers' cybersecurity posture. Your MDM vendor counts.
- Governance. Management bodies are personally liable for ensuring compliance. C-level execs can face sanctions.
Penalties go up to EUR 10 million or 2% of global annual turnover for essential entities. That's GDPR-level enforcement applied to cybersecurity.
DORA in 90 Seconds
The Digital Operational Resilience Act targets the financial sector specifically: banks, insurance companies, investment firms, payment providers, and the ICT third parties that serve them. If NIS2 is the broad regulation, DORA is the scalpel for finance.
DORA's five pillars:
- ICT risk management. Maintain a framework that covers identification, protection, detection, response, and recovery. Every ICT asset, including mobile devices, must be inventoried and risk-assessed.
- ICT incident reporting. Classify incidents by severity and report major ones to your competent authority.
- Digital operational resilience testing. Regular testing including threat-led penetration testing (TLPT) for large institutions.
- ICT third-party risk management. Register all ICT service providers. Critical third parties face direct EU oversight.
- Information sharing. Voluntary exchange of cyber threat intelligence between financial entities.
DORA doesn't set fines in the regulation itself, but national authorities determine penalties. Early guidance suggests they'll match the gravity, which for banks means seven-figure numbers are realistic.
Where Mobile Devices Create Compliance Gaps
Most NIS2 and DORA compliance programs focus on servers, networks, and laptops. Mobile devices get treated as an afterthought. That's a mistake.
A single unmanaged iPhone with corporate email access can violate multiple NIS2 requirements at once. No enforced screen lock? Risk management failure. Employee loses the phone and you don't know for two weeks? Incident reporting blown. The phone runs iOS 15 with known vulnerabilities? Patch management gap.
DORA is even more specific. Article 9 requires financial entities to "identify all sources of ICT risk" and maintain an updated inventory of ICT assets. If your bank's relationship managers use personal phones to access the CRM (and they do), those devices need to be inventoried and controlled.
The blind spots typically fall into five areas:
Device inventory. You can't protect what you can't see. Many organizations have no idea how many mobile devices access corporate resources.
Encryption verification. Both regulations require data-at-rest encryption. MDM can verify it's active; hope and policy documents cannot.
Access control. Who can access what data from which device? Without MDM, you're relying on username/password alone.
Incident response for mobile. Can you remotely wipe a lost device within the 24-hour NIS2 reporting window? Without MDM, probably not.
Audit trail. Regulators want evidence. MDM logs every policy push, compliance check, and enforcement action.
How MDM Addresses NIS2 Requirements
Here's how specific MDM capabilities map to NIS2's risk management measures (Article 21):
Encryption enforcement (Art. 21.2.d). MDM verifies that every enrolled device has encryption active. Devices that fail the check get blocked from corporate resources automatically. No manual auditing needed.
Access control and authentication (Art. 21.2.i). Enforce minimum passcode complexity, biometric authentication, and multi-factor access to work apps. MDM can require a separate passcode for the work container on BYOD devices.
Vulnerability handling (Art. 21.2.e). Push OS update policies to enforce minimum software versions. Block devices running outdated firmware from connecting to your network.
Incident handling (Art. 21.2.b). Remote lock and wipe within minutes of a reported loss. MDM logs provide the timeline regulators need for incident reports.
Supply chain security (Art. 21.2.d). Control which apps can be installed. Block sideloading. Distribute approved apps through a managed app catalog instead of letting employees download from unknown sources.
How MDM Addresses DORA Requirements
DORA's ICT risk management framework (Chapter II) maps to MDM as follows:
ICT asset inventory (Art. 8). MDM automatically maintains a live inventory of every enrolled device: model, OS version, last check-in, installed apps, compliance status. This is the single source of truth auditors look for.
Protection and prevention (Art. 9). Enforce encryption, VPN, and network security policies. Block jailbroken or rooted devices. Restrict USB debugging and file transfer on Android.
Detection (Art. 10). Compliance monitoring flags devices that fall out of policy. A phone that hasn't checked in for 30 days, a device with a revoked certificate, an employee who disabled their screen lock: MDM catches all of these.
Response and recovery (Art. 11). Remote wipe, remote lock, and Return to Service (on iOS 17+) give you response options that don't require physical access to the device.
Testing (Art. 24-27). MDM policies can be tested on a pilot group before fleet-wide rollout. You can simulate a lost-device scenario and verify your response time meets DORA's expectations.
A Practical Compliance Checklist
If you're starting from zero, here's a priority order that covers both NIS2 and DORA mobile requirements:
Week 1: Inventory and enrollment. Deploy MDM to all corporate devices. Use zero-touch enrollment for new devices and profile-based enrollment for existing ones. Get BYOD users enrolled with User Enrollment (iOS) or Work Profile (Android).
Week 2: Baseline security policies. Enforce encryption, minimum OS version, screen lock, and disable USB debugging. Block non-compliant devices from email and VPN.
Week 3: App management. Approve and distribute corporate apps through Managed Google Play and Apple Business Manager. Block sideloading on Android. Configure managed app settings (VPN per app, SSO tokens).
Week 4: Incident response testing. Run a tabletop exercise. "An executive lost their phone at a conference. Walk me through the next 60 minutes." Verify remote wipe works, verify the audit log captures the timeline, verify you can produce a report within 24 hours.
Ongoing: Compliance monitoring. Review MDM compliance dashboards weekly. Flag devices that haven't checked in. Audit app installation reports. Update policies when new OS versions ship.
What Appaloosa Brings to the Table
Appaloosa is a cross-platform MDM that manages iOS, Android, and macOS devices from a single console. For NIS2 and DORA compliance specifically, a few things matter:
EU hosting. Appaloosa runs on EU infrastructure. Your device management data stays in the EU, which simplifies data residency questions under both regulations.
Granular compliance policies. Set different policies per device group: stricter controls for executives handling sensitive data, lighter policies for shared retail devices. Compliance exceptions are logged for audit purposes.
Audit-ready reporting. Export device inventory, compliance history, and incident response logs in formats that auditors expect. When a regulator asks "show me your mobile device controls," you hand them a report, not a spreadsheet someone compiled last quarter.
See how Appaloosa handles MDM or explore remote support capabilities for incident response scenarios.