An Ivanti Endpoint Manager Mobile (EPMM, formerly MobileIron Core) server holds the trust relationship with every enrolled phone and tablet, so whoever controls its portals can push profiles, apps and wipe commands to the whole fleet. This guide covers the customer-side settings that decide how well an on-premises EPMM deployment resists misuse: how administrators and API clients authenticate, how device spaces and roles limit administrators, the service credentials EPMM holds, what to log and forward, and a hardening baseline built from Ivanti's documentation. It is written for mobility, identity and security operations teams who run EPMM. The general case for treating mobile device management as a tier 0 system, enrolment design and compliance signals is covered in the Mobile Device Management Security Guide, and periodic review in the MDM and UEM platform health check; this page goes deeper on EPMM settings and does not repeat them.
This is an independent guide from NHI Mgmt Group, based on Ivanti's public documentation as of November 2026. It is not sponsored or reviewed by Ivanti. Product features change, so confirm settings against Ivanti's current documentation.
Key takeaways
- Restrict who can reach each portal. System Manager Portal ACLs can limit the Admin Portal, System Manager, API Connection and OAuth API to named networks, separately from the device-facing services that must stay reachable.
- Keep port 8443 internal. Ivanti describes the System Manager port as needing "strictly controlled access", limited to Ivanti applications from the corporate network.
- Move admin sign-in to SAML or certificates. Password authentication is the default for the Admin Portal; Security > Advanced offers certificate authentication or SAML to an external identity provider where MFA can be enforced.
- Treat API users as privileged service accounts. The V1 API authenticates with the username and password of any local or LDAP user holding the API role, so give those accounts their own identity, a network ACL and monitoring.
- Send audit data off the box. Syslog facility local7 carries the audit data shown under Logs > Audit Logs, and local6 carries device and Admin Portal access, so forward both over TLS.
How identity and access work in Ivanti EPMM
An on-premises EPMM deployment has several administrative and service surfaces, each with its own identity path. Ivanti lists the components as the Admin Portal, System Manager, Enterprise Connector, a CLI and the APIs (V1, V2 and the Event Notification Service and Common Platform Services APIs).
| Surface | Who or what uses it | How it authenticates | Exposure guidance |
|---|---|---|---|
| Admin Portal | Administrators managing users, devices, apps, policies and labels | Password (default), certificate authentication, or SAML to an external IdP | Internal networks only, through a Portal ACL |
| System Manager | Platform administrators: network settings, certificates, upgrades, logs | Local System Manager users with their own password policy; SSH can use public key authentication | Port 8443 with strictly controlled access |
| Self-Service User Portal | Device users registering and managing their devices | Password, certificate (optionally Derived Mobile Smart Credential) or SAML | Restrict with a Portal ACL where users are on known networks |
| APIs | Integrations, scripts and partner products | V1: local or LDAP user with the API or Mobile App role; OAuth API restrictable by IP | API Connection and OAuth API Portal ACLs |
| Enterprise Connector | EPMM reaching Active Directory or LDAP | Directory bind account over HTTPS connections between Connector and EPMM | Internal; multiple Connectors for redundancy |
| Devices | Mobile@Work, MDM profiles, Apps@Work | Device certificates; mutual authentication when enabled | Must be reachable by devices, typically on 443 |
The ports involved matter for firewall rules and ACLs. From Ivanti's Port Settings reference: Sync TLS 9997 (device check-in without mutual authentication), MIFS Admin 443 (can be changed to 8443), Sentry Service 8443 (Standalone Sentry fetching device information), Apps@Work 443 (7443 recommended if changed), CRL 8080 over HTTP, Sync service 9999 and Provisioning 443.
Mutual authentication: with mutual authentication, a registered device can keep talking to EPMM only if it presents the right certificate, and Ivanti "strongly recommends" enabling it. It is set in the Admin Portal at Settings > System Settings > Security > Certificate Authentication, is on by default for new installations, and is kept at its previous state on upgrade. Ivanti notes that once enabled it cannot be disabled, that the EPMM identity certificate must be publicly trusted, and that once all devices use it, port 9997 can be disabled. See the mTLS Guide.
Admin roles and privileged access
EPMM delegates administration through device spaces. Global administrators are assigned to the global space, manage devices across the whole system and can be given any role. Device space administrators manage only the users and devices in their assigned spaces, can only message devices and apps in those spaces, and have a restricted set of roles. Roles are assigned at Admin > Admins > Actions > Edit Roles by an administrator holding the "Manage administrators and device spaces" role.
| Job function | Space | Role approach | Notes |
|---|---|---|---|
| Platform owners (two or three named people) | Global | Full roles including Manage administrators and device spaces | Separate admin accounts from daily accounts; certificate or SAML sign-in |
| Regional or business unit help desk | Device space per region or unit | Device management and user lookup only | Ivanti's own example is a Dallas help desk space limited to its devices |
| Policy and app engineers | Global | Policy, configuration, app and label roles; no admin management | Changes to policies and labels appear in audit logs by administrator |
| Integrations and scripts | Global or a scoped space | API role only, under Others | One account per integration; no Admin Portal use |
| Platform operations | System Manager local users | System Manager access only | Kept separate from Admin Portal roles; SSH by public key |
Privileged access practices for EPMM:
- Separate the two consoles: Admin Portal roles do not govern System Manager, which has its own local users at Security > Identity Source > Local Users and its own Password Policy. Review both user lists.
- Strong admin sign-in: configure Security > Advanced > Portal Authentication for certificate authentication on the Admin Portal, or Security > Advanced > SAML to redirect local administrator sign-in to your identity provider and enforce phishing-resistant MFA there. Ivanti notes the password and certificate options on that screen are not used once SAML is enabled. See the SAML Security Guide and the Phishing-Resistant MFA Guide.
- Break-glass: keep one local administrator outside SAML for IdP outages, with a long random password in a vault and alerting on its use. See the Break-Glass Account Guide.
- High-impact actions: wipe, retire, policy and label changes affect many devices at once. Limit those roles to platform owners and review the audit log for them weekly.
- Admin devices: reach the portals only from hardened admin workstations. See the Privileged Access Workstations Guide.
Integrations, API tokens and service accounts
EPMM stores and accepts several machine credentials. Because the V1 API uses the same username and password as the Admin Portal, an API account is functionally an administrator account and should be handled as a privileged non-human identity. See the Service Account Security Guide.
| Credential | Purpose | Control |
|---|---|---|
| API role accounts | V1 and V2 API calls from integrations and scripts | One account per integration with only the API role; Portal ACL on API Connection; rotate the password on a schedule and on staff change |
| Mobile App role accounts | Admin mobile app access through the API | Grant only to administrators who need it; review with other roles |
| OAuth API clients | Token-based API access | Restrict the OAuth API Portal ACL by IP address, range or subnet |
| Directory bind account | Enterprise Connector access to Active Directory or LDAP | Read-only directory rights, a dedicated account and LDAPS; see the LDAP Security Deep Dive Guide |
| Portal HTTPS, Client TLS and iOS Enrollment certificates | Server identity and device trust | Managed at Security > Certificate Mgmt; track expiry; the identity certificate must be publicly trusted for mutual authentication |
| Standalone Sentry connection | Sentry fetching device information over 8443 | Allow only Sentry addresses in the Sentry Connection Portal ACL |
| Syslog TLS trust | Validating the syslog server identity | Upload the issuing CA certificate in PEM format for TLS over TCP |
| Azure or IdP app registrations and SAML signing certificates | Admin and user sign-in | Owner, expiry date and rotation plan recorded with the identity team |
Record every one of these in your non-human identity inventory with an owner and review date. The API Key Management Guide covers rotation and secret storage patterns that apply to API account passwords as well as keys.
Logging and detection
EPMM records administrator actions in the Admin Portal under Logs > Audit Logs. Ivanti's audit log use cases show the questions it answers: which administrator issued wipe commands and to how many devices (Device events, Wipe), who changed the Exchange configuration (Configuration events, Modify Configuration), who changed the security policy (Policy events, Modify Policy) and who deleted labels (Label events, Delete Label). Other categories cover certificate, MDM, AppTunnel and app events.
To keep a copy off the server, configure syslog in System Manager: Settings > Data Export > SysLog Servers > Add, choose TCP, TLS over TCP or UDP, upload a trusted server certificate for TLS, and set the facility and severity filter. Then pick categories under Settings > Data Export > SysLog Data > Advanced Options. Ivanti warns syslog can lose data at high volume, such as audit logs, so prefer TLS over TCP and watch for gaps.
| Syslog facility | Content (per Ivanti) | Detection use |
|---|---|---|
| local7 | Audit data, also shown in Logs > Audit Logs | Mass wipe or retire, policy and configuration changes, label deletion, role changes |
| local6 | Device data, including device access to EPMM and Admin Portal access | Admin Portal access from unexpected sources, unusual device registration bursts |
| local4 | Health data such as Apache and Linux logs | Web request anomalies against portals, service restarts |
| local3 | Virtual machine data such as Tomcat memory logs | Capacity and stability baselines |
Detections worth building in the SIEM: Admin Portal or API access from an address outside the Portal ACL networks (should be impossible, so any hit means an ACL change); wipe or retire actions above a per-hour threshold; new administrator or new API role assignment; policy or app control rule changes outside a change window; and syslog silence. In ATT&CK terms these cover misuse of valid administrator accounts (T1078 Valid Accounts) and abuse of the platform's ability to push software (T1072 Software Deployment Tools). See the SIEM Guide.
Metrics that show the controls are holding:
- ACL coverage: Admin Portal, System Manager, API Connection and OAuth API all restricted by Portal ACL, target 4 of 4.
- Strong admin sign-in: percentage of administrators authenticating through SAML with MFA or certificates, target 100% except break-glass.
- Mutual authentication adoption: share of devices checking in with mutual authentication, so port 9997 can be closed.
- API account hygiene: API role accounts with a named owner and a password changed within policy.
- Patch lag: days from an Ivanti EPMM security update to installation.
- Log completeness: hours per month with no local7 events at the SIEM.
Hardening baseline
Apply the baseline in phases on a test instance first, then production during a change window, with a System Manager configuration backup before each phase.
- Network placement: allow HTTPS on 8443 only from the corporate administration network. Separate device-facing services (443, 9997 until mutual authentication is complete) from administrative ones at the firewall.
- Portal ACLs: at Security > Access Control Lists > Portal ACLs, restrict Admin Portal, System Manager Portal, API Connection and OAuth API to admin and integration networks, and Sentry Connection to Sentry addresses. Use the expanded mask form (10.0.0.0/255.255.255.0); Ivanti notes shorthand prefix lengths are not valid and that behind NAT you enter the NAT address. Test from an allowed and a blocked address before closing the change.
- Admin authentication: enable SAML for administrators with MFA at the IdP, or certificate authentication for the Admin Portal, and keep one vaulted break-glass account.
- System Manager accounts: review Local Users, set a Password Policy, and configure SSH for public key authentication under Security > Advanced > SSH Configuration.
- Transport and web protections: under Security > Advanced, set Incoming and Outgoing SSL Configuration to current protocols and cipher suites, enable HSTS and Host Header Validation, and review ModSecurity, which Ivanti describes as protection against certain future vulnerabilities. Configure Trusted Front End where a reverse proxy sits in front of EPMM.
- Mutual authentication: confirm it is enabled. If enabling on an upgraded server, check client version prerequisites, avoid changing the enrolment configuration afterwards, and plan to disable port 9997 once all devices have moved to 443. This step cannot be rolled back.
- Delegation: create device spaces for each support team, move help desk administrators out of the global space, and give integrations API-only accounts.
- Logging: configure syslog over TLS with local6 and local7 at minimum and confirm events arrive.
- Updates: apply Ivanti EPMM security updates promptly, on an emergency cycle, and keep the server on a supported release. See the Patch Management Guide.
Small versus large deployments: a single-site deployment with one administrator team can use the global space with two or three platform owners and a single API account per integration. Large or regulated deployments should use device spaces per support team, SAML with phishing-resistant MFA for every administrator, separate System Manager operators, and a dedicated network segment for administration.
Common misconfigurations
- Portal ACLs left open: device-facing services must be reachable, but the Admin Portal, System Manager and API need not be. Without Portal ACLs they share the same exposure.
- Shared API accounts: one API account reused by several integrations, or a named administrator's account used for scripts, makes rotation risky and attribution impossible.
- Help desk in the global space: without device spaces, every support administrator can act on every device.
- Mutual authentication left at its previous state after upgrade: because upgrades keep the old setting, older servers can still rely on 9997 without mutual authentication; check and plan the move.
- Audit trail only on the appliance: syslog events stay on EPMM only until log rotation, so without forwarding, history for an investigation is short.
- Certificates without owners: expired portal or enrolment certificates break enrolment and push teams towards rushed changes; track them with other machine credentials.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|---|---|---|
| Admin and API account lifecycle, break-glass | AC-2 Account Management | PR.AA-05 | T1078 Valid Accounts |
| Device spaces and role scoping | AC-6 Least Privilege | PR.AA-05 | T1072 Software Deployment Tools |
| SAML with MFA, certificate authentication | IA-2 Identification and Authentication (Organizational Users) | PR.AA-05 | T1078 Valid Accounts |
| Mutual authentication, TLS configuration, HSTS | SC-8 Transmission Confidentiality and Integrity | PR.PS-01 | T1199 Trusted Relationship |
| Portal ACLs, port restrictions, SSH settings | CM-6 Configuration Settings; CM-7 Least Functionality | PR.PS-01 | T1078 Valid Accounts |
| Security updates | SI-2 Flaw Remediation | PR.PS-01 | T1072 Software Deployment Tools |
| Audit logs and syslog forwarding | AU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting | PR.PS-04; DE.CM-09 | T1072 Software Deployment Tools |
Practitioner checklist
- Record EPMM version, owners, every exposed port and which networks reach each portal.
- Configure Portal ACLs for Admin Portal, System Manager Portal, API Connection, OAuth API and Sentry Connection, and test them.
- Restrict port 8443 to the administration network.
- Move administrator sign-in to SAML with MFA or certificate authentication, with one vaulted break-glass account.
- Review System Manager local users, password policy and SSH public key configuration.
- Create device spaces for support teams and remove unneeded global administrators.
- Give each integration its own API role account with an owner, ACL and rotation date.
- Confirm mutual authentication is enabled and plan the closure of port 9997.
- Forward local6 and local7 to the SIEM over TLS and alert on mass wipe, role and policy changes.
- Track certificate expiry and apply Ivanti security updates promptly.
Standards and references
- Ivanti: EPMM System Manager security overview
- Ivanti: Access Control Lists: Portal ACLs
- Ivanti: Advanced: Portal Authentication
- Ivanti: Mutual authentication between devices and Ivanti EPMM
- Ivanti: EPMM V1 API authentication
- Ivanti: Data Export: SysLog
- Ivanti: Port Settings
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Mobile Device Management Security Guide, MDM and UEM platform health check, If your MDM and UEM platform is compromised, Service Account Security Guide.