What do organisations get wrong when they treat certification as a one-time achievement?

Why This Matters for Security Teams

Certification is often treated like a finished state, but security capability is not static. When teams assume an older credential still proves current competence, they miss how quickly identity, cloud, and governance controls change in production. That creates a false sense of readiness, especially in environments where NHI sprawl, secrets handling, and access review practices evolve faster than training cycles. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which shows how quickly operational blind spots can outpace credentials and classroom knowledge.

Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls treats security competence as something that must be reinforced through ongoing control operation, not assumed after a single event. That is why recertification matters in practice: it checks whether people still know how to apply current procedures, not whether they once passed a test. The same logic applies to Ultimate Guide to NHIs — What are Non-Human Identities, where lifecycle governance, rotation, and offboarding all require current operational judgment. In practice, many security teams discover certification gaps only after access reviews, audit findings, or a secrets incident has already exposed the weakness.

How It Works in Practice

Organisations usually get this wrong in three ways. First, they confuse certification with validation. A certificate can show that someone met a standard at one point in time, but it does not prove they can operate against today’s tools, policies, or threat patterns. Second, they fail to tie recertification to the control environment. If a team has adopted new IAM workflows, new secret storage patterns, or stricter NHI governance, the knowledge baseline must move with it. Third, they treat learning as optional instead of operational.

Better practice is to make recertification part of a larger competency and control review cycle. That means:

• Mapping certifications to the actual systems and duties a practitioner touches.
• Refreshing skills when major changes occur in cloud platforms, PAM, secrets management, or NHI lifecycle controls.
• Using scenario-based checks that reflect current attack paths rather than memorised definitions.
• Aligning learning with operational evidence, such as access review performance, incident response drills, and change-management outcomes.

This is especially important where certifications are used as a proxy for trust in identity work. NHI Mgmt Group’s Sisense breach coverage illustrates how identity and secret-handling failures can compound quickly when governance is assumed rather than tested. The lesson is not that credentials are worthless, but that they are only a point-in-time signal. Current NIST guidance and common control practice both support repeated validation because the real risk is drift between what was certified and what is now required. These controls tend to break down when organisations keep legacy roles, stale runbooks, and outdated exam content in place after the underlying environment has materially changed.

Common Variations and Edge Cases

Tighter certification requirements often increase administrative overhead, so organisations must balance assurance against the cost of constant reassessment. That tradeoff becomes sharper in regulated environments, global teams, and specialist roles where training windows are limited.

Some teams use annual recertification as a blanket rule, but current guidance suggests the interval should reflect risk and change velocity. A low-change internal platform team may need less frequent refresh than a team managing privileged access, secrets rotation, or NHI governance. There is no universal standard for this yet; best practice is evolving toward role-based and event-based recertification rather than a single fixed schedule.

Another edge case is hiring or promotion. A newly certified practitioner may still need supervised operational experience before being trusted with production approvals. Likewise, a long-tenured expert may be highly capable but still need refresher training after major platform changes. The key is to separate proof of past achievement from proof of current readiness. That distinction matters most when the work involves access decisions, privileged workflows, or incident response, because the consequences of stale knowledge are rarely limited to the individual’s role.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat KYC as a one-time onboarding step?
• What do organisations get wrong when they treat access requests as a one-time approval instead of an ongoing control?
• What do teams get wrong when they treat sso as a one-time integration?
• What do teams get wrong when they treat identity verification as a one-time compliance task?