ServiceNow MID Server Governance Model

A MID Server governance model is the set of decisions that say how many MID Servers an estate runs, who owns each one, which credentials it may hold and who approves a change to it. The page covers server placement, credentials, network access, redundancy and change classes.

MID Server Role and Deployment Architecture

MID Servers (Management, Instrumentation, and Discovery) run on your infrastructure behind your firewall, enabling ServiceNow to communicate with on-premises and private cloud systems. MID Servers handle Discovery scans (scanning your infrastructure), data imports, webhook processing, and outbound integration calls. A MID Server acts as a proxy between ServiceNow (cloud-hosted) and your internal systems (firewall-protected).

Governance starts with architecture decisions: How many MID Servers do you deploy? Where are they located? ServiceNow recommends redundancy: at least two MID Servers in each location, so if one fails, the other continues processing. A single MID Server is a single point of failure; if it goes down, Discovery stops, integrations fail, and ServiceNow loses visibility into your infrastructure.

Location considerations: MID Servers should run in a network location with access to systems they need to monitor. If your MID Server runs in a corporate network but you have systems in a private cloud or remote office, consider deploying additional MID Servers closer to those systems. This reduces latency and allows segmented network access (each MID Server only sees the systems it needs to manage).

Credential Management and Access Control

MID Servers require credentials to access systems: database passwords for Discovery scans, API keys for integrations, SSH keys for server access. These credentials must be stored securely and accessed only by authorized MID Servers. Credential management is a critical security concern; leaked MID Server credentials give attackers direct access to your infrastructure.

ServiceNow Credential Vault stores encrypted credentials on the ServiceNow instance. MID Servers retrieve credentials from the Vault at runtime (not stored locally on the MID Server). When a MID Server needs to scan a database, it requests the database password from the Credential Vault, connects to the database, performs the scan, then discards the password. This ensures credentials are not exposed on the MID Server.

Implement least privilege for credentials: Create a dedicated service account for each system the MID Server accesses, with permission to only the required operations. For Discovery of a database, the service account needs read access to configuration tables and system views; it should not have write access or administrative rights.

MID Server Configuration and Governance Policies

Define governance policies for MID Server configuration: Who can approve new MID Server deployments? Who manages credentials? Who is responsible for keeping MID Servers patched? Who monitors MID Server health?

Create a MID Server ownership model: Each MID Server has an owner (typically an infrastructure team member) responsible for its operation. The owner ensures the server is patched, monitored, and available. When a MID Server fails, the owner is accountable for restoration.

Document MID Server capacity: How many concurrent tasks can a MID Server handle? What is the maximum Discovery scan frequency? Overloaded MID Servers lead to slow performance and timeouts. Monitor MID Server resource utilization (CPU, memory) and plan for additional servers if capacity is consistently high.

Network and Firewall Configuration for MID Server Traffic

MID Servers communicate outbound to ServiceNow (HTTPS) and inbound to internal systems (database, API, SSH). Firewall rules need to allow outbound HTTPS from the MID Server to the instance, and the MID Server’s access to the internal systems it manages.. Typically, MID Servers initiate outbound HTTPS connections to ServiceNow and need no inbound connections opened to the instance.. This architecture works within most corporate firewall policies.

Define network segmentation: If possible, deploy MID Servers in a DMZ or dedicated network segment. This limits lateral movement if a MID Server is compromised. MID Servers should only have network access to systems they need to manage, not open access to the entire corporate network.

Monitor MID Server network traffic: Log all connections the MID Server makes (ServiceNow, internal systems, external APIs). Unusual traffic patterns (unexpected external connections, high data transfer volumes) may indicate compromise. Implement network monitoring alerts for MID Servers.

MID Server Health Monitoring and Redundancy

Monitor MID Server availability continuously. ServiceNow includes MID Server health checks: connectivity to ServiceNow, available disk space, and resource utilization. Configure alerts if a MID Server becomes unavailable (no heartbeat within a set period). When a MID Server is unavailable, its workload should automatically shift to redundant MID Servers.

Implement a failover mechanism: If a primary MID Server fails, redirect its work to secondary MID Servers. ServiceNow Orchestration can include MID Server affinity rules: for each activity, specify which MID Servers can execute it. If the preferred MID Server is down, the activity runs on a secondary MID Server.

Patching and Upgrade Procedures

MID Servers require regular patching (OS patches, Java updates, MID Server software updates). Plan a maintenance window schedule (e.g., monthly) when MID Servers are patched. During patching, MID Servers are briefly unavailable; redundant MID Servers ensure that work is not lost.

Test patches in a non-production MID Server environment before deploying to production. MID Server software updates sometimes introduce compatibility issues with specific versions of ServiceNow or internal systems. Staging changes reduces production risk.

Audit and Compliance Logging

Log all MID Server activities: Discovery scans, data imports, API calls, credential access. Maintain audit trails for as long as your retention policy and compliance requirements require. Use logs to troubleshoot issues, identify security problems, and demonstrate compliance with audit requirements.

For regulated environments, implement role-based access control on MID Server logs: only compliance and security teams should access logs containing credential use or access to sensitive systems. Restrict MID Server administrative capabilities to platform team members.

Sorting MID Server changes into classes before anyone approves them

How to handle a change that does not fit a class

Some requests straddle two classes. A new integration that also needs a new credential is both a job scope change and a credential change. The rule should be that the stricter approval applies, and that the two evidence sets are both attached. Dividing one request into two smaller requests to avoid the stricter path is a governance failure even when each piece looks harmless.

1. Classify the request by the highest-risk element it contains.
2. Name the approver for that class, and record the decision with its date and reason.
3. Attach the evidence listed for the class, and link it to the server’s record.
4. Set a review point for changes that touch credentials or topology, so the decision is checked against what happened.
5. Record any exception to the model, and bring the exception to the next governance review as a case to decide, not an accident to forgive.

Reviewing the model itself

A governance model is a set of hypotheses about where the risk sits. When the same class of change keeps causing incidents, the class is wrong or its approver lacks the information to decide. When approvals always pass without comment, the review adds delay and no protection, and the classes should be narrowed. Look at the record of changes every few months and ask which class surprised the team most. The answer shows where the model needs attention.

Does a routine patch need a committee approval?

Usually not. A routine patch applied within a standing window, with a documented health check afterwards, can be approved by the platform administrator on duty. The committee’s time is better spent on credential and topology changes, where the consequences of a mistake are larger and harder to reverse.

Who should hold the emergency path?

The on-call lead should hold the authority to act, because the delay of waiting for a meeting can be longer than the outage. The safeguard is the timed record and the review that follows. An emergency path that is used for convenience rather than urgency should be treated as a governance finding.

Getting the classes right for your estate

The classes in the table are a starting point, and the right boundaries depend on how many servers you run and how many services depend on them.

Related guides: ServiceNow MID Server: Roles, Responsibilities and RACI and ServiceNow MID Server: Security and Access Design.