ServiceNow Integration Hub: Security and Access Design

Role-Based Access Control for Integration Hub

Integration Hub includes several key roles: Integration Hub Administrator (manages all integrations and credentials), Integration Hub Developer (creates and tests integrations), Integration Hub Operator (executes integrations, monitors execution), Integration Hub Viewer (monitors execution results but cannot change configurations). Align roles with job responsibilities: developers need configuration authority, operators need execution authority, administrators need authority over all settings.

Additional roles you may need: Integration Auditor (views audit logs and tracks changes to integrations), Credential Manager (manages integration credentials separately from integration configuration), and Data Governance (approves integrations involving sensitive data movement).

Least Privilege Principle

Least privilege means each role has only the minimum permissions needed for their job. A developer needs permission to create and test integrations, but not to modify production integrations. An operator needs permission to execute integrations and view results, but not to change integration logic. Implement least privilege by: assigning specific role permissions, not broad administrator roles; separating duties (see below); and regularly reviewing and adjusting permissions based on actual job requirements.

Review permissions periodically. As people change roles or jobs change, permissions should adjust. People often retain permissions from previous roles, creating excess permission creep.

Segregation of Duties

Critical separations of duty for Integration Hub: separate the person who creates integrations (developer) from the person who approves them for production (administrator). Separate the person who manages credentials from the person who uses them in integrations. Separate the person who configures monitoring and alerts from the person who responds to incidents. These separations prevent a single person from making an unauthorized change and covering it up.

Segregation of duties also prevents innocent mistakes: if one person creates the integration and another person approves it, the approver catches mistakes the creator did not see. This improves quality and reduces incidents.

Credential Management and Secrets

Integration Hub uses credentials (usernames, passwords, API keys, certificates) to authenticate to external systems. Credentials must be protected: never store credentials in plain text, never log credentials, never share credentials between integrations. Use ServiceNow credential storage or external secrets management (HashiCorp Vault, AWS Secrets Manager).

Access to credentials should be restricted: only the integration that needs the credential should have access, and only trusted administrators should manage credentials. Rotate credentials on the schedule your security policy sets, and rotate all credentials when a compromise occurs. Audit access to credentials: who accessed which credentials when.

Audit Evidence and Trails

Integration Hub should maintain audit logs of: who created, modified, or deleted an integration; when integrations are executed and their status (success or failure); what data flows through integrations (log data volume and types, not data content for privacy); changes to integration configurations; access to integration credentials; and errors or failures during execution.

Audit logs should be: tamper-proof (stored in a way that changes cannot be hidden), retained for as long as your regulations require, timestamped accurately, and reviewed regularly. Set up alerts for suspicious activity: configuration changes at odd hours, repeated execution failures, or access to credentials outside normal patterns.

Change Control for Integrations

Integrations that move data between critical systems need change control: no production integration should change without approval from both the creator and a reviewer. Implementation: Development and Production environments separated (test integrations in development, promote to production after testing and approval). Approval workflow requires designated approver (integration administrator or data governance team) to review changes before they go to production.

Change log documents what changed, why it changed, who approved it, and when it went to production. This documentation supports audit and troubleshooting.

Data Protection and Sensitive Data Handling

Integrations often move sensitive data (customer records, financial information, personal information). Protect sensitive data by: encrypting data in transit (TLS/HTTPS), encrypting data at rest if stored, masking sensitive data in logs, restricting access to integrations that handle sensitive data, and auditing access to sensitive data integrations.

Do not log sensitive data values. Log data volume and types, not content. For example, log “integration moved 1,000 customer records” but not the customer names or data.

Classify integrations by data sensitivity: low-sensitivity integrations (system status data) have fewer restrictions, high-sensitivity integrations (customer PII, financial data) have strict restrictions. Apply controls proportional to sensitivity.

Network and Firewall Considerations

Integration Hub uses outbound connections to external systems. Configure firewalls and network policies to: allow Integration Hub to reach necessary external systems, log all outbound connections, alert on unusual connection patterns, and block suspicious external systems. Document which external systems integrations connect to so security team can monitor for threats.

Regular Review and Compliance

Review integration security periodically: audit logs for suspicious activity, access rights alignment with current job roles, credential rotation status, and changes to sensitive data integrations. Adjust controls as integration scope expands or new regulations apply.

Giving each integration account only the access its flow needs

The access question for an integration is rarely “who can log in”. It is “which identity does the flow run as, what can that identity read and write, and who can change either of those things without anyone noticing”. In many platforms the answer to the last question is the weakest point. A service account created during a build gets a broad role so the flow works on the first try, the role is never reduced, and the account is then used by three other flows that nobody mentions in the design. This section is for the platform administrator who inherits that situation and needs to rebuild the access model without breaking the flows that depend on it.

Start by listing every identity that calls out of ServiceNow or into it. For each one, record the flow or inbound endpoint that uses it, the tables and fields it touches, and whether it writes. This inventory is often the first time the team sees how many flows share one account, and that count is the reason the rebuild is worth doing.

Access patterns by direction and risk

An ordered procedure for reducing an over-broad account

1. Run the flows that use the account in a non-production copy with the account’s roles temporarily reduced, and note every operation that fails.
2. Add back only the access each failure proves is needed, and record the table and operation that required it.
3. Give each flow its own account where the inventory shows a shared one, and move the credential reference to the new account in a single change window.
4. Remove the old account’s roles only after a full cycle of the flows that use it has passed without an access error.
5. Set a review date for the account’s access, and attach the date to the register entry rather than to a person’s calendar.

Failure modes the access review tends to find

Credentials stored in the wrong environment are a common find. A copy of a production credential sits in a test instance because the test flow was cloned from production, and it works until someone exports the test data to a shared drive. A second find is an inbound token with no expiry and no named owner. A third is a flow that runs with the rights of the user who last edited it rather than a dedicated identity, which means a change to that person’s role alters the integration without any change record. Each of these is cheap to fix once the inventory exists and expensive to explain after an audit.

Making access changes visible to the people who depend on them

Access changes should go through the same change record as the flow change they support. A reduction in rights can break a flow that nobody tested because it runs only at month end. Ask the owners of each dependent flow to confirm the calendar of their runs before the change window opens, and keep a short note of the operations that the reduced account must still perform.

When a simpler model is enough

A single integration with one service account, one external system and no sensitive fields can be documented in a short table and reviewed each year. The full inventory and per-flow accounts are worth the effort when several flows share accounts, when write access reaches sensitive tables, or when an auditor will ask how a change to an integration was authorized.

Access questions that come up during the review

Can an integration account hold an administrator role temporarily?

Avoid it. If a build genuinely needs elevated rights for a short task, give the rights an expiry date, record the change in the access register and remove them as soon as the task ends. A temporary role that is never removed becomes a permanent one.

Do read-only accounts need the same review as write accounts?

Yes. Read access to sensitive fields carries its own exposure risk, and a report extract that quietly includes personal fields can leave the platform as easily as a write can change a record.

What do we do with a vendor that will not let us scope a credential?

Record the broad credential as a named risk with an owner, isolate the flow that uses it so that it cannot reach unrelated tables, and monitor its calls for any activity outside the expected pattern.

The governance model covers the review forums and who sits on them, and the integration patterns guide covers the connector options. For a broader look at review cycles, the access recertification article covers how periodic reviews are run.

How to choose authentication for a ServiceNow Integration Hub connection

Choose the authentication for an Integration Hub connection by how easily the credential can be limited and withdrawn. Prefer token-based OAuth where the other system offers it, a scoped API key next, and basic authentication only when nothing else exists, and run every method through a dedicated account that cannot sign in interactively.

The reasoning is the damage a leaked secret can do. An OAuth token expires and can be revoked on the provider’s side without touching ServiceNow. A username and password usually carries whatever the account carries, for as long as nobody changes it. The choice of method and the instance access model are therefore one decision.

In ServiceNow the secret sits behind a connection and credential alias, so a flow names the alias and never the value. Moving a flow between environments means repointing the alias, and rotation becomes one change.

Before approving a new connection, get four answers:

• Which methods does the other system support, and which is strongest?
• Can the credential be limited to named endpoints or operations?
• When does it expire, and who is warned before it lapses?
• How is it revoked, and does revoking it stop only this flow?

Calls coming into ServiceNow follow the same rules from the other side. The caller uses its own account, marked for web service access only so the credential can never open the interface, with a role for the tables the call touches and nothing wider. Review each connection alongside the integration patterns it supports, and name an owner for failures through integration monitoring and error ownership.

What is an integration user in ServiceNow?

An integration user is a dedicated account that a system or flow uses to call ServiceNow, instead of a person’s login. It is typically marked for web service access only, holds a narrow role, and has one owner who can explain every flow that uses it.

Should an Integration Hub connection use basic authentication or OAuth?

Use OAuth when the other system supports it, because tokens expire and can be revoked without changing ServiceNow. Accept basic authentication only when nothing stronger exists, and then scope the account tightly and record a rotation date against the credential.

How do infrastructure access tools connect to ServiceNow for access requests?

Typically the access tool calls ServiceNow to create or update request records, or ServiceNow calls the tool through a connection to grant or remove access. In both directions the account should be dedicated, narrowly scoped and covered by the same review as any other integration account.