Governing Temporary and Privileged Access

1. Define the work to be done

Just-in-time access means making a permission available for a specific need rather than leaving it continuously assigned. It does not mean that every request should be approved immediately. The request still needs a purpose, appropriate authority and a defined scope.

Describe the task before selecting the permission. Does the engineer need to inspect logs, restart a service or change configuration? A broad administrator role may be convenient, but it can authorise more than the task requires. Where the target application offers only broad permissions, record that limitation and decide how the work will be supervised.

NIST SP 800-207 describes a resource-focused approach to access and rejects implicit trust based solely on network location or ownership. For temporary access, this supports checking the particular request rather than assuming an existing connection is enough. NIST SP 800-207: Zero Trust Architecture.

2. Approve an explicit access window

Record the requester, named user, target system, permission, justification and start and end conditions. The person asking for work is not always the person who will use the access. Avoid an approval that names only a supplier company when several engineers may act.

Define who can approve the permission and who covers their absence. Approval should remain connected to the actual application or business process. An unrelated manager may know the requester but not understand the consequences of elevated access.

At Westhaven, approval covers one warehouse application and one maintenance window. If the engineer later needs production database access, that is a different scope and should not be silently included in the original approval.

3. Confirm activation and operating boundaries

After approval, confirm that the intended access was granted to the correct account. Record the effective start time and the result of the target-system change. A successful request workflow does not guarantee that the engineer has the intended permission or that a broader permission was not granted.

Determine which system handles privileged sessions, logging and termination. Governance, authentication and privileged-session control have related but distinct responsibilities. Document how they connect in the deployed environment, including what happens if a component is unavailable.

IGAX’s website describes temporary access, time-limited privileged access, automatic revocation and privileged-session monitoring. Implementation planning should establish which connected systems perform each action and verify the supported behaviour for the selected application. IGAX platform capabilities.

Use approved operational procedures for monitoring. Decide who reviews unusual activity and what information they need. Avoid collecting session material without a defined purpose, access restriction and retention arrangement. These are deployment decisions, not consequences that follow automatically from enabling a request form.

4. Handle extensions and emergency access

Maintenance work sometimes runs longer than expected. An extension should identify the unfinished task, the new end time and the approving authority. Do not let repeated extensions turn temporary access into an informal standing entitlement.

Emergency access needs a prepared process. Decide which situations justify it, who may invoke it, how the activity is recorded and when the use is reviewed. Test the process before an incident. A procedure that depends on an unavailable approver or broken identity service may fail when it is most needed.

Keep the original approval and later changes distinguishable. The review should show what was initially authorised and why the final window differed. Replacing the original end time without a history weakens that explanation.

5. Verify the ending

Expiry is a control outcome, not merely a timestamp in a database. Check whether the permission was removed in the target system and whether other assignments still provide equivalent access. Depending on the application, existing sessions or tokens may require separate handling.

Test a failed revocation while the system is being introduced. The exception should identify the account, target, intended end time and owner responsible for restoring the approved state. The response may require an operational action outside the governance tool.

For Westhaven, completion includes evidence that the supplier’s elevated entitlement ended and that any required session termination occurred. The maintenance ticket can then refer to the access record. Retaining a supplier identity for future work is a separate decision from leaving its privileged permissions active.

• The end event was processed at the intended time.
• The target-system entitlement state was checked.
• Equivalent access through another path was considered.
• Failed removals have an owner and escalation.
• Remaining exceptions have a clear next review condition.

6. Review the pattern, not only individual requests

Look for repeated extensions, frequent emergency use and users who require privileged access for nearly every task. These patterns may reveal an unsuitable role design, a maintenance-process problem or an application that lacks sufficiently narrow permissions.

Measure the approved duration and verified duration separately. Review how often access remains active beyond the authorised window and why. Do not hide a significant exception inside an average that combines ordinary low-impact requests with privileged maintenance access.

Begin with a controlled application and a realistic support scenario. Prove the approval, activation, extension and revocation paths. The benefit comes from reducing unnecessary standing access while retaining a reliable way to complete legitimate work.