A machine identity management working group is broader and more cross-functional. It is designed to handle ownership, policy, tooling, discovery, and organisational alignment for machine identities across teams. A traditional crypto centre of excellence is typically narrower in scope and more centred on cryptographic standards. This newer model reflects the need for shared governance across infrastructure, DevOps, security, and cloud stakeholders.
How the two models differ in scope and operating intent
A machine identity management working group is designed to coordinate a broader operating model. It brings together teams that own discovery, policy, tooling, lifecycle, and governance for machine identities, so the programme can work across cloud, DevOps, security, and platform boundaries. A traditional crypto centre of excellence is usually narrower, with stronger emphasis on cryptographic standards, key usage, and approved technical patterns.
The practical difference is not just organisational shape, it is the problem being solved. The working group manages the full identity surface, including ownership, onboarding, rotation, offboarding, and accountability. The centre of excellence tends to concentrate on cryptographic design decisions, library choices, and standardisation of secure primitives rather than cross-team operational governance.
That is why the working group is better suited to machine identities as an enterprise capability. Machine identities span service accounts, workload credentials, certificates, tokens, and automated integrations, so the control problem is partly cryptographic but also about who owns the identity, how it is discovered, and how it is governed over time. Ultimate Guide to NHIs is a useful reference point for that broader model.
Why the machine identity model needs broader governance
machine identity management becomes cross-functional because the failure modes are cross-functional. Discovery often sits with platform or cloud teams, policy with security, implementation with engineering, and enforcement with operations. If those pieces are split across separate decision forums, the organisation can end up with inconsistent ownership, shadow credentials, and unclear standards for rotation or decommissioning.
A crypto centre of excellence can still be important, but it usually answers a different question: which cryptographic approaches are acceptable, and how should teams implement them safely. That helps with algorithms, certificate handling, or key-management conventions, but it does not by itself solve lifecycle ownership, inventory, or service-to-service accountability. For that reason, machine identity governance usually needs a forum that can resolve operational conflicts, not only technical ones.
Practitioners often underestimate how much machine identity risk comes from coordination gaps rather than weak cryptography alone. When teams can create credentials faster than they can inventory, review, and retire them, the result is usually sprawl, stale access, and unclear blast radius. Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks both reflect that lifecycle pressure.
When a crypto centre of excellence is still the right fit
A traditional centre of excellence remains valuable when the main decision is cryptographic: cipher selection, certificate policy, signing standards, trust anchor management, or approved libraries. In those cases, consistency and technical depth matter more than broad organisational alignment. The centre of excellence provides guardrails that reduce implementation variance and help teams avoid insecure or unsupported crypto choices.
The limitation is that crypto governance stops short of operational ownership. It can recommend how secrets or certificates should be protected, but it usually does not decide which team owns a service identity, who approves access changes, or how exceptions are handled across environments. If the question is “how do we keep the cryptography sound?”, a centre of excellence is a good model. If the question is “how do we govern thousands of machine identities end to end?”, it is usually too narrow on its own.
That distinction matters because many machine identity failures are rooted in lifecycle and access decisions rather than cryptographic weakness. Longer-lived credentials, unmanaged service accounts, and incomplete deprovisioning tend to create exposure even when the underlying crypto is strong. Guide to NHI Rotation Challenges is directly relevant to that operational reality, while SPIFFE workload identity specification shows how workload identity can be made more explicit and structured.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine identity governance must address excessive privileges across teams. |
| NHI-01 — Improper Offboarding | The working group owns retirements and deprovisioning, not just crypto. | |
| NHI-07 — Long-Lived Secrets | Rotation and lifecycle control are central to machine identity management. | |
| Recommendation — Set privilege boundaries and review machine identity access regularly. Define offboarding ownership and revoke machine credentials promptly. Shorten secret lifetimes and enforce rotation for machine credentials. | ||
| NIST SP 800-57 | Key Management | A crypto centre of excellence centers on key lifecycle and approved cryptographic practice. |
| Recommendation — Standardize key generation, storage, rotation, and destruction practices. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Machine identity working groups coordinate identity ownership and governance. |
| Recommendation — Assign clear ownership for identity lifecycle and access governance. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The scope includes access governance across machine identities and teams. |
| Recommendation — Define access control policy for machine identities and enforce it consistently. | ||
Practitioner Guidance
What to prioritise: If the organisation is struggling with ownership, inventory, policy drift, or cross-team accountability, treat the working group as the primary governance forum. If the main problem is inconsistent cryptographic implementation, keep the centre of excellence in the lead for technical standards.
Decision rule: Use a working group when the control objective spans discovery, lifecycle, and operating ownership across multiple teams; use a centre of excellence when the objective is mainly to define and maintain approved crypto patterns. Many programmes need both, but they should not be allowed to blur into one another.
What good looks like: The working group has clear decision rights for onboarding, rotation, offboarding, and exceptions, while the crypto centre of excellence defines the technical baseline for keys, certificates, and approved cryptographic methods. The healthiest model is coordinated, with the identity forum translating policy into operating practice.
Practitioner takeaway: A machine identity programme fails when crypto is treated as the whole problem, because the hard part is usually shared governance across ownership, lifecycle, and enforcement.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between certificate management and machine identity management?
- What is the difference between machine identity management and human IAM?
