TL;DR: Encryption, key management, and protected data handling remain tied to identity governance across machine and human access paths, as ASPG’s MegaCryption event on July 2 is a cryptography-focused webinar listing with no substantive technical detail. The absence of operational detail means practitioners should read it as a reminder that cryptography only works when identity, entitlement, and secret handling are controlled.
At a glance
What this is: This is a webinar listing for ASPG’s MegaCryption event, and the key finding is that it provides no technical detail beyond the cryptography theme.
Why it matters: It matters because cryptographic controls depend on identity governance, secret handling, and access boundaries, even when the event itself is only a brief announcement.
👉 Register for ASPG's MegaCryption event on cryptography
Context
Cryptography only reduces risk when the identities that use keys, certificates, and protected data are governed properly. A webinar listing about encryption may be light on detail, but the underlying security problem is familiar: controls fail when access, secret handling, and lifecycle management are treated as separate disciplines rather than one programme.
For IAM, NHI, and privileged access teams, the relevant question is not the event itself but the operational model behind it. Key custody, certificate usage, and access boundaries all depend on identity decisions, which is why encryption topics belong in the same governance conversation as secrets management and workload identity. See the Ultimate Guide to NHIs for the lifecycle view.
Key questions
A: Teams should govern cryptographic material as an identity asset, not as a standalone technical control. That means assigning ownership, tracking every human and workload that can use it, enforcing rotation and revocation, and tying renewal to lifecycle processes. If the organisation cannot prove who can present or retrieve the material, the crypto control is incomplete.
Q: Why do encrypted systems still suffer serious exposure when secrets are poorly managed?
A: Encryption protects data in transit or at rest, but it does not stop misuse by identities that already hold valid access. If secrets are static, shared, or hard to revoke, an attacker or insider can use legitimate credentials to reach protected systems. The control failure is governance over the identity, not the cipher.
Q: What breaks when certificate and key lifecycle ownership is unclear?
A: Rotation, renewal, and revocation all become unreliable when no one owns the lifecycle. That leads to stale credentials, missed expirations, and systems that keep trusting identities long after they should have been retired. The result is hidden access persistence that weakens the entire cryptographic programme.
Q: Which identity controls should be reviewed before expanding cryptography programmes?
A: Review inventory, entitlement scope, renewal workflow, and offboarding before expanding the programme. Cryptography only reduces risk when access to keys, certificates, and protected data is tightly bounded. Teams should verify that human and machine identities are both covered by the same governance model.
Background and context
Why cryptography depends on identity governance
Encryption protects data only when the systems and people using it are authenticated, authorised, and auditable. In practice, the weak point is usually not the algorithm but the identity around it, such as service accounts, API keys, application tokens, certificate issuers, and privileged operators. If those identities are over-permissioned or poorly lifecycle-managed, encryption does not prevent misuse. The control surface therefore includes access scope, key custody, rotation, and revocation, not just cryptographic strength.
Practical implication: treat cryptographic assets as identity-bound resources and review who or what can use them.
Secrets, certificates, and workload identity in crypto operations
Cryptographic operations depend on secrets that authenticate workloads and users to each other. That includes API keys, signing keys, client certificates, and the service identities that fetch or present them. When those identities are static, widely shared, or hard to inventory, the organisation loses control over where cryptography is actually enforced. This is why workload identity and secrets lifecycle management are part of the crypto control stack, not separate housekeeping tasks.
Practical implication: inventory every identity that can retrieve, store, or present cryptographic material.
NHI Mgmt Group analysis
Cryptography is an identity control problem as much as a data protection problem. Encryption fails operationally when the identities behind it are unmanaged, over-privileged, or impossible to retire cleanly. The control that matters is not just key strength, but whether the organisation can prove which human and machine identities can touch protected material. Practitioners should treat crypto governance as part of IAM and NHI governance, not as a separate security silo.
Static secrets remain the quiet failure mode in encrypted environments. When applications rely on long-lived API keys, certificate material, or shared credentials, encryption protects the payload but not the pathway. That creates hidden exposure windows that are hard to detect and harder to revoke. The practical conclusion is that teams need lifecycle visibility over every identity that can unlock protected systems, not just periodic assurance over the data itself.
Certificate and key handling expose the same governance gaps as other machine identities. A certificate is still an identity artefact, and it becomes risky when ownership, rotation, and offboarding are unclear. That makes cryptography relevant to the broader NHI agenda: inventory, entitlement, renewal, and retirement all apply here. Practitioners should align crypto operations with the same lifecycle discipline they apply to service accounts and tokens.
Named concept: crypto custody drift. This is the point at which control over cryptographic material quietly shifts away from the team that believes it owns it. It happens when keys, certificates, or secrets are replicated across tools, environments, or teams without a single accountable lifecycle process. The implication is that encryption posture can look strong while actual operational custody is fragmented and weak.
Identity governance teams should read cryptography through the lens of blast radius. If one identity can unlock many systems, then cryptography is amplifying that identity’s reach rather than constraining it. That is a governance failure, not a tooling failure. Practitioners should use crypto programmes to surface where access scope is broader than the protected asset warrants.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- Read the Ultimate Guide to NHIs for the lifecycle controls that connect secrets handling, rotation, and offboarding.
What this signals
Crypto custody drift: teams often believe encryption is the control, when the real risk sits in who can retrieve, present, or retire the underlying identity artefacts. That means security programmes should track key and certificate ownership with the same discipline used for privileged accounts and service identities.
With 27 days as the average time to remediate a leaked secret according to The State of Secrets in AppSec, the operational gap is not theoretical. Security leaders should expect crypto reviews to surface stale access, unclear ownership, and lifecycle blind spots rather than pure algorithmic weakness.
For a broader governance lens, the Top 10 NHI Issues shows why secret sprawl and over-privilege belong in the same conversation as encryption policy. Teams that separate those topics usually miss the control failure that matters most.
For practitioners
- Map cryptographic assets to identity owners Create a register of keys, certificates, tokens, and the humans or workloads that can retrieve or use them. Include service owners, approvers, renewal paths, and decommission steps so custody is clear end to end.
- Fold crypto review into lifecycle governance Review issuance, renewal, rotation, and revocation alongside joiner-mover-leaver processes for both human and non-human identities. A cryptographic artefact that cannot be retired cleanly should be treated as an active governance issue.
- Reduce shared secret exposure paths Replace shared keys and embedded credentials where possible, and track every system that can present or store cryptographic material. This makes it easier to see where one compromise could affect multiple applications or environments.
Key takeaways
- Cryptography does not compensate for weak identity governance around keys, certificates, and secrets.
- Long-lived or poorly owned credentials remain the practical failure mode in encrypted environments.
- Teams should manage cryptographic material through the same lifecycle controls used for service accounts and other non-human identities.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret rotation and lifecycle control are central to this cryptography governance topic. |
| NIST CSF 2.0 | PR.AC-4 | Cryptographic access must be limited to the identities that genuinely need it. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification before an identity can use protected cryptographic assets. |
Track every key and secret through issuance, rotation, and retirement, then retire orphaned credentials.
Key terms
- Cryptographic Custody: Cryptographic custody is the practical control over who can create, store, retrieve, rotate, or retire keys, certificates, and secrets. It is not just about encryption strength. If custody is fragmented across teams or tools, the organisation may still be secure on paper while exposure remains high in practice.
- Secrets Lifecycle: Secrets lifecycle is the end-to-end process for issuing, using, rotating, revoking, and retiring credentials such as API keys, tokens, and certificates. The lifecycle matters because static secrets create hidden access persistence. Effective governance makes lifecycle state visible and enforceable across both human and machine identities.
- Workload Identity: Workload identity is the identity assigned to a non-human system such as an application, service, or container so it can authenticate and access resources. It becomes a governance issue when the identity is long-lived, over-permissioned, or difficult to audit. Strong workload identity management reduces reliance on shared secrets.
- Certificate Rotation: Certificate rotation is the planned replacement of certificates before they expire or become risky. It is a lifecycle control, not just an operational task. Poor rotation discipline can create outages, stale trust, and hidden access persistence when old certificates remain valid longer than intended.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by ASPG: MegaCryption event listing for July 2. Read the original.
Published by the NHIMG editorial team on 2026-06-25.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org