IBM MaaS360 Security: Admin Roles, Policies and Compliance Rules

The IBM MaaS360 Portal can push policy to, lock, wipe and change apps on every enrolled phone, tablet and laptop, so portal administrators, enrolment settings and API credentials are tier zero for the whole device fleet. IBM runs the MaaS360 service, and the customer decides who administers it, how devices enrol, which compliance rules apply and which integrations call its web services. This guide covers those customer-side controls: administrator sign-in with SAML and two-factor authentication, roles and group-based access control, enrolment authentication, compliance rule sets, web services credentials, audit reports and a console hardening baseline. It is written for endpoint and mobility teams, identity architects and security reviewers. For MDM principles across platforms, see the Mobile Device Management Security Guide.

This is an independent guide from NHI Mgmt Group, based on IBM's public MaaS360 documentation as of November 2026. It is not sponsored or reviewed by IBM. Product features change, so confirm settings against IBM's current MaaS360 documentation.

Key takeaways

• Federate and add a second factor for every administrator. Administrator Settings offer Federated Single Sign-on (SAML), corporate directory login, 2-Factor Authentication and sign-in restricted to registered devices.
• Turn on Administrative Access Control. With Enable Administrative Access Control, administrators see only the users and devices in the managed user groups they are assigned.
• Keep the password prompt on Prompt Always. It is the default re-authentication for important actions, and only a Service Administrator can change it.
• Harden enrolment before you scale it. Use corporate (SAML, Azure or on-premise) enrolment authentication, a Corporate Usage Policy, per-user device limits and an allowed platform list.
• Treat web services credentials as a privileged admin. API calls authenticate with an app access key plus an administrator's username and password, so give that account its own narrow role.

How identity and access work in IBM MaaS360

MaaS360 has three identity planes: portal administrators who manage the service, end users who enrol devices, and integrations that call the MaaS360 web services. Security is a shared responsibility: IBM operates the platform, and the customer configures administrator access, enrolment, policy and integrations.

Administrator sign-in settings

Administrator Settings (Setup, Administrator Settings) has three tabs. The security-relevant settings are:

• Federated Single Sign-on (SAML): Configure the identity provider name, sign-in page URL, verification certificate, notification email and a custom administrator login URL. Enforce MFA and conditional access in your IdP. See the Identity Provider and SSO Security Guide.
• Corporate User Directory (AD/LDAP): Authenticates administrators against your directory through Cloud Extender, with optional auto-provisioning on first login. If you use auto-provisioning, map it to a low-privilege role and review new accounts.
• Strong authentication, registered devices: Limits administrator logins to previously registered devices; new devices need secondary validation.
• Strong authentication, 2-Factor Authentication: A passcode by SMS or email, or a time-based code from an authenticator app, in addition to credentials. Our recommendation: use the authenticator app option for every administrator account that signs in with MaaS360 credentials.
• Logout administrator sessions: Inactivity timeout, default 15 minutes and maximum 120 minutes, with a two-minute warning. Keep it at 15 minutes for administrators.
• Password prompt: Prompt Always (default), Let Administrator Choose (5, 10 or 20 minutes, or the session) or Never Prompt. Only global administrators with the Service Administrator role can change it, and changes apply at next login. Keep Prompt Always.
• Alerts: Turn on Alert administrator on new device discovery and Alert administrator on permanent user deletion so unexpected changes reach a monitored mailbox.

Admin roles and privileged access

Administrators are added under Setup, Portal Administrators, Administrators, Add Administrator, with an email, a username, one or more roles and an optional limit to specific managed user groups. New administrators receive temporary credentials by email. An administrator can only create accounts with equal or lesser access, for example a Help Desk administrator can create only Help Desk accounts. Roles named in the documentation include Service Administrator, Administrator and Help Desk; custom roles are created with Add Role, either new or copied from an existing role, and granted access rights such as managing the app approval process, generating administrator audit reports and managing apps and devices.

• Scope caveat: A group-scoped administrator sees only their users and devices but can still edit and publish policies, compliance rule sets, apps and documents that apply to all of their groups, which can affect groups outside their assignment. Keep policy publishing in a central role.
• Destructive actions: Limit device wipe rights to help desk leads and log every use with a ticket. Re-authentication through Prompt Always is your second check.
• Review cadence (ours): Export administrators and roles monthly, remove leavers the same day and check the History of each role for changes.

Enrolment security and compliance rules

Directory and enrolment settings

From MaaS360 10.76, enrolment can also use Microsoft Entra multi-factor authentication for iOS, Android and Windows devices; IBM Support enables it. If MaaS360 two-factor and Entra MFA are both on, users complete three factors, with Entra checked first. Passcode mode, where the code goes to the user's corporate email, is the simplest option; pair it with mailbox MFA if you use it.

Compliance rule sets

Compliance rule sets live under Security, Compliance Rules, Add Rule Set. IBM's customer success material describes conditions including enrolment status, OS version ranges and allowed or disallowed versions, remote wipe support, encryption support, application compliance against the policy's app list, and jailbroken or rooted status. Each rule can take its own enforcement actions and alert its own email addresses, actions can be stacked, and rule sets can be targeted with group-based rules. A rule set holds one OS version range per OS type, so create a second rule set for legacy devices. The Compliance Log shows all compliance actions in one place.

• Start with alerting: Assign a new rule set to a pilot group with email alerts only, read the Compliance Log for a week, then add blocking or removal actions.
• Mail blocking: The Block action applies to mail flow and needs Cloud Extender integrated with your mail environment.
• Exemptions: Devices can be exempted from compliance rules. Keep a list with owners and expiry dates, and review it monthly.
• Rule changes: Rule changes are audited (see Logging and detection), so require a change ticket for every rule set edit.

Integrations, API tokens and service accounts

MaaS360 web services are provisioned per app by IBM MaaS360 Support. A client authenticates with a POST to the auth-apis authenticate endpoint for its billing ID, sending the billing ID, platform ID, app ID, app version, app access key and an administrator's username and password, and receives a token valid for 60 minutes that is passed in the Authorization header. The API root depends on the account's region. In practice the integration is an administrator account, so it needs the same care as a human admin.

• One account per integration (ours): Name the API administrator after the integration and its owner, so the login report and audit data show which system acted.
• Rotation (ours): Rotate the API administrator password on a schedule and whenever an integration owner leaves; ask IBM Support about replacing an app access key if it is exposed.
• Secrets handling: See the Secrets Management Guide and the API Key Management Guide.

Logging and detection

The Administrator Login Report (Setup, Portal Administration) shows username, login attempt time, logout time, duration, operating system, browser version, IP address and authentication status, filtered over 7, 15 or 30 days and exportable as CSV or Excel. An IBM Community post describes Admin Audit Data under Reports, Audit, Administrators: CSV reports for Administrator Login, Administrator Changes, Administrator Roles, Group Changes, Rules Changes, Services, Deployment Settings, Login Settings, End User Notification Settings and Policies Changes, covering the previous 60 days, emailed within 30 minutes and requestable up to three times a day. Per-object History is available on administrators, roles and policies.

Because audit data covers 60 days, schedule a request at least monthly and keep the CSVs in your SIEM or log store. Metrics: administrators without SSO or 2FA; administrators not limited to groups; devices out of compliance for more than seven days; compliance exemptions past expiry; API administrator accounts without a named owner; days of audit history retained outside MaaS360.

Hardening baseline

1. Inventory: List administrators, roles, partner-inherited roles, API administrator accounts and integrations; request Admin Audit Data for the last 60 days as a baseline.
2. Admin sign-in: Configure Federated Single Sign-on (SAML) for administrators, turn on 2-Factor Authentication and registered devices, set the timeout to 15 minutes and keep Prompt Always. Test with one administrator first and keep a break-glass Service Administrator able to sign in if the IdP fails.
3. Roles: Build custom roles per job, enable Administrative Access Control and limit non-global administrators to their groups.
4. Enrolment: Move enrolment to Corporate (SAML based) or Corporate (Azure) with two-factor, set the Corporate Usage Policy, device limits and allowed platforms.
5. Compliance: Pilot rule sets with alerts, then add enforcement actions by group; document exemptions.
6. Integrations: Give each integration a dedicated API administrator and store its credentials in a secrets manager.
7. Logging: Schedule monthly audit data requests and export the login report weekly.
8. Rollback: Record each setting before change; login settings apply at next login, so keep a second session open while you test SSO and 2FA changes.

Smaller fleets can rely on 2FA, a few custom roles and a single rule set. Larger and multi-region estates add group-scoped administrators, separate rule sets per platform and legacy OS range, and SIEM retention of audit data.

Common misconfigurations

• Every administrator a Service Administrator: Roles become meaningless and anyone can change the password prompt. Keep the role to two people.
• Group-scoped admins publishing global policies: Scoped admins can edit policies that also apply outside their groups. Centralise policy publishing.
• Integration using a named person's admin account: The integration breaks when the person leaves and its actions look like theirs. Use a dedicated API administrator.
• Passcode enrolment with no limits: Anyone with mailbox access can enrol unlimited devices. Use corporate authentication and per-user limits.
• Compliance enforcement turned on fleet-wide on day one: Pilot first with alerts.
• Audit data never exported: After 60 days the history is gone from the request window. Export monthly.

Framework mapping

Practitioner checklist

• Configure SAML SSO for administrators and turn on 2-Factor Authentication with an authenticator app.
• Restrict administrator logins to registered devices and keep the session timeout at 15 minutes.
• Keep the password prompt on Prompt Always.
• Limit Service Administrator to two people plus a vaulted break-glass account.
• Enable Administrative Access Control and limit non-global administrators to their groups.
• Use corporate enrolment authentication with two-factor, a Corporate Usage Policy and per-user device limits.
• Pilot compliance rule sets with alerts, then enforce by group with documented exemptions.
• Run each integration on a dedicated API administrator with credentials in a secrets manager.
• Export the login report and request Admin Audit Data at least monthly.

Standards and references

• IBM: Configuring administrator settings in the MaaS360 Portal
• IBM: Adding a portal administrator account
• IBM: Creating an admin role for portal administrators
• IBM Support: Setting access control for MaaS360 admins
• IBM: Configuring directory and enrollment settings
• IBM Support: MaaS360 Web Services Integration
• IBM: Viewing the administrator login report
• IBM Community: MaaS360 compliance rules
• IBM Community: Get admin audit reports

Related NHI Mgmt Group resources: Mobile Device Management Security Guide · Identity Provider and SSO Security Guide · NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments · Secrets Management Guide