--- sourceDocument: Australia ServiceNow AI Platform Capabilities sourceDocumentLink: https://www.servicenow.com/docs/r/australia/servicenow-platform Release : - australia ft:locale : - en-US ft:publication_title : - Australia ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # MID Server Governance # MID Server Governance {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of MID Server Governance MID Server Governance enhances the security of MID Servers by automatically invalidating and shutting down inactive MID Servers to prevent their misuse, especially if a ServiceNow instance is compromised. This feature records the last status change related to MID Server validation and invalidation. It is not enabled by default but is included with the MID Server plugin. Show full answer Show less Once enabled, MID Servers will have their authentication expire after a set period of inactivity unless explicitly configured otherwise. ## Enable and Configure MID Server Governance * Governance is activated globally by setting the system property **mid.inactivity.timeout.enabled** to true. * The global inactivity timeout period is defined by the integer property **mid.inactivity.timeout.days**, which specifies the number of days before a MID Server is invalidated due to inactivity. The default is 30 days if not set. * Timeouts can be overridden for individual MID Servers by setting the **mid.inactivity.timeout.days** parameter on that server. A value of 0 disables governance for that specific MID Server. * Changes to governance settings do not require restarting MID Servers. * Governance supports both basic and mutual authentication methods. ## Activity Tracking and Auto-Invalidation The MID Server tracks activity by monitoring ECC queue messages. It reports the last activity time to the instance hourly, which is stored in the *eccagent* record. If the inactivity timeout is reached: * If the MID Server is running, it is automatically invalidated and shut down. * If the MID Server is down, an instance job checks for idleness and invalidates the MID Server accordingly. Users receive notifications on the MID Server page as the timeout approaches: * Info messages when 3 to 7 days remain before timeout. * Error messages when fewer than 3 days remain. * Error messages indicating the auto-invalidation date after the MID Server has been invalidated. ## Clearing Auto-Invalidated Status After a MID Server is auto-invalidated, the invalidated state must be manually cleared before restarting the MID Server. If restarted without clearing, the MID Server shuts down immediately and logs an issue. The invalidated state can be cleared via the **Clear auto invalidated** UI action on the MID Server instance page. After clearing, normal startup and validation procedures should be followed. ## Additional Information The **Purpose** field on the MID Server record allows customers to describe the intended use of the MID Server; this is informational only and has no functional impact. For customers looking to extend security and authentication configurations, related topics include: * MID Server certificate check policies * Authentication methods and credentials * Unified key store and Azure Key Vault integration * Command audit logging and FIPS enforcement * IPKI and mutual authentication setup * Encryption and decryption of configuration files * SSL certificate management and external TrustStore configuration Improve MID Server security by setting an automatic timeout to invalidate and shut down inactive MID Servers. You can enable this feature and set the inactivity timeout period globally and for each MID Server. |-| | | [ ] {#mid-timeout__table_yfh_kv4_nhb} ## Overview of MID Server Governance {#mid-timeout__section_s4g_v22_gsb} MID Server Governance prevents forgotten MID Servers connected to ServiceNow instances from being utilized if the instance is compromised. ​MID Server Governance keeps a record of the last status change of the MID Server validation/invalidation process. This feature is not enabled by default, and is available out-of-the-box as part of the MID Server plugin. Once enabled, MID Server authentication is expired after a predetermined period of inactivity unless explicitly configured to never expire. ## Enable and Configure MID Server Governance {#mid-timeout__section_qn1_w22_gsb} MID Server Governance is enabled for all MID Servers by setting the following true/false system property:​ mid.inactivity.timeout.enabled. This property is not defined by default. The global inactivity timeout is ​specified by setting the following integer system property: mid.inactivity.timeout.days. The property takes an integer which specifies the timeout in days. The default timeout is 30 days if unspecified. You can override the timeout for a particular MID Server by specifying mid.inactivity.timeout.days as a configuration parameter on that MID Server. A timeout value of 0 disables MID Server Governance on that MID Server. Therefore, you can set a global timeout and also change or disable timeouts for certain MID Servers. You do not need to restart the MID Server after changing the Governance configuration. Governance works with either basic or mutual authentication. ## Activity Tracking {#mid-timeout__section_ofr_21d_dtb} The MID Server analyzes activity by tracking incoming and outgoing ECC queue messages​. Once per hour, the MID Server reports the last activity to instance, which is stored in the ecc_agent record​​, and checks if the inactivity timeout has been reached. If the inactivity timeout has been reached and the MID Server is up, the MID Server is invalidated and shuts down. If the timeout is reached when the MID Server is down, a job on the instance determines if the MID Server is idle and invalidates it on the instance. When MID server is approaching auto-invalidation timeout due to inactivity, the MID Server page will display a message indicating: * An info message when 3-7 days remain before inactivity timeout. * An error message when less than 3 days remain before inactivity timeout. * After a MID has been auto-invalidated, an error message is displayed indicating the date the MID was auto-invalidated​. {#mid-timeout__ul_psy_cf2_gsb} ## Clearing the auto-invalidated state {#mid-timeout__section_sfc_g1d_dtb} After a MID Server has been auto-invalidated, the auto-invalidated status must be manually cleared in order to bring the MID back up successfully​. The MID Server shuts down immediately if it is restarted without clearing this state. In addition, a MID issue will be logged indicating this occurrence. The auto-invalidated state of a MID Server can be cleared by selecting the Clear auto invalidated UI action from the MID Server instance page​. After invoking this UI action, the user should start their MID Server and continue with the usual validation process. ## Purpose field {#mid-timeout__section_kwn_df2_gsb} The purpose is a text field that the customer can update at any point to indicate the intended usage for the MID Server. This field is purely descriptive and has no further interactions. **Related concepts** * [MID Server certificate check policies](https://www.servicenow.com/docs/8m9x80nAaFWIF8NiDGXc_Q "MID Server uses four kinds of security checks to secure external traffic. The security checks use TLS/SSL certificate validation, hostname validation, Certificate Revocation List (CRL), and Online Certificate Status Protocol (OCSP) validation to improve security. Control these security checks with the MID Server certificate check policies table.") * [MID Server authentication methods comparison](https://www.servicenow.com/docs/z5ydkOwSzufzHuISkzAUeg "The MID Server can authenticate to your instance using basic authentication, mTLS, or IPKI methods. The methods differ in what the MID Server presents, who issues and manages the certificate, and how access is revoked.") * [MID Server authentication credentials and SOAP requests](https://www.servicenow.com/docs/4p8crGngPgOAfdbk8pjYFg#mid-authentication-soap-requests "Set basic authentication credentials to update the web service invocation data. For added security, you can enforce basic authentication on each incoming SOAP request to the MID Server.") * [MID Server unified key store](https://www.servicenow.com/docs/3iLVsHlOfzGiZISJScyUqg#mid-unified-keystore "The MID Server unified key store allows all products on the MID Server to use common certificates and key pairs. This feature allows applications to use the same secure communication channel to the MID Server that the MID Server uses to connect to the instance.") * [MID Server Azure Key Vault integration](https://www.servicenow.com/docs/h~EAcaKr8L7MtsoM1T1JZw#mid-azure-key-vault-integration "The MID Server supports three authentication methods to retrieve credentials from Azure Key Vault without storing secrets on the instance.") * [MID Server command audit log](https://www.servicenow.com/docs/vOdzM6rlBeot3UGc~CspQw#mid-audit-log "The command audit log records the commands run by the MID Server for the Discovery application. Review the commands to verify there are no anomalies or errors.") * [MID Server FIPS Enforced Mode](https://www.servicenow.com/docs/6cyY5imUziFLEBVdeKF8Vg#mid-fips-enforced "The MID Server supports the National Security Cloud (NSC) IL-5 environment, which requires all utilized cryptography to be FIPS validated. The MID server can be run in FIPS Enforced Mode, where only cryptographic algorithms which are FIPS validated are utilized.") * [MID Server IPKI authentication](https://www.servicenow.com/docs/6MMmX~_xgLOT1WZhS4caBA "Instance PKI (IPKI) lets a MID Server authenticate to its instance using a JSON Web Token (JWT) signed by an instance-issued certificate. Use IPKI when you want to authenticate MID Servers with certificates that the instance issues.") **Related tasks** * [Encrypt or decrypt MID Server configuration file values](https://www.servicenow.com/docs/G4CBpk2iPfTHLSDWAWDJ5g "The value of any MID Server parameter in the config.xml file can be encrypted. The attributes for all encrypted values are managed from within the configuration file, including the security attribute of the login password.") * [Enable MID Server mutual authentication](https://www.servicenow.com/docs/1x5Mg3ah2iZZJWtCmt7MHA "Configure the MID Server to use a client certificate for authenticating to the instance. This avoids the need to create a basic authentication credentials in the Key Store for the MID Server's configuration.") * [Rekey a MID Server](https://www.servicenow.com/docs/cfw_kaXQmtxZLN_QCG2fMA "Rekey a MID Server to generate a new private key. Private keys are used to decrypt automation credentials, so that MID Servers can transmit information securely. Key pairs are initially generated when a MID Server is validated, and MID Servers should be rekeyed periodically to meet security requirements.") * [Add SSL certificates for the MID Server](https://www.servicenow.com/docs/8cWDoJ9T_h_b8ifC0ZkXbQ#add-ssl-certificates "Configure the MID Server to connect to a source over SSL.") * [Specify an external TrustStore for the MID Server](https://www.servicenow.com/docs/3RNiYmqV0dQbg~jmllLB_g "The MID Server JVM can utilize a TrustStore external to the MID installation directory so any certificates added to the TrustStore are not overwritten during an upgrade. It is important that this TrustStore file reside outside of the MID installation directory, and the Truststore location can be specified by adding additional parameters to the MID Server's wrapper-override.conf file.") * [Attach a script file to a file synchronized MID Server](https://www.servicenow.com/docs/DmB6BsY304iOeBhp4zOVQQ#mid-server-script-attach "You can attach a script file to synchronize to a connected MID Server.") **Related reference** * [MID Server configuration file security](https://www.servicenow.com/docs/Pqv4zoe2goe4CNWzxvGNvA "Sensitive MID Server configuration data can be protected using several different schemes, including internal and external data encryption and external data storage.") * [MID Server SSH cryptographic algorithms](https://www.servicenow.com/docs/om8pznVaWbn0m7PmSWW9UA "The MID Server utilizes SSH clients to perform many discovery actions. During the SSH handshake, both the client and server first determine which algorithms both parties support, then client picks the highest priority algorithm. For the Host Key Algorithm, the client picks highest priority algorithm which both parties support that matches the key type.")