AirWatch and Cisco ISE for stronger network access control
Combining device management with identity-aware enforcement gives organisations a stronger basis for network access decisions. AirWatch, now associated with VMware, provides enterprise mobility management for configuring devices, managing apps and assessing endpoint compliance. Cisco Identity Services Engine (ISE) adds identity and network context, helping security teams decide whether a user and device may reach sensitive resources.
The platforms serve different layers. AirWatch manages the endpoint and its posture, while Cisco ISE evaluates the connection and enforces access policy. Integrating them links a managed, compliant tablet with an authorised user instead of allowing every device on corporate Wi-Fi to share the same privileges.
The result is conditional access rather than a blunt allow-or-deny rule. Mobile employees can work on personal devices under BYOD programmes, with company data protected by application, file and network controls. IT teams maintain visibility and support, while network teams can respond when compliance changes.
Real benefits depend on sound integration design, not merely operating two consoles. Identity sources, device records, compliance attributes and enforcement points must agree on what they mean. Australian organisations with hybrid work across Sydney and Melbourne offices, distributed systems and flexible device ownership have much to gain from a carefully tested approach.
How mobility posture changes access decisions
AirWatch posture describes what the endpoint is and whether it meets organisational rules. Compliance profiles can check operating-system versions, encryption, screen locks, passcodes, rooting or jailbreak status, configuration drift and required applications. The result is a posture signal attached to a managed device record, useful even when that device operates outside an office.
Cisco ISE applies the network-side decision. It combines identity, requested service, network location and other session attributes to choose an access policy. Through RADIUS or TACACS+, enforcement points can permit a session, restrict it to limited services, or steer it into a different VLAN or access segment. ISE does not replace the mobility platform; it uses posture context alongside identity and network risk.
How the integration works
A typical integration begins with a shared corporate identity. The user authenticates through the organisation’s identity provider, and both systems reference stable user and device identifiers. AirWatch associates the user with endpoint records and compliance results. In a supported design, relevant posture attributes reach ISE through an approved connector, API exchange or identity broker, subject to product versions, licensing and support boundaries.
ISE then evaluates those attributes against policy sets. A rule might permit full application access to a managed, compliant device with strong authentication while allowing a BYOD handset to reach only selected resources. The decision is enforced at switches, wireless controllers and other supported access points. Device status and network session context therefore converge on one auditable access decision.
Continuity matters after the initial connection. AirWatch can detect a change in compliance, but enforcement speed depends on the integration path and network architecture. Re-evaluation, session refresh and fallback behaviour should be tested so that a failed update does not accidentally grant access or interrupt legitimate work.
Comparing responsibilities and outcomes
A useful comparison separates device administration from connection enforcement. It also prevents the expectation that either product will cover the other’s operational gaps.
| Concern | AirWatch | Cisco ISE | Combined outcome |
|---|---|---|---|
| Primary purpose | Manage enterprise endpoints, apps and compliance | Govern identity- and session-based network access | Mobility posture informs network authorisation |
| Main context | Device ownership, configuration, app state and compliance | User identity, requested service, network and device context | A shared view of authorised users and managed devices |
| Typical action | Enforce settings, deploy apps and trigger remediation | Permit, restrict or redirect sessions through enforcement points | Automated conditional access with remediation |
| Primary ownership | Mobility and endpoint teams | Network and security teams | Agreed policy ownership and escalation paths |
Shared ownership matters because the same compliance rule can otherwise produce conflicting outcomes. A documented policy owner should decide which system interprets each signal, how quickly changes take effect and who approves exceptions.
A practical rollout sequence
A controlled rollout reduces the risk of locking legitimate users out or exposing sensitive resources during an untested policy change. The pilot should include corporate devices, BYOD users and a limited access segment rather than the entire organisation.
Use the following sequence to build evidence before expanding enforcement:
- Map identities and devices, agreeing on authoritative identifiers and an owner for every critical attribute.
- Validate a supported integration path with the exact product releases, measuring signal latency and the effect of stale compliance data.
- Stage new policies in audit or limited-enforcement mode before applying blocking decisions to production access.
- Test lifecycle events such as enrolment, non-compliance, remediation, lost-device response, contractor departure and offboarding.
Measure operational results as well as technical success. Record how many sessions reach each enforcement outcome, how long remediation takes and where support staff need to intervene manually. These results reveal whether the policy is practical before its scope expands.
Australian deployment considerations
Australian operating conditions make shared policy particularly valuable. Teams often move between Sydney and Melbourne CBDs, home connections and regional sites, while field and retail workers in Brisbane and Perth use managed tablets across warehouses, airports and customer networks. Common workplace customs—hot-desking, BYOD allowances and shared workstations—make the office network a poor proxy for trust. The decision should follow the authorised user and compliant device as the connection changes.
The local market also shapes evidence and privacy expectations. Many financial institutions must meet APRA CPS 230, healthcare organisations operate under state and sector-specific obligations, and government buyers such as the Australian Customs Service require accountable controls within their own supply chains. The Privacy Act 1988 and applicable Australian Privacy Principles add privacy duties, while the Australian Signals Directorate’s Essential Eight provides a familiar baseline for patching, multifactor authentication and incident readiness.
These requirements favour managed device records, traceable policy decisions and clear recovery processes. A device can retain access to email and collaboration tools while sensitive applications remain unavailable. Such separation supports productivity without granting a compromised or non-compliant endpoint the same privileges as a fully managed workstation.
Validate security, privacy and recovery
Integration can expose sensitive device and user information, so data minimisation should guide the exchange. Administrators need enough posture detail to distinguish risk levels, not a complete inventory of every application on a personal phone. Apply least privilege to connector accounts, define retention for posture and session logs, and confirm that any third-party services meet contractual data-residency requirements. Endpoint posture should complement dedicated threat detection rather than substitute for it.
Network admission is only one protection layer. Once access is granted, managed documents still need appropriate safeguards. This mobile file security review examines how file-level controls can protect business content on managed mobile devices, complementing the network access decision.
Validation should cover failure as well as successful policy matches. Test what happens when a device falls out of compliance, a posture update is delayed, an ISE node is unavailable, a device is lost or a user leaves. Confirm that network infrastructure enforces change of authorisation correctly and that support staff have a clear recovery path. Record evidence of decisions and remediation, then use it to refine exceptions and policy thresholds.
Begin with a controlled integration path
A useful next step is a scoped proof of concept with representative devices, a defined identity provider and one or two access zones. Agree on success measures: posture-data latency, correct policy matches, session enforcement, recovery time and support effort. This turns the integration into a testable business outcome rather than an open-ended technical project.
Review the AirWatch pricing and package comparisons, read customer stories and contact the sales team with the target ISE version, device population and access segments in mind. Request the fully functional 30-day free trial and contact AirWatch sales to scope a supported AirWatch and Cisco ISE integration for your organisation.