Skip to content
Best IAM ToolsBest IAM Tools

LESSON 04 · THE FIVE JOBS

Privileged access basics: standing access, just-in-time grants and secrets

Short answer

Privileged access covers accounts that can change systems, read sensitive data or grant access to others: administrators, service accounts, emergency accounts and the secrets machines use. The job is to know where they are, grant them only when needed, and rotate what cannot be removed.

What counts as privileged?

NIST's glossary has an entry for a privileged account. In practice the list includes domain and cloud administrators, database owners, application admins, service accounts that run jobs, break-glass accounts kept for emergencies, and the API keys and tokens machines use.

Why is standing access the main risk?

A standing admin account is useful to an attacker every hour of every day, whether or not its owner is working. NIST defines least privilege as giving users only the access they need for their tasks. Just-in-time access applies the same idea to time: the right is granted when a task starts and removed after it. Apono describes just-in-time access to cloud resources.

What do vaults and rotation add?

Where an account must exist, its password or key can live in a vault and change regularly, so nobody holds a long-lived credential. CyberArk describes Secrets Manager as SaaS or self-hosted, the open-source Conjur project, and Secrets Hub for AWS Secrets Manager and Azure Key Vault, and says it can centrally rotate and manage credentials.

Are machine identities privileged too?

Often, yes. Service accounts and tokens can outnumber people. Orchid states, from its own telemetry, that 67% of non-human accounts are created directly within applications; that is a vendor figure, not ours. The OWASP Non-Human Identities Top 10 puts improper offboarding first (NHI1) and long-lived secrets seventh (NHI7). Silverfort describes behavioral baselines and virtual fences for service accounts.

What about admin accounts inside applications?

Many applications keep their own admin users outside the identity provider. They do not appear in the directory, so a vault cannot hold them until someone finds them. Orchid describes detecting local accounts and hardcoded credentials inside applications and bringing those applications under PAM control, and lists a CyberArk integration.

Where should you start?

  • List admin accounts per system, including local ones inside applications.
  • Remove standing access where a just-in-time grant would do.
  • Vault and rotate what remains.
  • Inventory machine secrets and name an owner for each.
  • Check what your identity provider includes: Okta lists Privileged Access in its Essentials suite.

Sources

Next lesson · L05

Identity threat detection and response explained

What ITDR watches, how it responds, and how it differs from the protections in your identity provider.