Centreon provides monitoring, configuration, and API access through several interfaces. Its authentication-token documentation describes API tokens, CMA tokens, and poller tokens as different credential types. Treating them as one class of secret hides the most important difference: an API token is linked to a Centreon user, while a poller or agent token is part of a machine-registration path.
Centreon users can belong to several access groups, and the rights defined in those groups are combined. A token's effective authority therefore depends on the user record, the access groups, the resource filters, and the action permissions. A review that lists token names without that union cannot answer what the token can change.
Measurement and scope
On 2026-11-10 at 21:53 UTC, count-only ZoomEye probes used page 1, page size 1, and sub_type=all. app="Centreon" returned 0 assets. The title query title="Centreon" returned 3,545. The zero app result is not evidence that no Centreon deployment exists. It shows that this product-specific field did not match in this measurement. The title result is an inventory lead, not confirmation of product version or authorization state.
Inventory token type and owner
Export API tokens with the linked user, creation date, expiry, last use, and the integration that calls the API. Keep CMA and poller tokens in a separate register with the agent or poller they belong to. A machine token that is valid for registration should not be able to act as a monitoring administrator.
Calculate effective access for each user. Record access-group memberships, resource ACLs, menu permissions, and action ACLs. Test a read-only monitoring request and a configuration change that should be denied. The user's login role does not replace this test because the ACL groups can combine.
Review the people who can create tokens for other users. Centreon documentation describes administrators and users with the relevant token-management permission as able to create tokens more broadly. That is a privileged capability. Require a named approver and record the token owner.
Protect the token and the API path
Store API tokens in a secret manager and send them only over a protected management path. Do not include them in monitoring dashboards or browser-side code. Check whether the API is reachable from a user network when it should be limited to the automation subnet. TLS protects the token in transit; it does not hide an overprivileged token after it is used.
Rotate poller and CMA credentials through a planned maintenance process. A failed poller registration can affect monitoring visibility, while a stale poller token can preserve an old path. Test replacement and revocation with a spare agent before changing the production fleet.
Use the count honestly
The zero app result and positive title result are a useful example of fingerprint uncertainty. Do not convert either into a claim about exposed Centreon systems. Reconcile the title leads against your own asset inventory, then review the tokens and ACLs inside each confirmed deployment.
The security decision is whether an API credential is a machine-only integration or a user-level union. Centreon's access model makes that distinction visible when the team records the user, groups, resource filters, and actions behind every token.