Why Your IT Provider Requests Access Approval Every Time

TL;DR — Your IT provider is usually asking for approval each time because they are using just-in-time access (temporary admin access granted only when needed) instead of permanent standing access. This is usually the safer setup: it reduces the damage from stolen accounts, limits accidental changes, and gives you an approval trail; the main downside is a little extra delay when urgent work starts. Reading time: ~7 min

What it is and where it sits

When your IT provider asks you to approve access for a task, they are usually working inside a Privileged Access Management setup, often shortened to PAM (a system for controlling and recording high-risk admin access).

The specific pattern is usually just-in-time access (temporary access granted for a limited time) instead of standing access (always-on admin rights). In plain terms: your provider does not keep a permanent master key. They request the key when they need it, you approve it, the system grants access for a short period, and then it expires automatically.

This sits between your provider's staff and your systems:

• your cloud account
• your production servers
• your database admin tools
• your DNS or email admin console
• your identity provider, or IdP (the system that handles sign-in, such as Google Workspace, Microsoft Entra ID, or Okta)

What it replaces is the older model where an agency had:

• a shared admin password
• a permanent admin user in your systems
• a VPN account that never expired
• SSH keys (server login keys) left on laptops indefinitely

In a typical flow, the PAM or approval system lives in front of the privileged system. The engineer does not go straight to production. They first request access, the request is checked against policy, you or your internal admin approve it, and only then does the system allow the session.

[Provider Engineer] ---- 1. request admin access ----> [PAM/Approval]
[PAM/Approval] ---- 2. notify approver ----> [Customer Approver]
[Customer Approver] ---- 3. approve for 1 hour ----> [PAM/Approval]
[PAM/Approval] ---- 4. grant temporary role ----> [Cloud/Server/DB]
[Provider Engineer] ---- 5. do approved task ----> [Cloud/Server/DB]
[Cloud/Server/DB] ---- 6. logs/events ----> [Audit Trail]
[PAM/Approval] ---- 7. access expires ----> [Cloud/Server/DB]

Why this matters architecturally: the approval step is not just paperwork. It is the control point that decides whether privileged access is created at all. In many environments, the provider never even knows the real password. The PAM tool brokers the session, injects a temporary credential, or assigns a temporary role in the cloud account.

How it actually works

Let's walk one realistic example end to end.

Scenario: your software agency needs to fix a production issue in your cloud-hosted app. They need temporary access to your cloud console and database admin tools for one hour.

Step 1: The engineer opens an access request

Inside their support or PAM tool, the engineer creates a request like:

• reason: "Investigate production checkout errors"
• systems: production cloud project and production database
• access level: admin or read/write, depending on the task
• duration: 1 hour
• ticket reference: your support ticket number

Good systems force these fields because the point is not only to approve a person, but to approve a specific action for a limited time.

Step 2: You receive an approval request

You, or someone on your team, gets an email, dashboard notification, or chat message. It usually includes:

• who is requesting access
• what system they want to access
• why they need it
• how long access will last
• a button or link to approve or deny

In your provider's dashboard this may appear under something like:

• Access Requests
• Privileged Sessions
• Approvals
• Admin Access

If your systems are integrated with your own identity provider, the request may also route to your internal admin team instead of directly to a business contact.

Step 3: Approval triggers temporary privileges

After approval, one of a few common things happens behind the scenes:

• a temporary cloud role is assigned to the engineer's identity
• a short-lived session is created through the PAM tool
• a temporary password or token is generated
• an SSH certificate (a short-lived server login credential) is issued
• a VPN entitlement (permission) is enabled for a limited time

The important detail: access is time-bound and usually scoped to one environment, such as production only, or one database only.

Step 4: The engineer performs the work

Now the engineer signs in using their own named account, not a shared "admin" login. Their actions are tied to their identity.

That means your logs can usually show:

• who accessed the system
• when they started
• what they changed
• when the session ended

In stronger setups, the session is also recorded, especially for remote desktop or shell access.

Step 5: Access expires automatically

At the end of the approved window, the temporary role or credential expires. If the work is not finished, the engineer must request another approval.

This is the part customers often notice and ask about: "Why do I have to approve again? You were just in there yesterday."

The answer is that repeated approval is the feature, not a bug. It prevents yesterday's emergency access from silently becoming permanent access.

Step 6: Audit trail remains

Later, if there is a question about a change, you can tie it back to:

• the request
• the approver
• the time window
• the engineer
• the activity logs

That is useful for security, but also for normal business accountability.

When to use it (and when not to)

If your provider touches production systems, customer data, finance systems, email admin, or DNS, repeated approval is usually a good sign.

If they only work in a low-risk sandbox or on code in a source repository, it may be unnecessary overhead.

You probably don't need this if...

• your provider never logs into production directly
• all changes happen through reviewed code deployments
• the environment contains no sensitive data
• downtime from a mistaken admin action would be low impact
• you are the only admin and you are comfortable with the risk of permanent external access

You probably do need this if...

• the provider can read or change customer data
• they can alter billing, email, DNS, or authentication settings
• you have compliance requirements
• more than one engineer at the provider may need access over time
• you want the ability to revoke access cleanly when contracts or staff change

Trade-offs

This model is safer, but it is not free.

A practical way to think about it: you are trading a little convenience for a big reduction in silent, hard-to-see risk.

The most common failure mode is not technical. It is operational: nobody is available to approve access during an incident. If your provider supports critical systems, solve that with an on-call approver process, not by giving up and leaving permanent admin access in place.

In practice

Below are two concrete examples of what this looks like in real systems. You may not run these yourself, but they show the mechanics your provider is trying to put around access.

Example 1: Temporary cloud role assignment

This is the pattern many cloud environments use: grant a role to a named user for a limited period, then remove it.

# Grant a user temporary access by adding them to an admin group
# Exact commands vary by provider and identity system.
# Example pattern using a group-managed approach:

# 1) Add the engineer to a privileged group
# 2) Record the expiry time in the ticket or approval system
# 3) Remove them when the window ends

# Example with a generic directory CLI pattern:
directory-cli group members add prod-admins engineer@provider.example

# Later, when the approved window ends:
directory-cli group members remove prod-admins engineer@provider.example

What it does: this gives the engineer admin rights indirectly through a group instead of handing out a shared password. Gotcha: if the removal step depends on a human remembering, access can linger; the safer pattern is automatic expiry in your identity or PAM system.

Example 2: Sudo rules for time-limited admin commands on Linux

If your provider accesses a Linux server, they may use a named account plus sudo (run a command as admin) instead of direct root login.

⚠️ Editing sudo rules incorrectly can lock admins out of a server or grant broader access than intended. Test changes in a non-production server first, and edit with visudo where possible because it checks syntax before saving.

# /etc/sudoers.d/provider-support
# Allow a named support user to restart nginx and view logs
# without giving full root shell access.

User_Alias PROVIDER = support_engineer
Cmnd_Alias WEBOPS = /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx

PROVIDER ALL=(root) WEBOPS

What it does: this limits the engineer to two specific admin actions instead of full server control. Gotcha: this file does not create expiry by itself; the expiry must come from disabling the account, removing the SSH certificate, or using a PAM tool that only enables the account for the approved window.

Example 3: Approval record stored as structured data

Even if the approval happens in a web UI, good systems store it in a structured way so it can be audited later.

{
  "request_id": "AR-10482",
  "requested_by": "engineer@provider.example",
  "approved_by": "ops-manager@customer.example",
  "system": "production-postgres",
  "access_level": "read_write",
  "reason": "Investigate failed order writes",
  "approved_at": "2026-10-30T09:15:00Z",
  "expires_at": "2026-10-30T10:15:00Z",
  "ticket": "INC-3817"
}

What it does: this is the minimum useful audit record for privileged access. Gotcha: if your process only keeps chat messages like "approved" without system, duration, and requester identity, you will have a weak audit trail when you need it most.

Further reading

• NIST SP 800-53, the "Access Control" and "Audit and Accountability" families
• NIST SP 800-63 Digital Identity Guidelines
• CIS Controls, the sections on Account Management and Access Control Management
• The "Authentication" and "Access Control" sections of the OWASP Cheat Sheet Series
• The "sudoers" manual page and the visudo documentation

This article was written by an AI system and published pending human review. Verify anything you intend to act on.