The ITSM (IT Service Management) integration in Segura® Platform is a powerful feature that allows for a direct connection between privileged access management and IT service management systems. By linking access requests to valid ITSM tickets, organizations ensure that all privileged activities are properly authorized, time-bounded, documented, and auditable.
Supported ITSM solutions
Segura® Platform currently supports integration with the following ITSM solutions:
| Platform | Integration Type | Time Window Enforcement | Real-Time Revalidation |
|---|---|---|---|
| ServiceNow | Native REST (Table API) | Yes | Yes |
| Jira Service Management | Native REST | Yes | Yes |
| BMC Helix ITSM / Remedy | Native REST | Yes | Yes |
| Cherwell | Native REST | Yes | Yes |
| Freshservice | Native REST | Yes | Yes |
| Zendesk | Native REST | Yes | Yes |
| Freshdesk | Native REST | Yes | Yes |
| CA Service Desk Manager | Native REST | Yes | Yes |
| GLPi ITSM | Native REST | Yes | Yes |
| Zoho Desk | Native REST | Yes | Yes |
| Ivanti Neurons for ITSM | Native REST | Yes | Yes |
| Generic REST / Webhook | Configurable REST or webhook | Yes | Yes — configurable polling |
The Generic REST / Webhook integration supports any ITSM tool that exposes a REST API or webhook endpoint, including proprietary and on-premises solutions not listed above.
What is the governance code?
The governance code is a central element in ITSM integration. It’s a unique identifier that:
- Can be inserted by users in the justification and authorization form when requesting privileged access.
- Functions as a connection between the access request in Segura® Platform and the corresponding ticket in the ITSM system.
- Is validated in real time against the ITSM platform before access is granted.
- Can be made mandatory for all privileged access requests via Access Policy configuration.
How does the integration work?
The following describes the end-to-end workflow when a user requests privileged access using an ITSM governance code.
Main components
- Administrator user (Admin): initiates the access request.
- Request form: interface for entering the governance code and justification.
- Segura® Platform: validates the code, ticket status, and time window.
- ITSM solution: the external system where the ticket is managed.
Request and verification process
- The user initiates an access request and enters the governance code in the justification form.
- Segura® Platform sends the governance code to the ITSM system for validation.
- The ITSM system confirms whether the ticket exists, is in an active/approved state, and whether the current time falls within the ticket's allowable time window.
- If all validations pass, Segura® Platform grants access and starts the privileged session or credential checkout.
- Segura® Platform continuously monitors the ticket status and time window throughout the session.
- When the time window closes or the ticket status changes, Segura® Platform enforces the appropriate response — warning, session pause, or forced termination.
Ticket status visibility is available for all supported platforms. For Jira Service Management, status display may vary depending on the project workflow configuration.
Enforcement of Allowable Time Windows for Privileged Access
Segura® Platform enforces strict time-based controls for all privileged access requests integrated with ITSM solutions. When an ITSM ticket is used to request privileged activity, Segura® Platform automatically reads the ticket's scheduled start and end fields and restricts all privileged sessions and credential checkouts to that approved window.
This enforcement applies to all supported ITSM platforms and covers the following behaviors:
-
Pre-window blocking: access is denied before the ticket's scheduled start time.
-
Post-window termination: active sessions are automatically terminated when the ticket's end time is reached.
-
Real-time revalidation: ticket status is continuously monitored during the session.
-
Full audit logging: all time-window events are immutably logged for compliance.
Pre-Window Blocking
Access attempts made before the ticket's scheduled start time are denied, even if the ticket status is approved. The user receives the following message:
The referenced ITSM ticket has not reached its scheduled start time. Access will be available from [scheduled_start]. Please try again after that time.
The denial event is logged with the governance code, the attempted access time, and the ticket's scheduled start time.
Post-Window Session Termination
When the ticket's end time is reached, Segura® Platform terminates the active session automatically. The termination sequence is:
-
Warning notification: the user receives an in-session alert before the end time. The warning interval is configurable (default: 10 minutes before end time; options: 5, 10, or 15 minutes).
-
Grace period: an optional grace period allows the user to wrap up work safely. Configurable from 0 to 15 minutes (default: 5 minutes). Setting to 0 enforces immediate termination at end time.
-
Forced termination: the session is closed and the credential is automatically checked back in.
-
Audit record: the termination event is logged with timestamp, ticket ID, scheduled end time, actual end time, and termination reason.
Unsaved work within the remote session will be lost upon forced termination. Users should save all work before the grace period expires.
Real-Time Ticket Revalidation
Segura® Platform continuously polls the ITSM ticket status throughout an active session. The polling interval is configurable per integration (default: 60 seconds). For environments requiring near real-time enforcement, webhook-based notification can be enabled to trigger immediate revalidation on any ticket status change.
The following table describes platform responses to each ticket event:
| Ticket Event | Segura® Response | User Notification |
|---|---|---|
| Ticket cancelled | Session terminated immediately | Yes — reason: ticket cancelled |
| Ticket resolved / closed | Session terminated immediately | Yes — reason: ticket closed |
| Ticket placed on hold | Session paused, access suspended | Yes — reason: ticket on hold |
| Ticket reopened / resumed | Access restored automatically | Yes — session can resume |
| Ticket end time reached | Session terminated after grace period | Yes — warning before termination |
| Ticket start time not yet reached | Access denied | Yes — shows scheduled start time |
Configuration
Time-bound access control is configured per ITSM integration. To enable and configure it:
-
Navigate to Settings > System Parameters > Integration with ITSM.
-
Select the ITSM platform to configure.
-
Enable the option: Enforce time window from ticket fields.
-
Map the start and end fields from the ITSM ticket to Segura®'s time window parameters (see Section 5.5).
-
Configure the warning notification time (default: 10 minutes before end time).
-
Configure the grace period (default: 5 minutes; set to 0 for immediate termination at end time).
-
Set the polling interval for real-time revalidation (default: 60 seconds).
-
Optionally enable webhook-based revalidation for near real-time enforcement.
-
Save and test the integration using a test ticket.
Only one ITSM platform can be set as the primary integration per Segura® instance. Generic REST can be used as a secondary integration for additional platforms.
Field Mapping Reference
The following table shows the default field mapping for each supported platform. Fields can be remapped under the integration configuration if your ITSM instance uses custom field names.
| Platform | Start Field | End Field | Status Field | Active Status Value |
|---|---|---|---|---|
| ServiceNow | scheduled_start | scheduled_end | state | 2 (In Progress) |
| Jira Service Management | customfield_planned_start | customfield_planned_end | status.name | In Progress |
| BMC Helix / Remedy | Scheduled Start Date | Scheduled End Date | Status | In Progress / Assigned |
| Cherwell | ScheduledStart | ScheduledEnd | Status | In Progress |
| Freshservice | planned_start_date | planned_end_date | status | 2 (In Progress) |
| Zendesk | custom_field_start | custom_field_end | status | open / pending |
| Freshdesk | custom_date_start | custom_date_end | status | 2 (Open) |
| CA Service Desk Manager | scheduled_start_date | scheduled_end_date | status | In Progress |
| GLPi ITSM | begin_date | end_date | status | 2 (Processing) |
| Zoho Desk | cf_planned_start | cf_planned_end | status | Open / In Progress |
| Ivanti Neurons | PlannedStart | PlannedEnd | Status | In Progress |
| Generic REST | Configurable | Configurable | Configurable | Configurable |
For platforms using custom fields (e.g., Zendesk, Freshdesk, Zoho), the field names above are examples. Actual field names depend on your ITSM instance configuration. Use the Generic REST field mapping to specify the exact field paths from your ITSM API response.
Audit Trail and Compliance
All time-bound access events are immutably logged in Segura® Platform and exportable for compliance reporting. Each audit record includes:
| Field | Description |
|---|---|
| Ticket ID | Governance code entered by the user |
| ITSM Platform | Platform where the ticket was validated |
| Scheduled Start Time | Start time read from the ITSM ticket field |
| Scheduled End Time | End time read from the ITSM ticket field |
| Actual Session Start | Timestamp when the session was effectively initiated |
| Actual Session End | Timestamp when the session was terminated |
| Ticket Status at Session Start | Status value at the moment access was granted |
| Ticket Status per Poll | Status value recorded at each polling interval during the session |
| Termination Reason | Natural end / forced termination / ticket cancelled / ticket closed / ticket on hold / manual termination |
| User | User who initiated the access request |
| Credential | Credential accessed during the session |
| Device | Target device of the privileged session |
| Session Recording Reference | Link to the session recording, if applicable |
| Pre-window Denial Events | Logged access attempts before the ticket start time |
| Post-window Termination Events | Logged forced terminations at or after the ticket end time |
Audit reports for ITSM-scoped sessions are available under: Reports > Privileged Sessions > Sessions by ITSM Ticket.
Time-bound access correlated to ITSM tickets supports change management audit requirements under SOX, ISO 27001, PCI-DSS, and ITIL frameworks. Auditors can verify that privileged access occurred only within the approved change window, with full session activity recorded and correlated to the originating ticket.
How to Make the Governance Code Mandatory
You can require the governance code for all privileged access requests associated with a given access policy, ensuring no session or credential checkout proceeds without a valid ITSM ticket reference.
-
On Segura® Platform, go to PAM Core > Access Control > Access Policies.
-
Add a new policy or edit an existing one.
-
In the Approvers tab, enable the field: Governance code required when justifying?
-
Save the policy.
Once enabled, users requesting access under this policy must provide a valid governance code. The code is validated against the ITSM platform before access is granted.
Benefits of ITSM Integration
| Benefit | Description |
|---|---|
| Enhanced security | Ensures all privileged access is associated with an approved, time-bounded ITSM ticket. |
| Time-bound enforcement | Automatically restricts and terminates sessions outside the approved change window. |
| Real-time risk reduction | Continuous ticket revalidation revokes access immediately if a ticket is cancelled or closed mid-session. |
| Improved auditing | Every access event is correlated to the originating ticket, time window, and status — providing a complete change management audit trail. |
| Compliance | Supports SOX, ISO 27001, PCI-DSS, and ITIL audit requirements out of the box. |
| Operational efficiency | Automates authorization verification and session lifecycle management, reducing manual intervention. |