What do organisations get wrong about continuous security?

Why This Matters for Security Teams

Continuous security is not a reporting cadence. It is the discipline of keeping access, exposure, and response aligned to current conditions so that controls change as quickly as the environment does. That matters because attack paths now move through identities, secrets, cloud permissions, and third-party integrations, not only through perimeter weaknesses. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why periodic review often misses real risk.

Security teams often get this wrong by treating “continuous” as a dashboard problem, then leaving remediation, privilege reduction, and credential rotation on monthly or quarterly cycles. That creates a false sense of control, especially when service accounts, API keys, and delegated access remain valid long after the business context has changed. The NIST Cybersecurity Framework 2.0 is useful here because it frames security as an ongoing governance and operational function, not a one-time hardening exercise. In practice, many security teams encounter the failure only after a stale credential or over-privileged integration has already been used, rather than through intentional continuous assurance.

How It Works in Practice

Operationally, continuous security means controls are tied to changes in identity, asset state, and threat signals. When a new workload appears, when an OAuth grant is added, when a privileged session starts, or when an AI agent receives tool access, the related policy, logging, and approval path should update immediately. That is the difference between “monitoring” and “continuous control.” NHI Management Group’s Ultimate Guide to NHIs highlights why this matters: 71% of NHIs are not rotated within recommended time frames, and 92% of organisations expose NHIs to third parties, which turns static access into a supply chain problem.

In practice, security teams should design continuous security around a few linked behaviours:

• continuous discovery of identities, secrets, and third-party connections
• policy enforcement that shortens privilege duration and removes standing access where possible
• rotation and revocation workflows triggered by risk events, not calendar dates alone
• telemetry that correlates identity events with workload, network, and application activity
• validation that response actions actually removed access, rather than only generating an alert

This approach aligns with NIST AI Risk Management Framework style governance logic when AI systems or agents are part of the environment, because continuous assurance must cover both system behaviour and the permissions those systems hold. It also fits the practical control intent behind OWASP secrets management guidance, especially where secrets are embedded in CI/CD, config, or automation. These controls tend to break down when identity data is fragmented across SaaS, cloud, code pipelines, and unmanaged third-party integrations because no single team sees the full access graph in time.

Common Variations and Edge Cases

Tighter continuous control often increases operational overhead, requiring organisations to balance faster enforcement against developer friction and alert noise. That tradeoff becomes more pronounced in hybrid estates, regulated environments, and AI-enabled workflows where access is dynamic and ownership is not always obvious. Current guidance suggests that continuous security should be risk-based, not uniformly aggressive, because overcorrection can push teams into bypasses and exceptions that weaken the programme.

There is no universal standard for this yet, especially where agentic systems can request tools, access data, or act on behalf of users. In those cases, the security question is not only whether the agent is monitored, but whether the agent’s identity, delegated permissions, and secrets are governed with the same discipline as a human admin account. That is where continuous security overlaps with NHI governance: if the organisation cannot inventory service accounts, vault access, and third-party OAuth grants in near real time, it cannot credibly claim continuous assurance. The best practice is evolving toward event-driven review, just-in-time privilege, and automated offboarding, but the exact implementation will vary by cloud model, regulatory scope, and blast-radius tolerance.

Related resources from NHI Mgmt Group

• What do organisations get wrong about Salesforce integration security?
• What do organisations get wrong about AI security coverage?
• What do organisations get wrong about continuous vendor monitoring?
• What do organisations get wrong about reactive identity security spending?