Omnissa Workspace ONE UEM Security Guide

Whoever controls the Workspace ONE UEM console can push software to, lock or wipe every enrolled device, so the console deserves the same protection as a domain controller. Omnissa Workspace ONE UEM (formerly VMware Workspace ONE UEM, and AirWatch before that) manages phones, tablets, Macs, Windows PCs and rugged devices from one tenant, organised into a tree of organisation groups. This guide covers the product-specific controls: how administrators authenticate, how roles and organisation groups scope their power, how REST API clients and directory bind accounts are handled, what to send to your SIEM, and a hardening baseline built from Omnissa documentation and the DISA STIG for the UEM server. It is for UEM administrators, endpoint security engineers and identity teams. The general case for treating MDM as tier zero is in the Mobile Device Management Security Guide; this page goes one level deeper into Workspace ONE itself. Menu paths below come from Omnissa documentation for console releases 2302 to 2410; option names and availability differ between SaaS, dedicated SaaS and on-premises deployments, so confirm them against the documentation for your release.

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

Key takeaways

Federate admin sign-in. Use the SAML option for Admin under Directory Services so console access inherits your identity provider's MFA and Conditional Access, and keep local console accounts to a small, monitored break-glass set.
Roles and organisation groups are two separate dials. A role decides what an admin can do; the organisation group it is assigned at decides where. Both must be narrow.
Turn on every Restricted Actions PIN. Device wipe always needs a PIN, but enterprise wipe, device delete, admin account delete and REST API key delete are toggles that should be enabled, with notes required.
Treat OAuth clients as privileged non-human identities. Each client carries a role; scope it, store the secret in a vault, and review it like an administrator.
Stream console events in real time. Syslog over Secure TCP to the SIEM gives you admin logins, role changes and destructive actions as they happen.

How identity and access work in Workspace ONE UEM

Three populations authenticate to a Workspace ONE UEM tenant, and each has its own controls:

Console administrators: sign in to the web console with a local UEM account, a directory account, or through SAML from your identity provider. The SAML route is configured at Groups & Settings > All Settings > System > Enterprise Integration > Directory Services by selecting Use SAML for Authentication and then enabling SAML authentication for Admin (the same setting can also apply SAML to Enrollment and the Self Service Portal).
End users enrolling devices: authenticate during enrolment with directory, SAML or basic UEM credentials, and receive an end user role (Full Access, Basic Access or External Access by default).
Machine clients: REST API callers authenticate with OAuth 2.0 client credentials (SaaS) or legacy API keys, and the Enterprise Systems Connector binds to your directory with a service account.

Directory integration is the hinge. The LDAP connection supports Encryption Type None, SSL or Start TLS; the port defaults to 389 and changes to 636 when SSL is selected. Choose SSL or Start TLS, and use LDAP protocol version 3. The bind account needs only read access to the directory; it can be a named bind user or the App pool identity of the Enterprise Systems Connector server (Use Service Account Credentials). Group sync settings matter for privilege: Auto Merge applies directory membership changes without admin approval up to the Maximum Allowable Changes threshold, so a directory compromise can flow straight into console user groups. Keep that threshold low for groups that drive admin access or enrolment rights.

Local console accounts follow the password policy at Groups & Settings > All Settings > Admin > Console Security > Passwords, which can only be set at the Global organisation group. Documented values: minimum length 7 characters, expiry up to 120 days, up to 6 invalid attempts before lockout, default lockout 10 minutes, complexity either letters and numbers (default) or letters, numbers and special characters, plus password history and recovery questions. Those are weak by modern standards, which is the main reason to push administrators through SAML and your identity provider's phishing-resistant MFA instead. See the Federation and Trust Relationships Guide for the trust you are creating.

Admin sign-in route	MFA and policy	Main risk	Use for
SAML from your identity provider	Inherits IdP MFA, Conditional Access and session controls	IdP compromise or a misconfigured SAML signing setup	All day-to-day administrators
Directory (LDAP) account	Directory password only at the console	Password spray and stolen directory credentials	Avoid for admins where SAML is available
Local UEM account	Console password policy (7 character minimum)	Short minimum length, often forgotten in offboarding	Break-glass only, two accounts, monitored

Admin roles and privileged access

Roles are built from resources, each granting Read or Edit on a console function. Omnissa's default admin roles include System Administrator, AirWatch Administrator, Console Administrator, Device Manager, Report Viewer, Content Management, Application Management, Help Desk, App Catalog Only Administrator, Read Only, Horizon Administrator, NSX Administrator and Privacy Officer. Default roles update automatically when new features ship; custom roles do not, so every upgrade needs a pass over custom roles to decide whether new resources should be granted. Role changes take effect only after the admin signs out and back in.

Scope comes from the organisation group (OG). A role is associated with the OG where it was created, and an admin assignment at a parent OG reaches every child OG. A Help Desk role at the Global OG can act on every device in the tenant; the same role at a regional OG cannot. Design the OG tree with administration in mind, not only device grouping.

Need	Approach	Notes
Tenant-wide configuration	System or AirWatch Administrator at Global or Customer OG	Smallest practical number of people; the DISA STIG asks for AirWatch Administrator and Device Manager to be limited this way
Regional or business unit device support	Copy of Help Desk or Device Manager, assigned at the child OG	Remove wipe and delete resources unless the team truly needs them
App and content publishing	Application Management or Content Management	App publishing is code execution on every device in scope (ATT&CK T1072)
Audit and reporting	Read Only or Report Viewer	Good default for auditors and security analysts
Privacy review	Privacy Officer	Separates who can change data collection settings

Use the role Compare function, which compares exactly two roles and exports differences to CSV, to evidence least privilege during reviews. Omnissa also warns that staging user credentials (used to enrol devices on behalf of users) should be treated with the same care as administrator credentials.

The DISA Omnissa WS1 UEM Server STIG (dated 15 June 2026) includes a requirement that each predefined administrator role (AirWatch Administrator, Device Manager and Read Only) has at least one member, or an approved custom equivalent, and that the two powerful roles are held by as few people as possible. The point is separation of duties: if every administrator holds the top role, nobody is limited.

Restricted Actions: the second lock on destructive commands

Groups & Settings > All Settings > System > Security > Restricted Actions controls which admin actions need a security PIN and which need a note. Some actions always need a PIN and cannot be turned off: Device Wipe, Organisation Group Delete, APNs Certificate Change, Data Encryption Toggle, Regenerate Enterprise Systems Connector Certificate, Secure Channel Certificate Clear, Force BIOS Password Reset and App Scan Vendor Reset/Toggle. Others are toggles and should all be enabled, in particular Enterprise Wipe, Device Delete (bulk delete always needs a PIN), Admin Account Delete, Admin Password Change, Profile Delete/Deactivate, Revoke Certificate, Delete REST API Key, Delete Workspace ONE Access Configuration and Change in Privacy Settings. Set Maximum invalid PIN attempts low (the range is 1 to 5); exceeding it logs the session out and forces a new PIN. Tick Require Notes so wipes, locks, reboots and enterprise resets carry a recorded reason. Set Child Permission so child OGs inherit rather than override these settings.

A PIN is not multi-person approval: an attacker holding a hijacked admin session can set or know the PIN. It does add friction and a logged step. Our recommendation at NHI Mgmt Group: give destructive actions both narrow role scope and alerting. See the Privileged Access Management Guide for just-in-time elevation patterns you can apply to the top roles.

Integrations, API tokens and service accounts

Workspace ONE UEM accumulates non-human identities quickly: REST API clients for automation and ITSM, the directory bind account, the Enterprise Systems Connector, SCEP and certificate authority connectors, and the Apple Push Notification service (APNs) certificate. Each one is a path to the console's power.

OAuth clients: in SaaS, create them at Groups & Settings > Configurations > OAuth Client Management with a name, description, organisation group and role. The role sets the API permissions (each maps to API calls with Read Only or Edit access), and the OG sets scope. The client secret is shown once and cannot be retrieved later. Tokens are issued by the Workspace ONE Token Service at a regional endpoint (for example na.uemauth.workspaceone.com or emea.uemauth.workspaceone.com) using the client_credentials grant.
Token lifetime: OAuth Token Validity under Session Management defaults to 3,600 seconds; a value of zero makes tokens always valid. Never set zero.
Legacy API keys: older integrations use an API key combined with an admin account's credentials. Migrate them to OAuth clients with dedicated roles, and enable the Delete REST API Key PIN so keys cannot be silently removed and replaced.
Directory bind account: read-only, excluded from interactive logon, password in a vault, and alerted on if used from anywhere but the connector host.
APNs certificate: Omnissa asks for a corporate Apple account dedicated to MDM, not a person's, and renewal must use the same account that created the certificate; losing access to it can force re-enrolment of Apple devices.

Credential	Where it lives	What it can do if stolen	Control
OAuth client secret	Automation platform, ITSM, scripts	Anything its role allows at its OG (T1528)	Dedicated custom role, child OG, vault, rotate, 1 hour tokens
Legacy API key plus admin account	Old integrations	Acts as that admin	Replace with OAuth client, then delete
Directory bind account	Directory Services settings, connector	Read directory data; directory pivot	Read-only, SSL or Start TLS, vault, sign-in alerts
Staging user	Enrolment staff, device prep	Enrol devices into the tenant	Treat as admin credential, per Omnissa guidance
Local break-glass admin	Sealed vault entry	Full console	Two accounts, alert on every use

Omnissa's move from legacy VMware domains to Omnissa domains required firewall changes by 15 June 2025 for API-driven and automation tasks; if old allow lists or scripts still reference VMware hostnames, review them as part of the integration inventory. For the wider discipline, see the API Keys vs OAuth Tokens Guide and the OWASP NHI5 Overprivileged NHI Guide.

Logging and detection

Workspace ONE UEM can send console events and device events to a SIEM through Monitor > Reports & Analytics > Events > Syslog. Console events are sent in real time. Protocol options are UDP, TCP and Secure TCP; message format can be the Workspace ONE UEM Legacy format, RFC 3164 or RFC 5424. Use Secure TCP and RFC 5424, set a distinctive Message Tag, and use Test Connection before relying on it. Omnissa recommends the AirWatch Cloud Connector for SaaS syslog delivery even when the SIEM endpoint is reachable publicly. Enable all console event categories; device events are noisier and can be trimmed. See the SIEM Log Source Onboarding Checklist.

Detection	Signal	Why it matters
New admin account or role assignment	Console events for admin create and role change	Persistence and escalation (T1098)
Bulk or out-of-hours wipe, enterprise wipe or device delete	Console device action events, count per admin per hour	Destructive impact (T1485)
New or changed app, product provisioning or script	Application and product events	Software deployment as execution (T1072)
OAuth client created, enabled or role changed	Configuration events	New machine path to the console
Restricted Actions, password or session settings changed	Settings events	Defence weakening before an attack
Local admin login	Console login events with account type	Break-glass use or bypass of SAML
Failed security PIN attempts	Console events	Someone probing a destructive action

Pair these with identity provider sign-in logs for the SAML application so you can tie a console session to device, location and MFA method. Useful measures: percentage of console admins signing in through SAML (target 100% except break-glass), number of admins holding tenant-wide roles, OAuth clients with a named owner and a review date, mean time to alert on a bulk wipe, and days since last custom role review.

Hardening baseline

Inventory first: export admins, roles, OG assignments, OAuth clients, API keys and directory settings. Record who owns each.
Federate admins: configure SAML for Admin under Directory Services, apply phishing-resistant MFA and device conditions in the identity provider, and test with a pilot group before moving everyone.
Reduce local accounts: keep two local break-glass accounts with the strongest password complexity setting, lowest practical lockout threshold and expiry, and delete the rest.
Session limits: under Admin > Session Management set Idle Session Timeout towards the 15 minute floor (range 15 to 480), turn off Allow Multiple Sessions, turn off Allow IP Address Change, keep Forced Session Timeout well under the 1,440 minute default, and keep OAuth Token Validity at or below 3,600 seconds.
Restricted Actions: enable every toggle PIN, require notes, set PIN attempts to 3 or fewer, force inheritance to child OGs.
Roles: move people off System and AirWatch Administrator into scoped custom roles; assign at the lowest OG that works; review custom roles after every upgrade.
Enrolment: require directory or SAML authentication for enrolment, use Restrict Enrollment to Configured Groups where it fits, and treat staging accounts as privileged.
Compliance policies: define passcode, encryption, OS version and check-in rules per platform, and use the escalation sequence (notify, restrict profiles and apps, then remove access) rather than jumping to a wipe. Feed compliance into access decisions; see the Device Trust and Posture Guide.
Logging: Secure TCP syslog with all console events to the SIEM, detections from the table above.
Patching: subscribe to Omnissa Security Advisories (OMSAs). On-premises servers are your responsibility, so apply Omnissa security updates promptly and track each OMSA to closure.

Rollback: SAML for Admin is the change most likely to lock people out. Keep the break-glass accounts tested before you switch, change one OG at a time where OG-level settings allow it, and use the Settings Audit and Comparison tools under Admin settings to record before and after states.

Common misconfigurations

Everyone is an AirWatch Administrator at Global: convenient during rollout, never cleaned up. Every help desk session can wipe the whole fleet.
Toggle PINs left disabled: enterprise wipe and device delete run with one click, and nobody records why.
OAuth Token Validity set to zero: tokens never expire, so a leaked token is a permanent key.
Integration accounts on a person's identity: legacy API keys tied to a named admin break when that person leaves, or worse, survive their departure.
Plain LDAP on port 389: bind credentials and directory queries cross the network unencrypted.
Custom roles never revisited: new features arrive with new resources, and custom roles silently miss controls or are bulk-granted Edit to catch up.
Syslog never tested: the integration is enabled but the SIEM receives nothing after a certificate or connector change.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK v20
Federated admin sign-in with MFA	IA-2(1)	PR.AA-05	T1078.004
Scoped roles and OGs	AC-6, AC-6(5)	PR.AA-05	T1098
OAuth clients and bind accounts	IA-5, AC-2	PR.AA-05	T1528, T1552
Restricted Actions and settings baseline	CM-6	PR.PS-01	T1485, T1072
Console events to SIEM	AU-6	DE.CM-03	T1098
Device and admin inventory	CM-8	ID.AM-02	T1199

Practitioner checklist

Enable SAML authentication for Admin and require phishing-resistant MFA in the identity provider.
Keep exactly two local break-glass console accounts and alert on every login.
Reassign tenant-wide roles to scoped custom roles at the lowest workable organisation group.
Enable every toggleable Restricted Actions PIN, require notes and force inheritance.
Set idle timeout near 15 minutes, disable multiple sessions and IP address change, keep OAuth tokens at one hour or less.
Give every OAuth client a dedicated role, an owner and a vaulted secret; retire legacy API keys.
Use SSL or Start TLS for directory binds and keep Auto Merge thresholds low.
Send all console events over Secure TCP syslog and build alerts for admin changes and bulk wipes.
Review custom roles after each upgrade and patch on-premises components against OMSAs.

Omnissa Workspace ONE UEM Security: Console Roles, Compliance and APIs