ISE Posture Prescriptive Deployment Guide

[Timothy Abbott]

• Foundation
• About Cisco Identity Services Engine (ISE)
• About This Guide
• Cisco ISE Posture capability improvements
• Getting Ready to Deploy
• Posture Workflow
• Prerequisites
• Posture/Compliance Updates
• Redirection Vs Redirection-less Flow differentiation
• Discovery Process
• Client Provisioning Policy
• Agents and How to roll them out
• Agent Types, Features & Comparison
• Deploying Agents
• Persistent Agent
• Stealth Agent
• Temporal Agent
• Agentless
• Building the Posture Policies
• Posture Settings - Lease & Grace Period
• Remediation Timer
• Posture Lease
• Periodic and Continuous Reassessment
• Periodic Reassessment (PRA)
• Continuous Reassessment (CRA)
• PRA & CRA Differences
• Building Blocks of Posture Policy
• Default Posture Policies
• Custom Posture Policies
• Operations - Running it day to day
• Best Practices
• Performance and Scale

ISE Posture Prescriptive Deployment Guide

Author: Pavan Gupta

Technical Marketing Engineer(TME) for Identity Services Engine(ISE) and Access Manager(AM), Cisco Systems, Inc.

▷ Cisco ISE Posture Playlist on YouTube

Foundation

About Cisco Identity Services Engine (ISE)

Cisco Identity Services Engine (ISE) enables and is the core of the Cisco’s Zero Trust in the Workplace solution, available on appliances, VMs, and cloud instances. Cisco ISE allows you to provide Secure Network Access for every user and device with the visibility and control required for the security of enterprise networks. ISE delivers complete visibility by identifying, classifying, and assembling the necessary contextual data about users and endpoints. It authenticates and authorizes them based on business intent (your security policy) and grants an appropriate level of network access based on the needs of their roles or functions. ISE provides network segmentation to align with the least-privilege security concept. ISE makes it simple and easy to allow authorized network communication among your endpoints while blocking everything else according to your existing identity services for users and network devices including Active Directory and mobile or enterprise device management applications. ISE uses granular segmentation in the network access edge, eliminating the need for additional security appliances, complicated infrastructure configurations, or expensive internal firewalls. ISE shares contextual user and device information bi-directionally with other Cisco security products and our Cisco Security Technology Alliance (CSTA) partners. By sharing user and device information with these additional security products and services, ISE helps them assess and correlate vulnerability and threats for automatic Rapid Threat Containment.

It is a common policy engine for controlling, endpoint access and network device administration for enterprises. ISE allows an administrator to centrally control access policies for wired, wireless, and VPN endpoints in a network. ISE builds context about the endpoints that include users and groups (Who), device type (What), access time (When), access location (Where), access type (Wired/Wireless/VPN) (How), threats, and vulnerabilities. By sharing vital contextual data with technology partner integrations and the implementation of the Cisco TrustSec® policy for software-defined segmentation, ISE transforms a network from a conduit for data into a security enforcer that accelerates the time-to-detection and time-to-resolution of network threats.

Cisco ISE Posture (Compliance), part of the Premier license, checks whether an endpoint meets an organization's security baseline — antivirus/antimalware status, disk encryption, patch level, required files/services/registry keys, and more — before granting full network access. Assessment runs through the Cisco Secure Client ISE Posture module (formerly AnyConnect), a temporal/web agent, or agentlessly via SSH/WinRM. Results (Compliant, NonCompliant, Unknown) feed ISE authorization policy, and ISE uses RADIUS CoA to move the endpoint from a restricted pre-posture state to its final access state.

About This Guide

This guide covers Cisco ISE Posture end to end, to date (ISE 3.5), organized by topic so each section stands on its own as a reference rather than a version-by-version changelog. It's written for network and security engineers who are deploying, operating, or troubleshooting ISE Posture: what it covers spans the full lifecycle, from prerequisites and workflow through agent selection and deployment, policy configuration (conditions, requirements, remediation), ongoing settings like Lease and Reassessment, and day-to-day operations, and best practices. 

Cisco ISE Posture capability improvements

Across releases 3.0–3.5, posture capability has expanded in three directions: broader OS/agent coverage (Linux, ARM64, agentless), richer condition types (osquery, USB disk encryption, script conditions), and tighter, faster compliance monitoring (Continuous Reassessment, posture grace periods). The table below is a quick-reference timeline; each item is covered with a link to its source for additional details. Some of the important milestones are described below. 

Release	Headline posture/compliance additions
3.0	Agentless Posture introduced (Windows & macOS, admin-credential SSH/WinRM checks, no client install); Agentless posture guide ↗
3.1	Posture support for Linux (Ubuntu, RHEL, SUSE); posture state synchronization/polling; script-based remediation actions; Secure Client posture support added via Patch 5. Release notes ↗
3.2	AnyConnect rebranded to Cisco Secure Client; posture condition script support (WinRM(PowerShell)/.sh); Secure Client posture extended to macOS/Linux in Patch 1; System 360 log analytics for posture/AAA syslog. Release notes ↗
3.3	Agentless Posture expanded (IPv6, more condition types, ARM64); auto-handling of unvalidated OS releases; osquery posture condition (Patch 4). Release notes ↗
3.4	USB "All External USB Drives" disk-encryption condition (Patch 4); continued osquery condition improvements;  Release notes ↗
3.5	Continuous Reassessment (near real-time posture monitoring, Patch 3); Min/Max Posture Grace Period Settings (Patch 1); IPv6 single-stack support for posture flow/feed service; "Posture Agent" renamed to "Cisco Secure Client" in reporting/exports. Release notes ↗

Getting Ready to Deploy

Posture Workflow

1. Endpoint connects (wired, wireless, or VPN over 802.1X) → NAD sends a RADIUS Access-Request to ISE.

↓

2. ISE authenticates the endpoint/user and applies a pre-posture authorization profile — either a redirect ACL pointing to the Client Provisioning portal, or (for redirectionless flows) a restrictive dACL/SGT/VLAN with no redirect where endpoint can only talk to the required services like DNS, DHCP, ISE PSNs, Remediation servers & respective protocols (if a specific posture check fails, this traffic allows endpoint to talk to the remediation server for remediation).

↓

3. Client provisioning detects OS and either launches/installs the Cisco Secure Client ISE Posture module, redirects to the Temporal/Web Agent, or (for Agentless Posture) ISE connects directly to the endpoint over SSH/WinRM using admin credentials.

↓

4. The agent (or ISE, for agentless) evaluates configured posture requirements against policy.

↓

5. Result is reported back to ISE — Compliant / NonCompliant / Unknown. endpoints that don't meet the requirements, may trigger remediation and re-evaluation. Non-Compliant endpoints can be allowed to talk to remediation servers so as to remediate to regain the compliant access. 

↓

6. ISE issues a RADIUS CoA to move the session to its final authorization profile as per the Posture Status

↓

7. Ongoing compliance is monitored for Applications Visibility (installed or Running) or Hardware visibility or via Periodic Reassessment or, from 3.5 Patch 3, Continuous Reassessment.

NOTE: As mentioned above, CoA (RFC 5176) is mandatory for changing the authorization of an endpoint, whenever there is a change in the posture Status to give appropriate privileges based on the Posture assessment during initial or on-going or PRA assessments or re-authentication while URL-Redirect enforcement is optional. 

Please refer to the below webinars which talks about the Cisco ISE Posture service from basics to advanced

Cisco ISE Posture Compliance: Part1

Cisco ISE Posture Compliance: Part2

Prerequisites

Network Devices' definition, CoA and Posture updates are necessary for you to start with posture workflow. 

• RADIUS Change of Authorization (CoA) support — required for ISE to move a session from pre-posture to post-posture authorization or whenever there is a change in the Posture Status
• URL-redirect ACL support on the NAD for the redirect-based flow; if URL-redirect is unsupported or for a user experience where the endpoint doesn't need to be redirected to a client provisioning page every time the endpoint connects to the network, plan for the redirection-less flow instead.
• dACL / SGT / VLAN enforcement capability for pre- and post-posture authorization profiles.
• RADIUS Accounting enabled on the NAD — required for Agentless Posture, since ISE locates the endpoint by IP via accounting records.

Posture/Compliance Updates

• Cisco Feed Service (Live Update) — Posture updates include a set of predefined checks, rules, and support charts for antivirus and antispyware for both Windows and MacOS operating systems, and operating systems information that are supported by Cisco. You can also update Cisco ISE offline from a file on your local system, which contains the latest archives of updates. When you deploy Cisco ISE on your network for the first time, you can download posture updates from the web. This process usually takes approximately 20 minutes. After the initial download, you can configure Cisco ISE to verify and download incremental updates to occur automatically. Cisco ISE creates default posture policies, requirements, and remediations only once during an initial posture updates. If you delete them, Cisco ISE does not create them again during subsequent manual or scheduled updates.
• Offline update packages — This offline update option allows you to download client provisioning and posture updates, when direct internet access to Cisco.com from a device using Cisco ISE is not available or is not permitted by a security policy. You can use this method to download the installation packages including compliance modules, agent installation packages and SPW for BYOD  software.cisco.com ↗ 
  

  The following Offline Installation Packages are available for download:
  win_spw-<version>-isebundle.zip—Offline SPW Installation Package for Windows
  mac-spw-<version>.zip—Offline SPW Installation Package for Mac OS X
  compliancemodule-<version>-isebundle.zip—Offline Compliance Module Installation Package
  macagent-<version>-isebundle.zip—Offline Mac Agent Installation Package
  webagent-<version>-isebundle.zip—Offline Web Agent Installation Package

• Compliance Module version — osquery conditions require Compliance Module 4.3.3394 or later 3.3 P4+; ARM64 posture requires 4.3.3583.8192 or later 3.3. Antimalware/USB conditions require a 4.x-generation module; legacy Antivirus/Antispyware/Disk Encryption/Patch Management work with 3.x. Client- and ISE-side generations must match.
• Cisco Secure Client minimum version — osquery requires 5.1.7+; Continuous Reassessment requires 5.1.17.3382+ 3.5 P3.

Redirection Vs Redirection-less Flow differentiation

For on-boarding devices for the first time, i.e. to install a Cisco Secure Client(agent) (Persistent or Stealth Agent) for the first time, you could make use of these flows 

• Redirection flow - Through URL-Redirect enforcement, end users are redirected to authenticated PSN's client provisioning portal to download and install required packages directly from ISE. This allows ISE to become the source for Client packages, Compliance Modules and/or Profiles
• Redirection-less flow - Through Software Distribution system, you can install Cisco secure client, Compliance Modules and Agent Posture Profiles

Below table describes differences between Redirection vs Redirection-less flow. 

Aspect	Redirection	Redirection-less
CoA	✅	✅
If NAD doesn’t support URL-Redirect	❌	✅
UX and/or Avoid redirection every time the endpoint connects to the networks	❌	✅
Agent Download from ISE	✅	❌
Agent Update from ISE	✅	✅
Agent Profile update ISE	✅	✅
Stage1 Discovery	✅	❌
Stage2 Discovery	❌	✅

Discovery Process

Before the Cisco Secure client posture module can report results back to Cisco ISE, it has to locate the Policy Service Node (PSN) that owns the endpoint's active session. This discovery process runs in two stages, and both stages applicable till date

Stage 1 — redirect-based probes

4 simultaneous probes: default gateway IP, an optional configured Discovery Host, enroll.cisco.com, and a probe to every primary PSN listed in the client's cached ConnectionData.xml. The first three rely on the NAD redirecting the client's HTTP request to the right PSN.

Stage 2 — "new generation" probes

Sequential, redirection-independent: the client queries the admin-configured Call Home List (PSN IP/FQDN, optional port) via /auth/ng-discovery; if that PSN doesn't own the session it triggers an MnT lookup by MAC to find the true owner.

ConnectionData.xml fallback

A locally cached, per-user list of previously successful PSNs. Cisco's own guidance: it's "effective as a backup mechanism to avoid full outages… " — don't rely on it as primary discovery.

Sources: Implement ISE Redirectionless Posture ↗ · AnyConnect ISE posture module discovery host and call home list ↗ (community, secondary)

Client Provisioning Policy

• Client Provisioning policy rules match on Operating System and, optionally, other endpoint/identity attributes, then push the matching resource: Secure Client (or legacy AnyConnect) package with an ISE Posture module profile, the Web Agent, or a native supplicant profile.
• Linux client provisioning resources (Ubuntu, RHEL, SUSE) were added 3.1 — Configure ISE 3.1 Posture with Linux ↗
• ARM64 client-provisioning policies were added 3.3 for Windows Agent, Mac Agent, Mac Temporal Agent, and Mac Agentless (Windows Temporal/Agentless are not supported on ARM64). ARM64 and BYOD provisioning policies cannot be combined.
• IPv6 support for the Client Provisioning portal itself was added 3.3, and extended to single-stack IPv6 deployments 3.5.
• Portal localization was extended over time (e.g. Ukrainian added 3.2 P3).

Irrespective of Redirection or Redirection-less flow, ISE client provisioning policy can be used to update the required installation packages/compliance module/Agent Posture Profiles, when agent's posture request is received. When there is no client provisioning policy match found for the agent request, then Cisco Secure Client Posture Scan is bypassed, leaving the endpoint in the same state (Initial or Unknown Posture State). So, Client Provisioning Policies are mandatory for you to go through Posture Scan. 

Agents and How to roll them out

Agent Types, Features & Comparison 

Persistent, Stealth, Temporal, or Agentless — Cisco ISE gives you four ways to check endpoint posture, and each trades off install footprint, remediation, and ongoing monitoring differently.

Persistent Agent

Full installed Cisco Secure Client ISE Posture module. Richest condition coverage, supports both reassessment models(manual/automatic).

Stealth Agent

Runs the Cisco Secure Client as a service in the background, No UI but with notifications support and with limited remediation support

Temporal Agent

Browser-based, minimal footprint, limited conditions coverage. Downloaded per-session, doesn't persist and provisioned through URL-Redirect

Agentless Posture

ISE-initiated SSH/WinRM check, no install, no end-user action.

 

Capability	Cisco Secure Client			AC Stealth		Temporal		Agentless
Anti-Malware Checks	✅	✅	✅	✅	✅	✅	✅	✅	✅
Firewall Installation Checks	✅	✅	❌	✅	✅	✅	✅	✅	✅
Application Inventory	✅	✅	❌	✅	✅	✅	✅	✅	✅
Hardware Inventory	✅	✅	❌	✅	✅	✅	✅	✅	✅
Process Checks	✅	✅	✅	✅	✅	✅	✅	✅	✅
Dictionary Conditions	✅	✅	✅	✅	✅	✅	✅	✅	✅
Application Checks	✅	✅	❌	✅	✅	✅	✅	✅	✅
File Checks	✅	✅	❗	✅	✅	✅	✅	❗	✅
Service Checks	✅	✅	❌	✅	✅	✅	❗	✅	❗
Disk Encryption	✅	✅	❌	✅	✅	❗	❗	❗	❗
Patch Management	✅	✅	❗	✅	✅	❗	❗	❗	❗
Registry Checks	✅	N/A	N/A	✅	N/A	✅	N/A	❗	N/A
USB Checks	✅	❌	❌	✅	❌	✅	❌	✅	❌
WSUS remediation (legacy)	✅	N/A	N/A	✅	N/A	❌	❌	❌	❌
Remediation	Auto, Manual	Partial	Partial	Part Auto	Partial	Text	Text	❌	❌
Reassessment	✅	✅	✅	✅	✅	❌	❌	❌	❌

Feature support matrix

Feature	Persistent Agent	Stealth Agent	Temporal Agent	Agentless Posture
Install required	✅ Once	✅ Once	❌ No- Per session;	❌ No
End-user interaction	Minimal, after first install	None	Each session	None
Deployment effort	Highest upfront (install/profile), lowest ongoing	Highest upfront (install/profile), lowest ongoing	Lowest	Low, but NAD accounting + admin-credential access required

When should an admin choose each agent type?

Agent type	Choose it when…	Reasoning
Persistent Agent (Secure Client)	Endpoint is corporate-managed, or you need ongoing/continuous compliance monitoring	Only agent type supporting the full condition set plus Periodic and Continuous Reassessment — the right default for anything you want monitored, not just checked once
Stealth Agent	Runs as a service, No UI, Endpoint is corporate-managed, or you need ongoing/continuous compliance monitoring
Temporal Agent	Guest/contractor/dot1x-portal flow where you don't want to install anything, but still need a real posture check	Runs an assessment without leaving a footprint; trades reassessment capability for zero install
Agentless Posture	Managed endpoints you can reach via SSH/WinRM with admin creds, where no install and no user interaction is possible	Ideal for point-in-time compliance audits; wrong choice if you need remediation or ongoing reassessment — it explicitly can't do either

Deploying Agents

Via ISE Client Provisioning

The default path: an unknown/non-compliant session is redirected to the Client Provisioning portal, which detects OS and pushes the matching Secure Client/agent package on the fly. Simple to configure, works well for guest/BYOD and unmanaged endpoints, but depends on NAD redirect (or redirectionless) support and end-user interaction (except for Agentless Posture) for newly on-boarding endpoints.

Via enterprise software distribution

For managed fleets, pre-deploying Secure Client with the ISE Posture module profile and Compliance Modules through Software Distribution systems like SCCM or UEMs or similar is the most reliable path at scale — the agent and profile are already present before the endpoint ever touches the network, so posture assessment can proceed without a Client Provisioning redirect step at all.

Persistent Agent

Persistent Agent, the recommended agent type with full condition coverage, remediation support, and both Periodic and Continuous Reassessment. It also requires a Cisco Secure Client Premier license in addition to the ISE Premier license requirement whether it is configured for stealth use or not.

Stealth Agent

Agent Stealth mode runs the Agent silently in the background as a service like "headless" configuration with the notification support. Cisco Secure Client has VPN module dependency so, note that only Posture module is not visible alone to the end user. It supports all the posture checks that were supported by persistent agent. However, since the stealth agent runs as a service in the background having no UI, it lacks the manual remediation where end users are supposed to do a manual remediation when the posture check fails. The Stealth agent requires a Secure Client Premier license in addition to an ISE Premier license.

Temporal Agent

The Temporal Agent runs a posture check without leaving anything installed behind — a good fit for guest, contractor, or employee workflows where you don't want an agent installation but need to give authorization based on the compliance of an endpoint. The disadvantage of using the temporal agent is that it is limited in the number of posture conditions it currently supports. The temporal agent only requires an ISE Premier license since it does not require persistent agent. Use it for only the most basic of posture checks.

Agentless

Agentless Posture lets ISE check compliance directly over WinRM(PowerShell) or SSH mechanism on Windows or macOS respectively, using endpoint login credentials

Building the Posture Policies

Configuring posture assessment in ISE requires several components to be taken into consideration: Conditions, Remediations, Requirements, Posture Policy, Client Provisioning and Access Policy. In the above sections, pre-requisites, client provisioning policies, authorization policies. Following section shows you the building blocks of a posture policy, default posture policies and then custom posture policies which would fit for your organizational compliance requirements. Posture conditions are the set of rules in our security policy that define a compliant endpoint. Some of the these items include the installation of a firewall, anti-virus software, anti-malware, hotfixes, disk encryption and more. Once posture conditions are defined, posture remediations (if required) can be configured. Posture remediations are the methods Cisco Secure Client (formerly AnyConnect)  will handle endpoints that are out of compliance. Some remediations can be automatically resolved through Cisco Secure Client while other might be resolved manually by the end user. Posture requirements are the actions steps taken by Secure Client when an endpoint is out of compliance. An endpoint is deemed compliant if it satisfies all the posture conditions. Once configured, posture requirements referenced for compliance enforcement. Client provisioning is the policy used to determine the version of Cisco Secure Client used as well as the compliance module that will be installed on the endpoint during the provisioning process. The compliance module is a library that the posture agent uses to determine if the endpoint is in compliance with defined posture conditions. Lastly, access policy will enable our posture policy and define what form of policy the endpoint will be subjected to if it is compliant, non-compliant or requires provisioning of Cisco Secure Client.

Posture Settings - Lease & Grace Period

Global configuration, under Work Centers > Posture > Settings (or Administration > System > Settings > Posture).

• General Settings — remediation timer, network transition delay, default posture status for unclassified endpoints, and AUP enforcement options.

Remediation Timer

You can configure the timer for client remediation with a specified time. When clients fail to satisfy configured posture policies during an initial assessment or during periodic reassessment, the agent waits for the clients to remediate within the time configured in the remediation timer. If the client fails to remediate within this specified time, then the agent sends a report to the posture run-time services after which the clients are moved to the noncompliance state. This remediation timer can be set at a global level or through Posture Profile. 

 

Posture Lease

Configured at Work Centers > Posture > Settings > Posture Lease: check "Perform posture assessment every N Day(s)" (1–365 days). Once an endpoint becomes Compliant, ISE stores an expiry timestamp as an endpoint attribute in the shared database. On the endpoint's next new session within the lease window, ISE performs a "fast reconnect" — it skips the full posture check entirely and marks the session Compliant directly from the cached expiry, regardless of which PSN authenticates it (the attribute is replicated to all nodes independent of Light/RADIUS Session Directory). When the lease expires, ISE does not proactively force a recheck — the endpoint simply runs posture again the next time it re-authenticates.

Security trade-off: while the lease is active, ISE does not verify the endpoint is still actually compliant — a device that goes non-compliant mid-lease keeps its Compliant session status. Cisco's own guidance: "It is recommended to use Posture Reassessment along with the Posture Lease to minimize this risk." Pair Posture Lease with Periodic or Continuous Reassessment rather than using it alone.

 

Cache Last Known Posture Compliant Status & Per-policy Grace Period

Grace Period 

Cisco ISE provides an option to configure the grace time for the devices that are noncompliant. If a device is found to be noncompliant, Cisco ISE looks for the previously known good state in the posture assessment result cache and provides grace time for the device accordingly. The device is granted access to the network during the grace period. You can configure the grace time period in minutes, hours, or days (up to a maximum of 90 days).

Cache Last Known Posture Compliant Status

A separate, independent setting (same Posture Lease settings page): Cache Last Known Posture Compliant Status, with a configurable "Last Known Posture Compliant State" duration (max 30 days / 720 hours / 43200 minutes). Unlike the lease, this doesn't skip the check — it cushions the outcome: if an endpoint that was previously Compliant fails a subsequent posture check while still inside this window, ISE holds the session as Compliant for the Grace Period configured on the matched posture policy (a per-policy value, in minutes) — the client shows "In grace period," and the RADIUS live log still records the session as Compliant even though the underlying check failed. Once the grace period expires without the endpoint passing, the session flips to NonCompliant. If the caching window itself has already expired when a check fails, the grace period is not honored at all — the session goes straight to NonCompliant.

3.5 Patch 1 — Posture Grace Period Settings 3.5 P1: You can define Posture Grace Period (minutes/hours/days, up to 90 days) against each posture policy. This settings would allow the administrator to provide compliance grace period for the endpoints which are not compliant against those configured policies. For eg., when your organization is looking for an up to date patches to be installed on the endpoint, when the endpoint is not compliant against this policy, instead of enforcing non-compliant, this posture grace period allow you to give compliant access for a configurable grace period time, beyond which the endpoint needs to be compliant against the policy. There are instances where the endpoint is not compliant against multiple policies where different grace time periods are configured. Starting ISE 3.5 P1, administrator can select maximum or minimum of grace periods defined at different posture policies which are not met.

Periodic and Continuous Reassessment

Two models for keeping a session's compliance status current after the initial check. 

Periodic Reassessment (PRA)

A periodic interval is configured, and at each interval the persistent agent silently re-runs the posture check against the endpoint — without redirecting the user or repeating the full Client Provisioning flow — and updates the session's compliance status if it has changed. PRA only applies to endpoints already successfully postured as compliant, is configured at Work Centers > Posture > Settings > Reassessment Configurations, and is not available to Agentless Posture or Temporal Agent sessions. It is recommended to have Posture Lease along with PRA, since a long lease with no PRA leaves compliance status unverified for the full lease duration. When endpoint fails at a specific compliance check, you have enforcement options to Remediate/Terminate/Logoff. Choose the action to enforce on an endpoint if an endpoint was fully compliant in an earlier check but is not fully compliant upon reassessment:
Continue: The endpoint continues to have network access.
Logoff: The endpoint is considered non-compliant and loses network access.
Remediate: The appropriate remediation action is taken on the endpoint.

Continuous Reassessment (CRA)

Introduced in ISE 3.5 Patch 3: Cisco Secure Client monitors endpoint health/posture in near real time rather than waiting for the next PRA interval — certain events (e.g. an AV service stopping, a USB drive being inserted) are detected immediately, with other attributes polled roughly every 10 minutes. Requires Secure Client 5.1.17.3382 or later. This meaningfully shortens the exposure window between an endpoint drifting out of compliance and ISE acting on it, compared to a fixed PRA interval. However, there is no enforcement (No CoA) currently supported even if the endpoint becomes non-compliant during CRA. Since no CoA is enforced during CRA for posturestatus changes, when endpoint re-authenticates against network then the endpoint is enforced with latest Posture Status (Compliance or Non Compliance). Suggest you to use both CRA and PRA for the enforcement purposes if the reauthentication is not handy for CRA. 

Note these points when using the continuous reassessment feature:

• To enable continuous reassessment for an endpoint, use a supported version of Cisco Secure Client.

  Cisco Secure Client 5.1.17.3382 and later versions support continuous reassessment.

• Continuous reassessment is supported only for Full agents. Agentless and Temporal agents are not supported.

• If you configure manual remediation for a continuous reassessment policy, the posture agent converts it to automatic remediation during the posture flow. The posture agent ignores file and message text-only remediation.

• If you disable the reassessment option, the posture status of endpoints is verified only when a new network connection is established.

If you have enabled both the Continuous Reassessment and Periodic Reassessment options on the Reassessment Configurations page, you can select the reassessment type for a specific set of endpoints by using the Preferred Reassessment Type option while creating the agent posture profile. Ensure that your Cisco Secure Client release supports continuous reassessment configuration.

If you want to migrate from periodic reassessment to continuous reassessment, follow these steps:

1. Enable both the Continuous Reassessment and Periodic Reassessment options on the Reassessment Configurations page (Administration > System > Settings > Posture > Reassessments).

2. Create an agent posture profile and select the Continuous option from the Preferred Reassessment Type drop-down list.

3. Assign this agent posture profile to the group of endpoints that you want to transition to continuous reassessment.

You can switch to continuous reassessment for all the endpoints after all the posture agents are upgraded to supported versions.

You can view the posture reassessment type and reassessment report type details in the Posture Assessment by Endpoint report (Operations > Reports > Endpoints and Users) under the columns Report Type (initial, continuous reassessment, or periodic reassessment) and Report Subtype (full or differential). The Report Subtype column is applicable only for continuous reassessment. The posture agent sends a differential report if posture changes occur and sends a full report at each keepalive interval. You can view the initial posture assessment status, agent continuous reassessment status, and latest posture status (initial or reassessment) on the Context Visibility > Endpoints > Compliance page.

Below table gives you what posture checks or conditions supported by Continuous Reassessment

Posture condition	Windows	macOS	Linux
Firewall	Polling	Polling	Not supported
USB	Event based	Not supported	Not supported
File	Event based	Event based	Event based
Script	Polling	Polling	Polling
Registry	Event based	Not supported	Not supported
Service	Event based	Polling	Not supported
Disk encryption	Polling	Polling	Not supported
Patch management	Polling	Polling	Polling
Antimalware	Polling	Polling	Polling
Application	Polling	Polling	Not supported
Process	Event based	Polling	Polling
Osquery	Not supported	Not supported	Polling

 

PRA & CRA Differences

Aspect	Periodic Reassessment (PRA)	Continuous Reassessment (CRA)
Introduced / availability	Long-standing ISE feature	New in ISE 3.5 Patch 3
Detection model	Re-runs the full posture check at a fixed, configured interval	Event-based + polling — certain events (e.g. AV service stopping, USB insertion) detected immediately; other attributes polled ~every 10 min
Trigger	Timer / scheduled interval	Endpoint health/posture events, plus background polling
Exposure window	Up to the full PRA interval before drift is noticed	Near real-time — meaningfully shorter drift-to-detection window
Agent support	Full agents only (persistent + Stealth); not Temporal, not Agentless	Full agents only; not Temporal, not Agentless
Minimum client version	Standard Secure Client / AnyConnect	Cisco Secure Client 5.1.17.3382+
Applies to	Endpoints already postured Compliant	Endpoints already postured Compliant
Configuration	Work Centers > Posture > Settings > Reassessment Configurations (per identity group)	Enabled via posture profile/policy with a supported Secure Client version
Enforcement / CoA	Yes — on status change ISE can act, with per-policy options Continue / Logoff / Remediate, backed by CoA	No enforcement / No CoA currently — even if the endpoint goes non-compliant during CRA, ISE does not issue a CoA. Monitoring/visibility only
Remediation behavior	Per the chosen enforcement action (Continue / Logoff / Remediate)	Manual remediation is auto-converted to automatic; File and Message-Text-Only remediations are ignored
OS / condition coverage	Broad (standard posture conditions)	Varies by condition & OS — event-based, polling, or not supported (refer above table)
Primary use case	Scheduled re-verification of compliance	Shrink the time between an endpoint drifting out of compliance and ISE seeing it

Building Blocks of Posture Policy

Posture conditions are the set of rules in our security policy that define a compliant endpoint. Some of the these items include the installation of a firewall, anti-virus software, anti-malware, hotfixes, disk encryption and more. Once posture conditions are defined, posture remediations (if required) can be configured. Posture remediations are the methods Cisco Secure Client (formerly AnyConnect)  will handle endpoints that are out of compliance. Some remediations can be automatically resolved through Cisco Secure Client while other might be resolved manually by the end user. Posture requirements are the immediate actions steps taken by Secure Client when an endpoint is out of compliance. An endpoint is deemed compliant if it satisfies all the posture conditions. Once configured, posture requirements can then be reference by posture policy for compliance enforcement.

Below table would give you compatibility of each Posture checks supported on the respective OS across different agent types articulated above.

Condition	Check variants	Win	macOS	Linux	SC	Stealth	Temporal	Agentless	Recommended Remediation action (auto/manual)
File	Win: FileDate, FileExistence, FileVersion, CRC32, SHA-256 · macOS: +PropertyList, −FileVersion · Linux: FileDate, FileExistence, CRC32, SHA-256	✅	✅	✅	✅	✅	✅	⚠️¹	File Remediation (manual); Link; Script Remediation;
Registry	RegistryValue / Default; Number, String, Version	✅	❌	❌	✅	✅	✅	⚠️²	Script Remediation
Service	Win: Running/Not Running · macOS: Daemon / User Agent / Daemon-or-User-Agent	✅	✅	❌	✅	✅	⚠️³	⚠️³	Script Remediation;Launch Program (start/stop service); Message(manual)
Application	Process (Running/Not Running) or Application (Installed/Running); Provision Everything/Name/Category	✅	✅	⚠️⁴	✅	✅	✅	✅	Script Remediation/Launch Program / message(manual)
Anti-Malware	Installation; Definition (version / days-older-than / latest file / current date)	✅	✅	✅	✅	✅	✅	✅	Script Remediation; Anti-Malware Remediation (auto); Message(manual)
Anti-Virus (legacy)	Installation; Definition	✅	✅	❌	✅	✅	✅	❌⁶	Script Remediation/AV Remediation (auto);Message(manual)
Anti-Spyware (legacy)	Installation; Definition	✅	✅	❌	✅	✅	✅	❌⁶	Script Remediation;AS Remediation (auto);Message(manual)
Disk Encryption	Location: Specific / System / All Internal / All External USB⁷; State: Fully / Partially / Pending	✅	✅	❌	✅	✅	✅	⚠️⁹	None automatic — message/link only
Patch Management	Installation; Enabled; Up To Date (Critical Only → All)	✅	✅	✅	✅	✅	⚠️¹⁰	⚠️¹⁰	Patch Mgmt / WSUS / Windows Update Remediation (auto, severity-based);Script Remediation;
Firewall	Enabled (is firewall running)	✅	✅	❌	✅	✅	✅	✅	FW Remediation
USB	Presence of USB mass-storage device	✅	❌	❌	✅	✅	✅	❌	USB Remediation (auto — block)
Hardware Attributes	Collects endpoint HW attributes (visibility)	✅	✅	❌	✅	✅	✅	❌	None (visibility only)
Script	Win: PowerShell/.ps1 · macOS & Linux: shell/.sh; exit 0 = pass	✅	✅	✅	✅	✅	⚠️¹¹	⚠️¹¹	Script Remediation (auto) / message
osquery	Query-based checks over osquery tables	❌	❌	✅	✅	✅	❌	❌	None dedicated (message)
External DataSource	Match endpoint UDID vs datasource (AD only)¹²	—¹²	—¹²	—¹²	✅	✅	❌	✅	None

Below table talk about remediation actions supported by OS

Remediation action	What it does	Win	macOS	Linux	Auto/Manual	SC	Stealth	Temporal	Agentless
Anti-Malware / AV / AS	Triggers the security product to update defs / enable	✅	✅	❌	Automatic	✅	✅	❌	❌
Patch Management	Invokes patch product to install missing patches	✅	✅	❌	Automatic	✅	✅	❌	❌
Windows Update / WSUS	Runs Windows/WSUS updates (severity-based)	✅	❌	❌	Automatic	✅	✅	❌	❌
USB	Blocks/handles USB mass-storage device	✅	❌	❌	Automatic	✅	✅	❌	❌
Launch Program	Launches a program/command to remediate	✅	❌	❌	Automatic	✅	✅	❌	❌
Script	Runs a remediation script	✅	✅	✅	Automatic	✅	✅	❌	❌
File	Client downloads required file version	✅	✅	❌	Manual	✅	❌¹³	❌	❌
Link	Opens a browser URL for self-remediation	✅	✅	❌	Manual	✅	❌¹³	❌	❌
Message Text Only	Notifies user / Help-desk instructions	✅	✅	✅	Manual	✅	❌¹³	✅¹⁴	❌

The Notes

Notes (¹–¹² unchanged from before; ¹³–¹⁷ are new for remediation):

1. Agentless File: all checks except conditions using USER_DESKTOP / USER_PROFILE paths. This is because the Agentless runs in the user context rather than system context
2. Agentless Registry: all except conditions using HKCU/HCSK root key.
3. Temporal & Agentless don't support the macOS System Daemon / Daemon-or-User-Agent service checks.
4. Linux Application: Process check only.
5. Compound conditions can be built using dictionary conditions. 
6. Agentless doesn't list legacy AV/AS separately — use Anti-Malware (4.x) instead.
7. USB Drive condition and other checks are evaluated immediately upon USB drive insertion. 
8. Temporal doesn't support the Disk Encryption "Encryption" check.
9. Agentless Disk Encryption: all except the encryption location-based check.
10. Temporal & Agentless support Patch Management Installation check only (no Enabled / Up To Date).
11. Script runs as logged-in-user / Administrator/root
12. External DataSource association like UDID-to-AD are outside of ISE.
13. Stealth disables all Manual remediation types ("the Manual Remediation Type is disabled (grayed out) because this action requires client-side interaction") — so File, Link, and Message-Text remediations aren't usable in Stealth. The remediations offered in Stealth are Anti-Malware, Launch Program, Patch Management, USB, WSUS, and Windows Update.
14. Temporal supports only message-text remediation — "the temporal agent does not support custom remediation. The default remediation supports only message text."
15. Agentless supports no remediation (Remediation, Grace Period, PRA, and AUP are all listed as unsupported for Agentless).
16. Continuous Reassessment auto-converts manual remediation to automatic, and CRA ignores File and Message-Text-Only remediations entirely.

Global Remediation Timer: default 4 min, range 1–300 min (set globally or per Agent Posture Profile); default posture policies/requirements/remediations are created only at the first posture update.

Default Posture Policies

What ISE ships with out of the box, and what has to be built.

• ISE does ship with pre-built (but disabled), posture policies covering generic(any) AV/AM/AS/Firewall/USB/ products or condition sets. There are pre-built policy to monitor applications (running and installed) and hardware attributes of an endpoint.
• Endpoints with no matching posture policy, or agents that haven't reported yet, default to Unknown status — decide explicitly in authorization policy whether Unknown is treated like NonCompliant (safer default) or given provisional access.

Below video shows you how you could use default posture policies for compliance of an endpoint in your organization and then start customizing it. 

Custom Posture Policies

Now that you understand the workflow, agents, posture policies and settings, you can now configure any compliance checks that needs to be met by your organizational policy. Below video shows an example compliance policies

 

Operations - Running it day to day

How admins observe and troubleshoot posture in day-to-day operation.

Live Logs

Operations > RADIUS > Live Logs. First-stop triage — shows PostureStatus transitions per session, filterable by identity/MAC/session ID. ISE 3.3+ adds per-step latency detail useful for isolating slow posture steps.

Live Sessions

Operations > RADIUS > Live Sessions. Shows active sessions and current posture state (Unknown/Pending → Compliant/NonCompliant); supports manual CoA (reauthenticate/disconnect) to force a re-check; per-endpoint lease expiry visible via Context Visibility > Endpoints.

Reports

Operations > Reports or Posture Workcenter > Reports, Key posture reports: Posture Assessment by Endpoint (drill-down per session/requirement), Posture Assessment by Condition, plus RADIUS Accounting/RADIUS Authentications for correlating auth events to posture outcomes. 

Agentless Posture - explicitly for agentless flows

Posture Assessment by Conditions - a report based on the passed/failed conditions; useful when an administrator wanted to understand the conditions failed at an org level.

Posture osquery condition - A report for osquery checks

Log Analytics / System 360

Operations > System 360, introduced 3.2 (Grafana/Prometheus dashboards) with Log Analytics (Kibana/Elasticsearch). Runs on MnT nodes only, ~7-day retention, adds cross-node correlation Live Logs/Reports don't provide.

Data Connect

A way for an administrator to connect to ISE database in Read-only mode and allows administrators to query based on SQL queries for any external reporting purposes, supported from 3.2 (Oracle TCPS, port 2484, requires Essentials license). Posture-relevant views: POSTURE_ASSESSMENT_BY_ENDPOINT, POSTURE_ASSESSMENT_BY_CONDITION, POSTURE_GRACE_PERIOD, POSTURE_SCRIPT_CONDITION, POSTURE_SCRIPT_REMEDIATION — good for BI-tool dashboards over posture trends that Reports can't easily show.

Sources: Troubleshoot ISE Session Management and Posture ↗ · ISE 3.3 Admin Guide — Maintain and Monitor ↗ · Data Connect Database Views ↗

Best Practices

• Default to the redirect flow recommendation; reserve redirectionless/Call Home List configuration for NADs that genuinely can't support redirection, and use Network Device Groups to manage a hybrid environment cleanly.
• RADIUS Change of Authorization (CoA) support — required for ISE to move a session from pre-posture to post-posture authorization or whenever there is a change in the Posture Status
• URL-redirect ACL support on the NAD for the redirect-based flow; if URL-redirect is unsupported or for a user experience where the endpoint doesn't need to be redirected to a client provisioning page every time the endpoint connects to the network, plan for the redirection-less flow instead.
• dACL / SGT / VLAN enforcement capability for pre- and post-posture authorization profiles.
• RADIUS Accounting enabled on the NAD — required for Agentless Posture, since ISE locates the endpoint by IP via accounting records.
• Pair Posture Lease with Periodic or Continuous Reassessment. Lease alone leaves compliance status unverified for the entire lease window 
• Allow users to Rescan - Use Enable Rescan Button, applicable to Cisco Secure Client persistent agent and configurable under Posture Profile for allowing users to rescan the policy whenever required
• Avail Posture State Synchronization Interval - This setting can be governed through ISE Posture Profile in the agent configuration. Supported range is from 0 - 300 seconds, '0' disables periodic probing. If enabled, agent probes Cisco ISE PSNs periodically to retrieve an endpoint's latest posture status. This probe is useful if an endpoint's status changes from Compliant to Pending without triggering a network change event in the endpoint
• Keep reauthentication timers and load-balancer persistence aligned so reauthenticated sessions land back on the same PSN; where wired switches run MAB/dot1x in a specific order, set cisco-av-pair: termination-action-modifier=1 on the compliant authorization profile so reauthentication doesn't spuriously terminate the session.
• Treat Unknown status conservatively in authorization policy — default to limited/no access rather than assuming Unknown means benign.
• Use Agentless Posture as a point-in-time audit, not a substitute for continuous monitoring — it can't do remediation or reassessment of any kind.
• Pre-deploy the agent for managed fleets (software distribution or headend) and reserve portal-driven Client Provisioning for guest/BYOD/unmanaged endpoints.
• Continuous Reassessment on a representative subset before fleet-wide rollout — it requires Secure Client 5.1.17.3382+ and changes several Data Connect field behaviors.
• Test custom scripts and osquery conditions across representative OS builds before production rollout, especially given the "unvalidated OS" auto-matching behavior introduced in 3.3.

Source for the reauthentication/session-ID and load-balancer guidance: Deploy ISE Posture — Cisco best-practices TechNote ↗

Performance and Scale 

Please refer to https://cs.co/ise-scale for the performance and scale for scenario wise or posture TPS.