Who is accountable for keeping externally exposed assets visible between security assessments?

Why This Matters for Security Teams

externally exposed asset are rarely static, and that is what makes accountability essential. Ownership must sit with the teams that can see new exposure, validate whether the asset is intended, and drive remediation before attackers do. Current guidance from NIST SP 800-53 Rev. 5 on continuous monitoring and inventory discipline makes the operational point clear: visibility is not a one-time assessment outcome, it is an ongoing control function.

For non-human identity and externally reachable systems, the risk is amplified because exposure often changes through CI/CD, cloud drift, partner integrations, and forgotten credentials. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 91.6% of secrets remain valid five days after notification, which means exposure often persists well beyond the first signal. See Ultimate Guide to NHIs — Why NHI Security Matters Now and The 52 NHI breaches Report for why hidden exposure becomes a breach multiplier.

In practice, many security teams discover exposed assets only after an internet scan, a partner complaint, or a credential misuse event has already confirmed the gap.

How It Works in Practice

The accountable model is usually a shared operating arrangement, but one team must own the outcome. Asset inventory teams maintain the authoritative list of systems, domains, APIs, service accounts, and cloud resources. Security owns detection rules, external attack surface monitoring, and risk triage. Infrastructure or platform teams own the actual remediation path, including DNS, load balancers, certificates, access policies, and retirement of abandoned resources. Where NHI exposure is involved, the service owner or platform owner must also participate because the exposed secret, token, or certificate is part of the asset itself.

Practically, this means the workflow needs three things: continuous discovery, assignment rules, and time-bound remediation. Continuous discovery finds new exposure through scanners, cloud telemetry, repo scanning, and external monitoring. Assignment rules decide whether the item goes to app owners, cloud operations, IAM, or a product team. Time-bound remediation sets expected closure dates, escalation thresholds, and evidence of fix. NIST guidance on inventory and monitoring supports this approach, and attack-surface governance aligns with the visibility principles described in the Ultimate Guide to NHIs. For the control model, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the baseline for monitoring, configuration, and response ownership.

• Assign a named owner for each externally exposed asset, not just each application.
• Separate detection ownership from fix ownership so findings do not stall in triage.
• Track remediation SLAs for exposure, not only for vulnerability severity.
• Include secrets, service accounts, and API endpoints in the same inventory process.

These controls tend to break down in fast-moving cloud environments where ephemeral assets are created and destroyed faster than the inventory and ticketing systems can synchronise.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance speed of change against assurance that nothing internet-facing is left unowned. That tradeoff is real, especially in DevOps-heavy environments where teams deploy directly to production and service boundaries are fluid. Best practice is evolving, but current guidance suggests that accountability should follow the control plane, not just the business application.

There are edge cases. Shared platforms may have central infrastructure ownership, while application teams own the exposed service configuration. Third-party hosted services may place remediation partly with the vendor and partly with the internal service sponsor. In merger or outsourcing scenarios, visibility can sit with security while fix authority sits elsewhere, which is why escalation paths need to be pre-agreed. The key is to avoid a model where security only reports exposure and no one is responsible for closing it.

For organisations managing NHIs, the same principle applies to API keys, OAuth grants, and certificates. A discovered exposure should trigger revocation, rotation, or containment, not just a ticket. NHIMG’s analysis in 52 NHI Breaches Analysis shows why ownership gaps become persistence gaps when secrets remain valid after detection. In mixed ownership models, the most reliable pattern is a clear RACI with one accountable owner per asset and one execution owner per remediation action.

Related resources from NHI Mgmt Group

• Who is accountable for closing the loop on cloud security remediation between security and engineering teams?
• Who is accountable when layered identity security leaves gaps between Microsoft and non-Microsoft environments?
• Who is accountable for prioritising exposure remediation when new vulnerabilities appear between assessments?
• What is the difference between role-based access and API key governance for NHI security?