Yes. New secret or certificate creation can signal a new application connection or an unauthorised change, while expiry monitoring protects continuity for existing applications. Treating both events separately gives teams better visibility into access establishment and access continuity, which are different governance problems.
Why monitoring both creation and expiry captures two different governance signals
New secret or certificate creation is a change in access establishment. Expiry is a change in access continuity. If teams only watch one side, they miss either the moment a new credential appears or the point where a valid one is about to stop working. Those are different operational states, and they deserve separate alert logic.
Creation events are useful because they can reveal new integrations, emergency fixes, or unexpected credential issuance. In a healthy environment, the event should map to an approved request, a known owner, and a documented system or application relationship. The useful question is not just whether something was created, but whether its appearance fits the normal lifecycle of the application that now depends on it.
Expiry events matter because they expose continuity risk before production impact shows up. A credential can be legitimate and still fail at renewal, rotation, or replacement time. Monitoring expiry gives teams time to renew, reissue, or retire dependent applications in a controlled way rather than discovering the problem through an outage. That is especially important where certificates, API keys, or automation secrets are embedded in build, runtime, or integration paths.
What separate monitoring reveals about secret lifecycle and access change
Separate event monitoring helps teams distinguish between intentional lifecycle activity and unexpected drift. A newly created secret may indicate onboarding, rotation, migration, or a shadow integration. An approaching expiry may indicate a planned refresh, but it can also expose neglected ownership, weak inventory, or an untested recovery path. The signal is stronger when creation and expiry are interpreted together, because one tells you access was established and the other tells you whether that access is still sustainable.
For practitioners, this is also a control-design issue. If creation events are noisy and expiry events are buried, teams end up with gaps in both review and remediation. Rotation challenges for non-human identities become easier to manage when teams monitor the whole lifecycle, not just the end state. Likewise, secrets management guidance is strongest when it treats issuance, usage, rotation, and expiry as linked events rather than isolated checks.
Creation monitoring also supports better ownership and change control. When a credential appears outside the expected process, teams can ask whether it came from a deployment pipeline, a manual exception, or an unmanaged action. When an expiry warning appears, teams can check whether the credential is still actively used, whether the owner still exists, and whether replacement has been tested. That reduces both surprise creation and avoidable breakage.
How to operationalise the two signals without drowning in alerts
The practical rule is to route creation and expiry into different workflows. Creation alerts should go to change review, ownership confirmation, and inventory reconciliation. Expiry alerts should go to renewal planning, dependency checking, and failover validation. If both events use the same severity model, teams usually overreact to routine rotations and underreact to genuinely unexpected issuance.
Good monitoring also needs context. A certificate created during a controlled rollout is not the same as a secret minted by an unknown service account. An expiry event for a lab token is not the same as one for a production signing key. The most useful system tags each event with environment, owner, business service, and expected lifetime so the team can decide whether the event is routine, risky, or already overdue.
Where expiry is concerned, the key judgement is lead time. If expiry alerts arrive too late, they become outage notifications rather than governance controls. If creation alerts arrive without ownership data, they become noisy findings rather than actionable signals. The monitoring design should therefore answer three questions: who created it, what it supports, and when it stops being valid.
Risk and Threat Considerations
Monitoring only one lifecycle edge creates blind spots. Creation without expiry visibility can hide unauthorized issuance, while expiry without creation visibility can hide silent credential sprawl and unmanaged dependencies. In both cases, the organisation loses the ability to see whether access was intentionally established and whether it still deserves to exist.
Failure mechanism: An attacker or careless operator introduces a new secret outside normal control, or an existing credential reaches expiry without a verified replacement path. The first weakens governance and can support unauthorised access; the second can break production services or push teams into risky emergency workarounds.
Impact: The result can be unauthorized access, service disruption, failed rotations, or prolonged exposure of stale credentials. Over time, this also erodes inventory quality, ownership clarity, and trust in the alerting process itself.
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-53 Rev 5 and NIST SP 800-57 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Created secrets can expose unmanaged credentials and unexpected issuance. |
| NHI-07 — Long-Lived Secrets | Expiry monitoring directly addresses secret lifetime and renewal risk. | |
| Recommendation — Detect and investigate unexpected secret issuance and leakage paths. Set short lifetimes and alert before secrets outlive their intended cryptoperiod. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret creation and expiry are credential lifecycle controls. |
| AU-12 — Audit Record Generation | Creation and expiry events need auditable logging for review and response. | |
| Recommendation — Manage creation, distribution, rotation, and expiration of authenticators. Log credential issuance and expiration events for monitoring and investigation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Credential issuance and expiry are part of access governance and control. |
| Recommendation — Define and enforce controlled access lifecycles for secrets and certificates. | ||
| NIST SP 800-57 | 3.3 — Cryptoperiods | Expiry monitoring operationalises cryptoperiod management for certificates and keys. |
| Recommendation — Align renewal alerts with cryptoperiod and replacement windows. | ||
Practitioner Guidance
What to prioritise: Make creation alerts actionable by requiring an owner, an approved business service, and an expected lifetime. Make expiry alerts actionable by attaching dependency data so teams know whether a renewal will affect production.
What to verify: Before trusting either signal, confirm that the event source covers all credential types in use, including certificates, API keys, tokens, and automation secrets. If an event feed misses one class, the control is incomplete even if the dashboard looks busy.
Decision rule: If the event shows unexpected creation, treat it as a lifecycle and access-review problem first. If the event shows nearing expiry, treat it as a continuity and recovery problem first.
Practitioner takeaway: The best monitoring strategy separates “how access was established” from “how access stays valid”, because those questions drive different ownership, response, and remediation decisions.
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- How can organisations reduce the risk of stale API keys and machine tokens?
- What breaks when organisations only monitor sign-in events and ignore consent grants?
- What breaks when organisations do not monitor the browser layer for security events?