An NHI management platform connects to every cloud account, SaaS tenant, vault and code repository you own, so a compromise of the platform is a compromise of the map and often the keys to all of them. To discover and govern service accounts, API keys, tokens and AI agent identities, the platform needs broad read access, and once you turn on remediation it gains the power to rotate, disable or delete credentials across the estate. The same concentration that makes it useful makes it a prime target, as incidents at platforms holding other organisations' tokens have shown. This guide is for identity and platform security teams who run, or are about to run, an NHI management platform. It covers admin roles, the connector identities the platform uses, the secret material it may see, its own logs, guardrails for automated remediation and lifecycle from purchase to retirement. It is vendor-neutral: confirm exact setting names in your vendor's documentation.
Key takeaways
- The platform is tier 0 by aggregation. No single connector may be tier 0, but together they reach every environment, so protect the console and connectors to tier 0 standard.
- Read access is not harmless here. A complete NHI inventory with owners, permissions and stale credentials is an attacker's target list; limit who can export it.
- Keep secret values out of the platform. Discovery and secret scanning should store fingerprints, locations and metadata, not the credentials themselves.
- Remediation identities need their own controls. Rotate and disable rights belong to separate, narrowly scoped identities with approval gates and action caps.
- Hold the platform to the rules it enforces. Its own connectors should be short lived, least privilege, owned and inventoried, which is the OWASP Non-Human Identities Top 10 applied to itself.
Why the platform concentrates risk
An NHI platform typically joins four kinds of capability: discovery connectors into cloud, SaaS, directories and CI/CD; secret scanning across code, tickets and chat; posture analysis that joins identities to permissions and owners; and remediation that can act on what it finds. Each adds a credential the platform holds and a kind of data it stores.
A CI/CD platform breach shows the pattern from the build side: a platform holding many customers' machine credentials was entered through a stolen engineer session, and customers were told to rotate every stored secret. A sales engagement integration breach shows it for integrations: OAuth tokens held centrally for hundreds of customer tenants became the attack path. An NHI platform with write-capable connectors across your estate is the same shape of risk inside your own organisation.
| Capability | Access or data it needs | If abused | Primary control |
|---|---|---|---|
| Cloud discovery connectors | Read IAM, roles, keys and audit logs across accounts, subscriptions and projects | Full permission graph for every cloud, or write access if over-granted | Read-only roles, federation with external ID, no long-lived keys |
| SaaS and identity provider connectors | Read app registrations, OAuth grants, tokens metadata, service users | List of every third-party integration and its scopes | Least-privilege API scopes, certificate client credentials |
| Code, CI/CD and collaboration scanners | Read repositories, pipeline configuration, tickets or chat | Access to source code and to any secrets the scanner keeps | Read-only app installs per organisation, fingerprint-only storage |
| Vault and secrets manager connectors | Read secret metadata, policies and access logs | Reading secret values if policy grants it | Metadata-only policies; deny read of secret values |
| Remediation actions | Rotate, disable, delete keys; remove permissions; revoke grants | Mass outage or covering tracks | Separate identities, approval, action caps, protected list |
| Inventory and reports | Owners, permissions, last use, risk scores | Ready-made target list for an attacker | Export restricted to named roles; export events alerted |
Admin roles and console access
- Role design: separate platform administrators (tenant settings, connectors, roles), security analysts (view findings), remediation approvers, and application owners who see only their own identities. Scope owner views by business unit or cloud account so no one outside the security team sees the whole inventory.
- Authentication: SSO through your identity provider with phishing-resistant MFA, local accounts disabled once SSO works, and one tested break-glass account. The CISA and FBI Secure by Demand guide suggests buyers ask whether SSO is offered at no additional cost and whether MFA is on by default at no cost. See the Break-Glass Account Guide.
- Admin devices and elevation: grant connector management and remediation approval just in time, from privileged access workstations. The NCSC tiers guidance notes a PAM solution could be designated tier 0 and restricts high-risk actions to PAWs, just-in-time access and just-enough administration. See the Privileged Access Workstations Guide.
- Sensitive actions: require a second approver for adding or widening a connector, suppressing a finding class, bulk export and enabling automatic remediation.
- Review: review console roles and owner scopes every quarter (our recommendation) and on every leaver.
Connector identities: apply the NHI rules to the platform
The platform's own connectors are non-human identities. Run them against the OWASP Non-Human Identities Top 10 before go-live.
| OWASP NHI risk | How it shows up in the platform | What to do |
|---|---|---|
| NHI1:2025 Improper Offboarding | Connectors left behind after a proof of concept, a removed cloud account or a replaced product | Record every connector with owner and expiry; remove on decommission |
| NHI2:2025 Secret Leakage | Connector keys pasted into setup wizards, tickets or scripts | Prefer keyless federation; where keys exist, deliver them from a secrets manager |
| NHI3:2025 Vulnerable Third-Party NHI | The platform itself is a third party with access into your estate | Treat as a critical supplier; assess, contract and monitor |
| NHI4:2025 Insecure Authentication | Shared client secrets, basic authentication to legacy systems | Certificates, private_key_jwt or workload identity federation |
| NHI5:2025 Overprivileged NHI | Organisation-wide admin or owner roles granted for convenience | Read-only roles for discovery; separate scoped write identities |
| NHI7:2025 Long-Lived Secrets | Static cloud access keys for discovery | Role assumption with short sessions; rotate any static key at least every 90 days (our recommendation) |
| NHI8:2025 Environment Isolation | One connector identity spanning production and non-production | One connector identity per environment or account boundary |
| NHI9:2025 NHI Reuse | The same credential used for discovery and remediation | Split read and act identities |
| NHI10:2025 Human Use of NHI | Admins signing in as a connector to debug | Block interactive use; alert on it |
- Bind connectors to the platform: for cloud role assumption, require the platform's unique external identifier and restrict source principals; for API connectors, restrict source addresses to the vendor's documented egress where the target supports it, and alert on use from elsewhere.
- Constrain tokens: RFC 9700 (BCP 240) recommends audience-restricted, least-privilege tokens, sender-constrained tokens using mTLS or DPoP, and asymmetric client authentication. Use these where the target platform supports them.
- Inventory the inventory tool: its own connectors belong in the same NHI inventory, with owners and review dates. See NHI Inventory Reconciliation.
Connection patterns per target type are covered in the NHI management platform integration security guide, and discovery scope in NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
Secret material the platform may see
Secret scanning means the platform will read real credentials in code, logs and tickets. Decide up front what it may keep.
- Store fingerprints, not values: configure scanners to keep a hash or partial fingerprint, the location and the detector type, and to discard the matched value. Ask the vendor to confirm in writing where matched values are processed and whether they are ever written to disk or logs.
- Validity checks: some platforms test whether a found secret is live by calling the issuing service. That is useful for triage but means the platform uses your credential from its own infrastructure. Decide per secret type, and expect those calls in the target's logs.
- Vault connectors: grant list and metadata rights only; deny read of secret values by policy, and alert if the connector ever reads one.
- Findings as sensitive data: a finding that says "valid production key in repository X, line Y" is itself a pointer to a live secret. Restrict who can see finding detail and rotate the secret before closing the finding. See the Secrets Management Guide.
- Platform keys: inbound API keys for SOAR or ticketing integrations get one key per integration, minimum role, an expiry and rotation. For self-hosted components, keep connector credentials in a secrets manager or hardware-backed store, not in configuration files.
Guardrails for automated remediation
Turning on remediation changes the platform from an observer into an actor across every connected environment. Roll it out slowly.
- Start in recommend-only mode: the platform proposes rotations and removals, owners approve, and you measure how often the proposal would have broken something.
- Separate the write identity: give remediation its own identity per environment, scoped to the actions you have enabled (for example disable an unused access key, but not delete roles).
- Protect critical identities: keep a protected list (break-glass accounts, the platform's own connectors, identity provider federation trusts, production deployment identities) that automation can never touch. Changes to the list need two approvers.
- Cap blast radius: limit automatic actions per run and per hour (our suggested starting point: ten credential disables per hour per environment) and fall back to alert-only when the cap is reached.
- Prefer reversible actions: disable before delete, and keep a short window in which a disabled key can be re-enabled, so a wrong call is an incident ticket rather than an outage.
- Keep a kill switch: document one-step suspension of all remediation, who can use it, and test it twice a year.
The platform's own logs
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Connector added, widened, re-credentialed or removed | New access into an environment (T1098.001) | Always |
| Role assignment, SSO change, new local user | Console persistence | Always |
| Inventory or findings export, bulk API reads | Theft of the target list | Always for full exports |
| Finding suppressed or risk accepted | Hides a real exposure | Suppressions with no expiry |
| Remediation proposed, approved, executed, rolled back | Accountability and misuse detection | Bulk actions and protected-list hits |
| Connector credential used from an unexpected source | Stolen connector credential (T1078.004) | Always |
- Export elsewhere: stream the audit log to a SIEM or archive the platform's administrators cannot change. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system.
- Retention: Secure by Demand asks SaaS providers to keep security logs available to customers for at least six months at no extra charge. Check your contract and export if it is shorter.
- Reconcile with targets: every connector call and remediation also appears in the cloud, SaaS or vault audit log. Compare them: activity by a connector identity that the platform has no record of points to a stolen credential.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO, phishing-resistant MFA, logs, vulnerability disclosure, SBOM); ask for the exact permissions per connector and feature, whether matched secret values are stored, data residency, vendor staff access and breach notification terms. See the NHI management platform buyer's guide and NHI management platform RFP template. |
| Deploy | SSO and audit export on day one; read-only connectors first, one environment at a time; remediation off until inventory is trusted. The phased plan is in the NHI management platform rollout playbook. |
| Run | Quarterly reviews of roles, connectors, suppressions and keys; kill switch test; reconcile platform and target logs. See the NHI management platform day-2 operations runbook. |
| Respond | If the platform or a connector is suspected compromised, follow If your NHI management platform is compromised: suspend remediation, revoke connector credentials, and treat any secret the platform could see as exposed. |
| Retire | Remove every connector role, app install, OAuth grant and API key in each target, not just in the console; confirm data deletion in writing; keep the audit history you need. |
Roll back a permission reduction by re-granting only the specific right a connector reports as missing, recorded in a change ticket, never by restoring organisation-wide roles.
Detection and measurement
Metrics that show the platform is held to its own standard:
- Percentage of connectors using federation or certificate credentials rather than static secrets.
- Number of connectors with any write permission, and the share of those used only by remediation identities.
- Connectors without an owner or review date (target: zero).
- Full inventory exports per month, each with a named requester and reason.
- Suppressed findings older than 90 days without re-approval (target: zero).
- Remediation actions rolled back as a percentage of actions executed.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and privileged accounts | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078.004 Cloud Accounts |
| Connector credentials and keys | IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials, T1528 Steal Application Access Token |
| Secret material handling | IA-5 | PR.AA-01 | T1552 Unsecured Credentials |
| Audit log protection | AU-9, AU-9(2) | PR.PS-04 | T1685 Disable or Modify Tools |
| Supplier risk | SA-9, SR-3 | GV.SC-07 | T1195 Supply Chain Compromise, T1199 Trusted Relationship |
Common failure patterns
- Organisation-wide admin for discovery: a connector granted owner rights across every cloud account during a trial is never scaled back.
- Scanner keeps the secrets: matched values are stored in findings or logs, so the platform becomes the largest secret store you did not plan.
- Remediation on the discovery credential: one identity reads and writes everywhere, so its theft is both reconnaissance and impact.
- Orphaned connectors: a removed product or trial leaves roles and OAuth grants in targets, an NHI1 offboarding failure in the security stack itself.
- Inventory open to all owners: every application owner can export the whole estate, not just their own identities.
- Audit log only in the console: connector changes and exports cannot be reviewed once the console itself is in doubt.
Practitioner checklist
- Classify the platform and its connectors as tier 0 by aggregation and administer them from privileged access workstations.
- Enforce SSO with phishing-resistant MFA, disable local accounts and test one break-glass account.
- Scope owner views by business unit and restrict full exports to named roles with alerts.
- Run every connector through the OWASP NHI Top 10: owner, expiry, least privilege, one per environment, no human use.
- Use federation or certificates for connectors; rotate any remaining static key at least every 90 days.
- Configure scanners to keep fingerprints only, and deny vault connectors read of secret values.
- Keep remediation in recommend-only mode until inventory is trusted, then enable with separate identities, a protected list, caps and a kill switch.
- Export the platform audit log to a separate store and reconcile it with target audit logs.
- On retirement, remove roles, grants, installs and keys in every target and get written confirmation of data deletion.
Standards and references
- OWASP: Non-Human Identities Top 10 2025
- NCSC: Secure system administration
- NCSC: Risk manage administration using tiers
- CISA and FBI: Secure by Demand Guide
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1098.001 Additional Cloud Credentials
Related NHI Mgmt Group resources: NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments · Secrets Management Guide · NHI management platform buyer's guide · Securing the identity threat detection and response (ITDR) tool itself