Skip to content
Setup

Requirements and prerequisites

What to prepare on your Cisco ISE before connecting a Context: the three API families, a dedicated API user, Endpoint Custom Attributes, network reachability, and how admins and Self-Service users sign in.

Endpoint Manager is delivered as SaaS — there’s nothing to install on-premises. Everything it does happens over an HTTPS connection from the platform’s egress FQDN to your Cisco ISE. This page is the checklist of what you line up on your side before you wire up the connection in Cisco ISE connection.

Endpoint Manager talks to Cisco ISE through its REST APIs, so you need an ISE deployment whose Primary Administration Node is reachable over HTTPS and has the three API families below enabled.

Note

Endpoint Manager requires Cisco ISE 3.2 Patch 2 or later — the release that introduced the Open API surface it depends on for per-endpoint operations and Endpoint Custom Attribute sync. Earlier patch levels may work but are not formally supported. The guides are most recently verified against current 3.4 releases, so stay close to a current release if you can.

API familyUsed for
ERS (External RESTful Services)Reading and creating Endpoint Identity Groups; listing endpoints in bulk.
Open APIPer-endpoint create / read / update / delete; Endpoint Custom Attribute sync.
Monitoring API (MnT)Reading live session data; issuing Change of Authorization.

All three have to be enabled on the deployment. If any one is off, the Cisco ISE API Status table on the connection screen reports it as Down and the Context refuses to operate. The step-by-step enablement lives in Cisco ISE connection.

Mint an ISE admin user specifically for Endpoint Manager — don’t reuse a human administrator’s credentials. It needs to:

  • Read, and optionally create, Endpoint Identity Groups.
  • Read, create, update and delete endpoints.
  • Read endpoint session data from the Monitoring API.
  • Issue Change of Authorization requests.

In ISE role terms that lines up with ERS Admin, Open API Admin and MnT Admin. Give it a strong, unique password. It’s stored encrypted and never shown back once saved, and you can rotate it any time from API Configuration.

Endpoint Manager keeps a little metadata on each endpoint — who created it, when, and an optional device-type tag — using Cisco ISE’s Endpoint Custom Attributes. Define these under Administration → Identity Management → Endpoint Custom Attributes before you connect a Context:

AttributeTypeHolds
ngCreatedByStringWho created the endpoint (an admin or a Self-Service user)
ngCreatedAtStringWhen it was created
ngUpdatedByStringWho last changed it
ngUpdatedAtStringWhen it was last changed
ngDeviceTypeStringDevice-type tag

ngDeviceType is seeded by the platform as an endpoint level definition named Device Type, pre-selected on every group; the attribute itself must still exist in ISE. Attribute names beginning with ng are reserved for the platform.

On top of these you can define any number of your own attributes, at group level (one value for a whole group, think vendor-owner or maintenance-window) or endpoint level (a value per device, think asset-id, end-date, or a Wi-Fi key). Each of those must exist in ISE too, under the exact same name. ISE silently discards values for names it doesn’t recognise, so a mismatch saves without error and never reaches the endpoint. See Managed Attributes.

The traffic is HTTPS, outbound from your ISE side to the platform and inbound from the platform to ISE’s APIs:

  • Allow outbound HTTPS (TCP 443) from the ISE Primary Administration Node — or the segment in front of it — to the platform’s egress FQDN.
  • Let the platform’s egress reach ISE’s ERS, Open API and MnT endpoints.

The exact egress FQDN is shown in the API Configuration card of each Context (it looks like pn.sr1.c0.example.net). Which one you get depends on the delivery option you chose — Global Cloud or Nordic Sovereign Cloud.

If a reverse proxy, WAF or API gateway sits in front of your ISE admin node, it has to pass these calls through — they’re the exact surface Endpoint Manager talks to on each API family. The HTTP method matters as much as the path: security appliances are often configured to allow only GET and POST, and that silently breaks the operations that rely on PUT or DELETE.

ERS API

MethodPathPurpose
GET/ers/config/endpointgroupList and search Endpoint Identity Groups
GET/ers/config/endpointgroup/{id}Read a single Endpoint Identity Group
POST/ers/config/endpointgroupCreate an Endpoint Identity Group
GET/ers/config/endpointList endpoints in bulk (large group listings)

Open API

MethodPathPurpose
GET/api/v1/endpointSearch and list endpoints
GET/api/v1/endpoint/{id}Read a single endpoint
POST/api/v1/endpointCreate an endpoint
PUT/api/v1/endpoint/{id}Update an endpoint
DELETE/api/v1/endpoint/{id}Delete an endpoint
POST/api/v1/endpoint/bulkCreate endpoints in bulk
PUT/api/v1/endpoint/bulkUpdate endpoints in bulk

Endpoint Custom Attribute values (including Managed Attributes) travel inside these endpoint calls: there is no separate custom-attribute API traffic to allow.

Monitoring (MnT) API

MethodPathPurpose
GET/admin/API/mnt/Session/MACAddress/{mac}Read live session data for an endpoint
GET/admin/API/mnt/CoA/Reauth/...Issue a Change of Authorization (reauthentication)

Note that Change of Authorization is issued as a GET: the Monitoring API needs no write methods.

On top of the calls above, Endpoint Manager sends a single HEAD request to the base URL of your ISE when you save the connection, to validate the TLS certificate before the first real API call.

Warning

Check your WAF, reverse proxy or API gateway specifically for method filtering, not just path rules. Endpoint Manager needs GET, POST, PUT, DELETE and HEAD allowed on the paths above. A policy that only permits GET and POST lets the Context connect and read groups, but endpoint updates and deletions will fail.

Note

ISE can be on-premises or cloud-hosted. Endpoint Manager only cares that it’s reachable over HTTPS from that FQDN — topology makes no difference.

For administrators and Self-Service users to reach the platform, pick one:

  • Email invitation — magic-link sign-in. The default; nothing to configure on your side.
  • SAML 2.0 single sign-on — against your own identity provider (Microsoft Entra ID, Okta, ADFS and others). SAML can drive admin sign-in, Self-Service sign-in, and optional Self-Service Enrollment so new users are provisioned on first login.

The admin and Self-Service portals are web apps and run on current versions of the major evergreen browsers — Chrome, Edge, Firefox and Safari.

  • ISE has to be reachable. Anything Endpoint Manager sends to ISE fails while ISE is unavailable, and each failed attempt shows up in the audit log.
  • You own the API user. Rotate its password or change its role whenever you need to, then re-save API Configuration so the Context picks up the change.

Next