An access control pattern that allows or denies use of a resource only during a specified time window. It can be fixed, recurring, or event-driven. In practice, the control depends on accurate clocks, reliable policy enforcement, and fast revocation, otherwise the schedule exists on paper but not in operations.
Expanded Definition
Time Based Access Control is an access pattern that makes availability conditional on the clock, not just on identity or role. It is commonly used for maintenance windows, batch jobs, emergency elevation, and partner integrations that should only function during approved periods. In NHI and IAM programs, the term can overlap with scheduled entitlement activation, certificate validity, token lifetime, and event-driven revocation, so definitions vary across vendors. The key distinction is that the time condition is part of the authorisation decision itself, rather than a separate operational reminder. For that reason, the design depends on accurate time synchronisation, policy enforcement at the decision point, and reliable revocation when the window closes. NIST’s Cybersecurity Framework and the NHI governance guidance in Ultimate Guide to NHIs both reinforce that timing controls only work when enforcement is continuous, not advisory. The most common misapplication is treating a scheduled approval email as a control, which occurs when access is granted outside the policy engine and left to manual follow-up.
Examples and Use Cases
Implementing time based access control rigorously often introduces operational friction, because tighter schedules reduce standing exposure but increase dependency on reliable automation and clock integrity.
- A service account is allowed to authenticate only during a nightly ETL window, then blocked until the next run, limiting exposure if the account is abused outside processing hours.
- An emergency administrator token is valid for one hour during an incident bridge, then expires automatically to support just-in-time recovery workflows.
- A third-party API key is enabled only for a migration weekend, then revoked after the cutover, a pattern often discussed alongside the 52 NHI Breaches Analysis.
- A payment workflow permits machine-to-machine calls only during a certified maintenance window, aligning with time-bounded operational controls described in PCI DSS v4.0.
- A scheduled certificate or token is rejected once it falls outside its validity period, which is a basic time-gated access pattern rather than a discretionary approval.
Why It Matters in NHI Security
Time based access control matters because NHIs are often created for automation, then forgotten after the business event that justified them. When schedules are not enforced at the policy layer, expired access can remain usable, making a temporary workflow behave like a standing backdoor. This is especially dangerous for API keys, service accounts, and machine tokens, which are frequently overprivileged and rarely reviewed. NHIMG reports that 97% of NHIs carry excessive privileges, so adding a time window without revocation discipline only narrows the misuse window slightly. The governance lesson is that timing must be paired with logging, drift detection, and immediate disablement when the approved window ends. Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP Non-Human Identity Top 10 both frame this as a control integrity problem, not just a scheduling feature. Organisations typically encounter the risk only after a forgotten token is abused outside business hours, at which point time based access control becomes operationally unavoidable to address.
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 surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Time-windowed access depends on secret and token lifecycle discipline. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access should include when access is allowed, not only who gets it. |
| PCI DSS v4.0 | 8.3 | Access control and authentication timing are relevant to temporary privileged use. |
Enforce expiry, rotation, and revocation so time limits are real, not just documented.
