Operate Sophos Central Integration Credential Manager
Integration Credential Manager manages credentials for third-party products that Sophos Central uses in integrations. Examples include API tokens or accounts for Data Ingestion and Response Actions.
Do not confuse it with API Credentials. API Credentials let an external application access Sophos Central. In Credential Manager, Sophos Central instead stores credentials to access a third-party product.
When Credential Manager is appropriate
Create a credential there when a supported Sophos integration needs access to an external product and that credential type is available in Central. The manager can reuse credentials across multiple integrations of the same type and shows health, last use, permissions, and linked integrations.
It cannot store every possible secret type. Unsupported integrations remain governed by the enterprise secret store.
Plan permissions in advance
Define these points before creation:
- third-party product and target instance,
- permitted read or write actions,
- Sophos functions allowed to access the credential,
- technical owner and emergency contact,
- expiration date and rotation procedure,
- inactivity limit,
- test and rollback.
Grant write access only when Response Actions are genuinely required and are also restricted in the third-party product. An integration that only reads telemetry does not need modification rights.
Create a credential
Go to Global Settings > Access Control > Integration Credential Manager. Add first opens the Type page. Select a supported credential type, such as Okta API Token, and confirm with Next.
On Details, enter the name and description, select Read or Write permission, and under Integrations with Access select only the required Sophos functions, such as Data Ingestion or Response Action. Optionally configure an Inactivity limit and, where available for the type, an Expiration date. On the right, review the security implications and accept Vendor and Product documentation and disclaimer.
If the disclaimer checkbox is not accepted on Details, Central offers it again on the next page. The credential is not released for production without explicit acceptance; the extra dialog does not replace the internal review of third-party access.
On the Credential page, enter the values required by the third-party product, such as the URL and API Token in the Okta example. Obtain them from the relevant product configuration, not another organization’s example. Save creates the credential. Then check the dependent integration, health, usage, and a test event. Alternatively, a supported integration can create a credential with default permissions during setup, which is then narrowed in the manager.
The external account itself also requires least privilege. A narrow Central setting cannot compensate for an overprivileged account in the third-party product.
Monitor health and usage
Depending on the credential, Central shows:
- Healthy, Partially healthy, or Unhealthy,
- a dash instead of the health icon and Awaiting usage on hover when it has never been used,
- last use,
- integrations that use it,
- permissions and credential type,
- warnings before suspension or purge.
A green credential status proves only that technical use works. It does not confirm that all data arrives or that a Response Action has the correct business effect. Check a test event, timestamp, and result in the target system.
On the details page, Usage shows the number and time of requests. Logs contains only the 250 most recent events and can be filtered by status, integration type, and time range. For longer traceability, copy relevant errors to operational monitoring or a support case before they are overwritten.
Edit, suspend, or delete a credential
To edit, open the credential name under Global Settings > Access Control > Integration Credential Manager and select Actions > Edit. Central presents the same setup pages used for creation. On Details, change the name, description, permissions, integration access, inactivity limit, and, if available, expiration. On Credential, replace the actual third-party values. After saving, test health, usage, and function for every integration identified under Used by.
To suspend manually, select the credential, choose Actions > Suspend, and confirm the usage warning. This is useful when compromise is suspected or during controlled troubleshooting, but stops data and response use for every dependent integration. Actions > Unsuspend reactivates the credential and resets its inactivity period to six months or the individually configured value.
For credentials no longer required, migrate every dependency first. Then select Actions > Delete and confirm the warning. Deleting does not automatically revoke the corresponding account or token in the third-party product; remove or rotate it there as well.
Inactivity, suspension, and purge
By default, a credential is suspended after six months or 180 days of inactivity and removed after one year. Under Actions > Edit > Inactivity limit, it can instead be suspended after one year and purged after two. Changing the limit starts the new period immediately and removes existing warnings.
Before extending an inactivity limit, determine whether the integration is still required. A rarely triggered emergency action needs a documented functional test, not an unlimited secret.
Central warns 90 days before suspension. Before purge, it warns 90, 60, 30, and 7 days in advance. These notifications are delivered reliably only when suitable email alert rules for Credential Manager exist.
Actions > Reset inactivity limit resets the remaining inactivity period to six months or the configured value. Actions > Unsuspend reactivates a suspended credential and resets the same period. First verify the external secret, permissions, and dependent integrations; unsuspending cannot repair an expired or revoked token.
Manual suspension stops data transfer for every integration that uses the credential. Purge or deletion can permanently interrupt multiple integrations when the credential is reused.
Rotate without a data gap
For secrets that can be rotated in the third-party product, use a maintenance window:
- Record dependent integrations and last use.
- Generate a new secret in the third-party product.
- Update the credential in Central.
- Verify health and a test event.
- Revoke the old secret in the third-party product.
- Review audit and integration logs.
If the third-party product supports two parallel secrets, use a short overlap. Otherwise, schedule and monitor a small data gap.
Common problems
Status remains Awaiting usage
The credential is not assigned to an active integration, the integration has not run, or the wrong credential set was selected. Check assignment and a test event.
Credential is healthy, but data is missing
Check the time range, data source, integration, filters, and permissions in the third-party product. Health does not confirm every expected data volume.
Rotation interrupts several integrations
The credential was reused. Identify all dependencies under Used by and test them together.
Delete warns of possible usage
Do not bypass the warning. Migrate or remove every linked integration before deleting the credential.