Standing Access for Computer Use

Many assume that granting a user permanent login credentials to a workstation is harmless because the user is trusted. The reality is that standing access creates a silent bridge for lateral movement, credential leakage, and untracked activity.

Standing access and its hidden dangers

When a user can log in to a computer at any time without re‑authentication, the organization loses visibility into when and how the machine is used. The credential often lives in a password manager, a shared local account, or an unattended service account. Because the connection bypasses any real‑time check, there is no audit trail of commands, no opportunity to block dangerous operations, and no way to mask sensitive output that might appear on the screen.

In practice this means that a compromised laptop can become a launchpad for further attacks, and compliance reviewers will struggle to prove who performed a privileged command. The problem is not the identity system that issued the token – it is the fact that the request reaches the target computer directly, without an intervening control point.

Why a gateway is required

Identity providers such as Okta or Azure AD can issue short‑lived tokens, but they do not examine the traffic that flows between the user and the workstation. The only place enforcement can happen is on the network path that carries the SSH or RDP session. A dedicated gateway can inspect the wire‑protocol, require just‑in‑time approval, and record every interaction before the packet reaches the host.

Centralizing policy in a gateway also simplifies management. Instead of scattering deny lists and approval workflows across dozens of servers, a single layer‑7 proxy enforces the same rules everywhere, ensuring consistent protection and a single source of audit data.

How hoop.dev enforces just‑in‑time control

hoop.dev acts as a Layer 7 gateway that sits between the authenticated identity and the computer being accessed. The setup phase provisions OIDC or SAML tokens, defines which groups may request a session, and deploys a lightweight agent inside the network where the workstation resides.

When a user initiates an SSH or RDP connection, the request is routed through hoop.dev. The gateway validates the token, checks the user’s group membership, and then applies policy before the session is allowed to continue. Because hoop.dev is the data path, it can enforce several outcomes:

• Record each session for replay and audit.
• Require just‑in‑time approval for high‑risk commands.
• Mask sensitive fields that appear in terminal output.
• Block commands that match a deny list before they reach the host.

All of these controls exist only because hoop.dev sits in the data path. Removing the gateway would restore the original standing‑access problem: the user would connect directly to the computer with no audit, no masking, and no approval step.

Practical steps to reduce standing access

1. Audit all permanent accounts on workstations and replace them with short‑lived tokens issued by your identity provider.

2. Deploy hoop.dev as the sole entry point for SSH and RDP traffic. Configure policies that require a fresh approval for any privileged command.

3. Enable session recording in hoop.dev so that every command is captured and can be replayed during investigations.

4. Use inline masking to ensure that secrets displayed on a console never leave the session logs in clear text.

5. Regularly review the audit logs produced by hoop.dev to spot anomalous usage patterns.

6. Integrate hoop.dev with your existing ticketing or approval system so that just‑in‑time requests are automatically routed to the right approvers.

Common pitfalls when removing standing access

Leaving legacy accounts untouched. Many teams delete the obvious admin accounts but forget service accounts that still have password‑based logins. Those hidden accounts become the new standing access vectors.

Relying on client‑side tools for approval. If the approval workflow runs on the user’s laptop, a compromised endpoint can bypass it. The approval must be enforced by the gateway, not the client.

Disabling logging to save storage. Without logs, you lose the ability to prove who did what. hoop.dev’s session records are lightweight and can be streamed to existing log aggregators, so there is no reason to turn them off.

Getting started

For a quick deployment, follow the getting‑started guide. The documentation walks you through deploying the gateway, registering a workstation as a connection, and defining just‑in‑time policies. Detailed feature information is available in the learn section.

FAQ

What exactly is standing access?
Standing access is a permanent credential that allows a user to connect to a computer at any time without additional approval or re‑authentication.

Can hoop.dev eliminate the need for standing credentials?
hoop.dev does not replace the identity provider; it adds a control layer that requires a fresh, policy‑driven approval for each session, effectively turning standing access into just‑in‑time access.

Does hoop.dev interfere with existing authentication mechanisms?
No. hoop.dev acts as a relying party for OIDC/SAML tokens and then proxies the connection. The original authentication flow remains unchanged.

How does session recording help with compliance?
Every command is captured, timestamped, and stored in a replay‑able format. Auditors can verify that privileged actions were authorized and see exactly what was typed.

Explore the open‑source code on GitHub to see how the gateway is built and to contribute your own enhancements.