Move from recognized endpoints to validated protection.
An endpoint can appear in SentinelOne and still fail a protection requirement. Keep the managed-device decision separate from the health conditions used to restrict access.
The published EasyNAC compatibility guide lists SentinelOne Cloud. The recorded integration demonstration provides a practical example of device recognition and firewall-based restriction.
Connect the supported endpoint-security integration and AD where your access design requires it. Default Auto Trust includes AD-joined and XDR-managed checks. Confirm the current management recognition, then validate any supported health requirements separately.
Connect the integration.
- Deploy the EasyNAC appliance or VM, configure its IP and review discovered devices.
- Prepare the SentinelOne management URL and an authorized API token. Set the query interval, test the connection and inspect the returned device information.
- Confirm the managed-device recognition used by default Auto Trust, then select any additional documented health conditions required by your access policy.
- Use a managed test endpoint and an unapproved test device to verify access, restrictions and recovery.
Recognize SentinelOne devices and protection gaps.
EasyNAC queries the SentinelOne management server using its management URL and an API token. The connector documents these condition groups:
- Agent presence, offline status and devices that have not reported within a configured number of days.
- Disabled protection, an out-of-date agent, malware infection and application-vulnerability information that is not up to date.
- Disabled Network Quarantine, Device Control, firewall or encryption, as reported by SentinelOne.
Connect protection conditions to network access.
The connector applies tags when enabled conditions match the information reported by the source. EasyNAC uses those tags in Auto Trust and role-based access decisions. Managed-device recognition and additional health requirements serve different purposes: the resulting access follows the policy in use.
A practical pilot can start with managed-device recognition and a firewall-disabled condition. Confirm the source-reported tag, the intended restriction and the management access needed to correct the condition. The connector reads the documented Network Quarantine status; this is distinct from issuing a SentinelOne quarantine action.
Checks refresh on the configured query interval; they are not an instantaneous live assessment of every endpoint. After correcting a condition, confirm the source has reported the change and EasyNAC has refreshed its information before checking restored access.
Prove the access outcome.
| Pilot case | What to demonstrate |
|---|---|
| Managed endpoint | Confirm the device is recognized through the SentinelOne Agent condition. |
| Protection gap | Use a permitted firewall or protection-status test and verify the corresponding tag and access outcome. |
| Stale or outdated agent | Verify the configured reporting-age check or the documented agent-out-of-date condition. |
| Recovery | Restore the protection requirement, refresh the source information and verify intended access returns. |
Record the source condition, EasyNAC tag, policy reason and access result in the Evaluation Kit scorecard. Agree the test and recovery procedure with your security team before changing endpoint conditions.
Keep the integration useful after deployment.
Coordinate token expiry, account/site scope and endpoint matching with the SentinelOne administrator. Retest after agent, connector or access-policy changes. Management, protection status and a security incident are different signals.
Expand only after the first network’s device matching, access and recovery behavior is understood. Review EasyNAC appliances, remote Enforcer Sensors and optional CVM when planning branches or regions.
Common questions.
Do I need a separate NAC agent for this integration?
The connector queries the existing SentinelOne management environment. The SentinelOne agent continues its normal endpoint-protection role; the integration does not add a dedicated NAC agent for these checks.
Can EasyNAC distinguish a managed device from one with protection disabled?
Yes. Agent presence and protection-disabled status are separate documented conditions. Their tags can be used by the access policy to produce different outcomes.
Sources and deployment scope.
Prepared by InfoExpress, Inc., the company behind EasyNAC. The connector checks described here were verified against the EasyNAC appliance help on 14 October 2026. Product API references provide source-platform background. Confirm availability for your connector version and source-product configuration.
Test it on your network.
Agree the requirements, connect a representative endpoint and record the actual result.