ServiceNow MID Server: Security and Access Design

Securing a MID Server rests on four controls: certificate-based authentication to ServiceNow, role-based access for administering the server and running its jobs, credentials kept in ServiceNow's encrypted vault, and host firewall rules that limit what the server can reach. Each control depends on who may change the server and which systems it can touch.

Authentication and Communication Security

MID Servers communicate with ServiceNow using SSL/TLS (encrypted, authenticated HTTPS). When a MID Server starts, it authenticates to ServiceNow using a certificate. ServiceNow verifies the certificate (confirming the MID Server is who it claims to be) and the MID Server can then receive and execute jobs.

Manage MID Server certificates carefully. Certificates have expiration dates; monitor when your MID Server certificates expire and renew them before expiration. If a certificate expires, the MID Server cannot authenticate to ServiceNow and becomes offline. Also, if a MID Server is compromised, revoke its certificate to prevent the compromised server from impersonating a legitimate MID Server.

Role-Based Access Control

Not all users should be able to create, edit, or execute MID Server jobs. Define roles for MID Server administration: who can add new MID Servers, who can change MID Server configuration, who can view MID Server logs? Also define roles for job execution: who can trigger discovery jobs, who can run integration jobs, who can execute scripts on target systems?

ServiceNow provides default roles (maint_admin, mid_server_admin) that you can assign to users. Assign these roles based on responsibility: IT infrastructure team gets mid_server_admin, integration team gets roles to create and execute integration jobs. Regularly audit role assignments to ensure they align with job responsibilities.

Credential Management and Segregation

MID Servers need credentials to access target systems: SSH keys for Unix servers, domain accounts for Windows, database passwords, API tokens. Store all credentials in ServiceNow’s encrypted credential vault. Do not store credentials on the MID Server file system, in configuration files, or in logs.

Apply segregation of duties to credentials: a MID Server used for discovery should not have credentials for production infrastructure. Create separate MID Servers for different functions (discovery, integration, script execution) and assign each the minimum credentials necessary. If a MID Server is compromised or misused, the damage is limited by what credentials it can access.

Network Segregation and Firewall Rules

MID Servers should reside in a trusted network segment with restricted access. Use host-based firewalls to control what the MID Server can reach: restrict outbound connections to specific target systems and ServiceNow. Do not allow inbound connections to the MID Server from arbitrary sources; only ServiceNow should send commands to it.

For production MID Servers, consider a screened subnet: a network segment separate from general IT infrastructure, with tighter firewall rules and monitoring. This isolates MID Servers and limits lateral movement if one is compromised.

Audit and Logging

Enable comprehensive logging on MID Servers: what jobs executed, which credentials were used, which systems were accessed, what results were returned. ServiceNow stores job execution history automatically. Use this history for audit: if a job failed, you can trace why (network error, authentication failure, script error). If a job behaved unexpectedly, you can review what it did.

Also audit MID Server configuration changes: when a credential is added or updated, when a MID Server is enabled or disabled, when roles are assigned or revoked. These changes should go through change management; use ServiceNow change requests to document and approve them.

Access Control for Target Systems

MID Servers access target systems using credentials (SSH keys, passwords, tokens). The principle: each MID Server should have access only to the systems it needs to manage. A MID Server managing Windows servers needs domain credentials but not SSH keys. A MID Server discovering database infrastructure needs database credentials but not application server credentials.

When a target system is decommissioned, remove the credentials from the MID Server. When infrastructure moves to a new location or provider, update the MID Server’s network access. This prevents MID Servers from reaching systems they should not touch.

Privilege Escalation and Script Execution

MID Servers can execute scripts on target systems using run commands or other mechanisms. Limit this privilege: a MID Server should not have sudo access unless absolutely necessary. If sudo is required, use sudoers rules to restrict which commands the MID Server can run as root. Document the justification for each privilege escalation; this evidence is useful for security audits.

Security Incident Response

If a MID Server is compromised, isolate it immediately: take it offline, revoke its certificate, and rotate all credentials it had access to. Investigate what the compromise did: which jobs executed, which target systems were accessed, what data was accessed or modified. Use audit logs to reconstruct the incident. After investigation, determine whether any target systems were damaged and whether additional incident response is needed.

Running an access review that finds drift, not just paperwork

Access to a MID Server is rarely set once. Credentials get added for a project that ended, a host picks up a second role during a rushed fix, and a firewall exception stays open because nobody remembered why it was requested. A review that only compares the current configuration with the design document will miss all of this, because the design document was often wrong about the detail from the start. The review needs to start from observed behavior: which targets each cluster actually contacted, which credentials it actually used, and which jobs ran under them.

ServiceNow keeps a record of MID Server traffic and job activity in its own tables, and the ECC queue carries the messages exchanged with each server. Those records show what happened, which is a different question from what was permitted. A useful review puts the two side by side and treats any gap as a finding to explain, not a file to tidy.

Access review checklist by layer

Work through the layers in order. Each layer depends on the one before it, so a finding at the identity layer often explains a finding at the network layer.

1. Identity: list every credential record that a cluster is allowed to use, and mark any that no job has used in the review window.
2. Scope: for each cluster, compare the list of targets in its integrations and discovery schedules with the targets it actually contacted.
3. Privilege: confirm that the service account on each host is not a member of any group it does not need for its current jobs.
4. Network: compare host firewall rules with the routes the cluster used, and remove any rule that no traffic has needed.
5. Change trail: check that every credential or scope change in the period has a matching change record and an approver.
6. Authentication method: record how each cluster authenticates to the instance, and note any cluster still relying on an older method that is no longer the recommended choice for new connections.

Decision table for access findings

Not every finding needs the same response. The table separates findings that can wait for the next scheduled change from those that justify stopping a cluster until the cause is known.

Why unused credentials are the first thing to remove

An unused credential is an open door with no owner. Removing it costs little and reduces what a compromised host could reach, which makes it the cheapest reduction in exposure available to the team.

What the review should not try to prove

A review cannot prove that an access grant was wise. It can show whether the grant is still used, whether it was approved, and whether it matches the design. Keep those questions separate, because mixing them stalls the review.

How often the review should run

Run a light review whenever a cluster changes and a full review on a fixed cycle that your security function already uses for other platforms. Matching the cycle to existing controls avoids another calendar to maintain.

Handling an authentication method change during the review

When a platform change moves clusters to a stronger authentication method, record each cluster’s current method in the review and test the new one in a non-production instance first. Do not combine the method change with a scope change in the same window, because a failure will be impossible to attribute.

Keeping the review tied to ownership

Findings are only useful if someone owns the response. Assign each finding to the owner of the integration or credential it concerns, and track it on the same change board used for other platform work. The roles and approval matrix for MID Server changes shows who should own each response. Where the findings point to a wider pattern of credential sprawl, the note on credential governance for discovery covers the same ownership question for Discovery credentials.

The wider controls these findings sit inside are covered on the access and segregation of duties page.

Questions teams ask about MID Server access reviews

Can the review be automated?

Parts of it can. Pulling the list of credentials, the targets each cluster contacted and the change records are good candidates for a scheduled report. The judgment about whether a finding is acceptable should stay with a person.

Who should receive the review output?

The security reviewer, the MID Server administrator, and the owner of each integration named in a finding. Sending it only to security tends to leave the operational owners unaware of what they must change.

What if a cluster is needed for a target nobody currently owns?

Treat that as a finding in its own right. A target without an owner cannot be reviewed properly, so the first remediation is to assign one, even if the assignment is to the team that inherited the system.