Skip to content
Avanet

Operate Sophos Fusion Integration Credential Manager

Integration Credential Manager manages credentials for third-party products that Sophos Fusion (formerly 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 Fusion. In Credential Manager, Sophos Fusion 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 the integration features with access.

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. Under Credential Type, select a supported 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 intended integration, health, and usage, and functionally test the integration. 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

The list view 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 accessed, including the last use and possible inactivity warnings,
  • Used by, listing the integration features that can use the credential,
  • the 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.

The details page also shows Vendor, Vendor Identifier, Permissions, and Integration Access. Usage shows the number of requests and the last request time. 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 functionality. Used by and Integration Access show integration features, but they don’t replace your own inventory of the specific integration instances that must be checked before a change.

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 permanently purged 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. This requires email alert rules for Credential Manager. A Super Admin opens Global Settings > Platform > Notification Settings > Configure Email Alerts and checks recipients, frequency, and alert types. Enabling the first custom rule disables the existing recipient settings, so explicitly include the required administrators and distribution lists in a suitable rule.

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.

Replace credential values in a controlled way

Credential Manager doesn’t rotate a secret in the third-party product itself. If the vendor supports replacement, coordinate its documented procedure with the Central update in a maintenance window:

  1. Record specific integration instances, Used by, Integration Access, and last use.
  2. Prepare a replacement value according to the third-party product’s documentation.
  3. Update the credential in Central through Actions > Edit.
  4. Verify health, usage, and the affected integration functions.
  5. Revoke the old value only after successful verification and according to the vendor procedure.
  6. Review audit and integration logs.

Only the third-party product determines whether old and new values can overlap. If overlap isn’t documented, don’t promise a seamless change; plan for and monitor a possible interruption.

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.

A change interrupts several integrations

The credential is reused. Used by is the first indication of the impact, but also identify every specific integration instance in your own inventory and test them together.

Delete warns of possible usage

Do not bypass the warning. Migrate or remove every linked integration before deleting the credential.

Frequently asked questions

Is Integration Credential Manager a general password vault?

No. It supports a limited set of credential types for Sophos integrations. Other secrets belong in the enterprise secret store.

How does it differ from API Credentials?

API Credentials give an application access to Sophos Fusion. Integration Credential Manager stores credentials that Sophos Fusion uses to access a third-party product. Roles, secret rotation, and API hosts are covered in Manage Sophos Central API credentials securely.

Can one credential be used for several integrations?

Yes, if the type supports it. This reduces the number of secrets but increases the blast radius of a change or deletion. Document every dependency.