On-call is an access state

Production access tends to be broader than anyone intended, and it usually got that way through a defensible decision. An engineer needed to reach a database during an incident, the access was granted, and nothing ever removed it. The permission was justified at the moment it was created, and the justification was never given an expiry.

Nobody wants to be the person who blocked a production recovery over a permission, which is why this pattern is so durable. The missing half of the decision is not whether the access was warranted. It is how long it should outlive the incident that warranted it.

Least privilege has a second axis

Least privilege is almost always discussed as a question of how many people hold a sensitive permission. Reduce the count, close the finding, and the environment is considered better controlled.

Duration is the other axis, and it is rarely measured at all. If an engineer needs elevated production access for eight hours every third week, a permanent grant means the permission exists without an active operational reason for almost its entire life. The headcount in the access review looks identical either way, and the exposure does not.

Periodic reviews are the wrong instrument for this. They describe the estate on the day someone runs the report, and everything about the grant checks out on that day: the person is an engineer, they take part in the on-call rotation, and they do sometimes need production. A privilege that should have lasted a shift and lasted eleven months instead passes every review in between. What the review cannot ask is whether today is one of the days they should have it.

Something in the environment already knows the answer to that question.

The schedule already knows who is responsible

Any organization running formal production support maintains an on-call rota, and it is maintained accurately for reasons that have nothing to do with security. If the schedule is wrong, someone gets paged who is asleep and someone who is awake does not. That operational pressure is exactly what makes the rota more trustworthy as an authorization source than a list a security team curates by hand.

The mechanism itself is small. A scheduled job reads the currently active participant from the incident management platform and writes that person into a dedicated group in the identity provider. The group is attached to the additional policy rules that expose production. When an engineer comes on call the extra destinations appear, and when the rotation moves on the next run removes them again.

The interval that job runs on deserves an explicit decision. At a fifteen-minute sync, a rota change should reach the access policy within a quarter of an hour under normal operation. That interval is not implementation trivia; it defines the stale-entitlement window the design is prepared to accept, before any downstream propagation delay or a run that does not complete. It should be chosen against the response targets it is meant to support rather than inherited from whatever the scheduler defaulted to.

The same mechanism absorbs the changes that arrive mid-shift. When an incident overruns a rotation and the responder stays on, the extension is recorded in the rota, because that is where it has to be recorded anyway for paging to keep working. The entitlement follows from the same edit. There is no second workflow for extending a permission and therefore nothing that can drift away from operational reality, which is a stronger property than the convenience it looks like at first.

Underneath all of it sits the point that makes the design worth building. Granting access during an incident is a task with a highly motivated person driving it to completion. Removing it afterwards is a task with nobody chasing it. Tying the entitlement to the rota removes the half that human attention reliably fails to cover.

What the access decision is made from

Department / Team / Squad Baseline group

Baseline, always present Standing membership from the role · Unchanged when a shift begins or ends

On-call rota Scheduled sync · On-call group

Access policy

Permitted destinations Baseline set, plus the elevated set while on call

Elevation, only while responsible Example: 15-minute sync, and the interval defines the stale-entitlement window · Shift ends, membership removed, elevated destinations withdrawn, baseline untouched

What changes between the two states Only the additional production destinations appear and disappear · The role’s own access is never replaced or restored

Device posture, required on every path

• Managed endpoint
• Disk encryption
• Endpoint security running
• Managed-device certificate

Neither identity nor on-call membership bypasses posture: the correct user, in the correct group, on an unmanaged device reaches nothing.

Make on-call access additive

The instinct is to define a complete on-call policy, with its own destination list, that stands in for the engineer's normal access during a shift. It is worth resisting. Two overlapping destination sets covering the same infrastructure will drift apart, and the drift surfaces during an incident.

The version that holds up is additive. Standing access continues to come from the person's department, team or squad, exactly as it does on any other day. The on-call group grants only the destinations that become necessary while someone is responsible for production, and nothing else. If that group carries twenty destinations, those twenty destinations are the complete definition of what changes when a shift begins, readable in one sitting and explicable to an auditor without a diagram.

Demotion then becomes trivial to reason about, because nothing was replaced when the shift started and nothing has to be restored when it ends. Removing the group membership withdraws the additions and leaves the engineer on the access their role already provides. The automation never touches the baseline, so a failure in the elevated path cannot cost anyone their ordinary working access.

None of this helps if reaching the private network already means reaching everything behind it. The prerequisite is considerably less interesting than the automation: organizational groups that mean something, provisioned into the access platform, and a matrix describing which of them reaches which destination. Temporary elevation is a refinement of that model rather than a substitute for building it.

Two decisions remain for whoever implements the pattern, and neither has a default answer. Where several rotas feed one elevated group, the real question is whether those responsibilities justify the same destinations, and sometimes the honest answer is separate groups with different reach. Similarly, reading only the primary participant excludes secondary and escalation responders, which is an authorization decision about who is genuinely accountable during an incident rather than a detail of how the integration was written.

Group membership is not the whole decision

Knowing who is responsible answers one question and says nothing about what they are connecting from. A posture check closes that gap by requiring the endpoint to meet defined controls before the connection is allowed: disk encryption, endpoint security running, and a certificate that only ever reaches managed devices. The correct user, in the correct group, on a personal laptop, still reaches nothing.

Whether that check runs once or repeatedly determines how much it is actually worth. A test performed at connection describes the device at a single moment, and a long-lived session can easily outlive the state it was granted on, with security tooling disabled an hour in and the tunnel carrying on because nothing asks again. Where the platform supports it, posture should be re-evaluated throughout the session, so that a device drifting out of compliance loses access without waiting for the user to reconnect.

The certificate needs the same scrutiny, because it is the control most often implemented in a form that does not hold. If the private key can be exported and copied to another machine, the check proves that a file exists rather than that the endpoint is managed. Binding the key to the device or to hardware, where that is available, is what turns it into evidence of management.

A sync nobody watches is not a control

Automation that removes privilege fails differently from automation that grants it. If the synchronization stops running, nobody is locked out, nothing visibly breaks, and no ticket gets raised. The group simply freezes with its last known membership and everyone in it keeps elevated access indefinitely, which is precisely the condition the design was built to prevent, reached in silence.

That makes the health of the job part of the security control rather than an operational concern beside it. Filling a channel with a message after every successful run produces noise that people learn to ignore within a month. Monitoring freshness works better: if no successful synchronization has completed within the expected interval, alert. The absence of activity is the signal worth detecting, and it needs somewhere to surface.

The job also needs a defined behavior for the case where the schedule returns no participant at all. Holding the last known state protects availability during an incident, at the cost of preserving privilege that can no longer be verified. Clearing the group limits that privilege, at the cost of possibly removing access from whoever is mid-incident. Neither is correct everywhere. What matters is that the choice is deliberate, tested against a real empty response, and visible when it happens.

There is a quieter failure alongside it. If the synchronized group can be edited by hand, eventually it will be, usually once and under pressure, and the rota stops being the source of truth while every console continues to look correct. Under normal operation the group should be writable only by the automation. An emergency administrative path can legitimately exist alongside that, provided it is explicit, auditable and temporary rather than a standing permission somebody happens to hold.

Test where access actually disappears

Removing someone from a group and removing their access from an established session are two different events, and the second is the one that matters. The useful question is not whether the workflow updated the membership. It is whether the user can still reach the elevated destination.

That is directly testable. Connect with a test account, confirm a production destination is reachable, remove the account from the on-call state, wait one synchronization interval, then try the same destination again on the same session without reconnecting. Whatever comes back is the real revocation time of the system, as distinct from the interval on the scheduler, and it is the number to quote when someone asks how quickly access ends.

The rota covers the planned case and will never cover all of them. Someone outside the rotation occasionally needs production for an hour, and the temptation is to add them to the on-call group manually and clean up later. An exception path is legitimate, provided it carries the same property as the mechanism it sits beside, which is that the grant ends on its own rather than by someone remembering. A time-limited request with an approval step is one way; the implementation matters far less than the expiry.

Once the rota drives the entitlement, a useful side effect appears without anyone designing for it. Reconstructing who could reach production on a particular date no longer requires assembling a report, because the operational record already contains it. The system that records who should be paged is also the source driving who receives the access, so responsibility and entitlement are derived from the same operational history rather than maintained as two independent accounts of the same day.

Least privilege is usually framed as a question about who. For production support, the more useful question is when, and another system in the environment has already answered it.

Explore this expertise: Identity & Access Management

All technical notes