{
"slug": "privileged-access-management-pam-under-attack-gating-just",
"topic_id": "TOPIC-029",
"cluster": "Privileged Identity & Help-Desk Takeover",
"tier": "Tier B",
"title": "Just-in-time elevation issues a credential, not a control",
"summary": "Privileged access management narrowed the window in which administrative power exists. Inside that window it is still unrestricted, and the window is usually hours long.",
"lede": "An engineer requests elevation, an approver clicks yes, and a credential appears that can do anything the role permits for the next eight hours. The improvement over standing access is real. The remaining gap is everything that happens after the yes.",
"date": "2024-12-27",
"category": "Developer",
"author_id": "desmond-okafor-hale",
"tags": [
"PAM",
"privileged access",
"just-in-time",
"elevation",
"audit",
"cloud IAM"
],
"image_title": "Just In Time Elevation Gap",
"schema": "Article",
"key_takeaways": [
"JIT elevation bounds when privilege exists. It does not bound what is done with it during the window.",
"The approval is attached to a request for a role, not to the operations subsequently performed under it.",
"Signing the operations that matter — not the elevation — gives per-action evidence without reintroducing approval friction on everything."
],
"body": [
{
"type": "h2",
"text": "What JIT fixed and what it left"
},
{
"type": "diagram",
"kind": "compare",
"alt": "What JIT fixed and what it left",
"caption": [],
"nodes": "The last two rows are the ones an auditor asks about after an incident.",
"left": {
"title": "Fixed",
"items": [
"Privilege no longer permanent",
"Bounded time window",
"A request is reviewed",
"Better than standing access"
]
},
"right": {
"title": "Not fixed",
"items": [
"Individual operations unauthorised",
"Scope creep invisible",
"A stolen elevated session is maximal",
"Evidence at the wrong granularity"
]
}
},
{
"type": "table",
"head": [
"Problem",
"Standing access",
"JIT elevation"
],
"rows": [
[
"Privilege exists permanently",
"Yes",
"No — bounded window"
],
[
"Anyone with the account can use it",
"Yes",
"Only during the window"
],
[
"A request is reviewed",
"No",
"Yes, once, for the role"
],
[
"Individual operations are authorised",
"No",
"No"
],
[
"Evidence of who did what",
"Access logs",
"Access logs"
]
]
},
{
"type": "p",
"html": "The last two rows are unchanged, and they are the rows an auditor asks about after an incident."
},
{
"type": "h2",
"text": "The granularity mismatch"
},
{
"type": "p",
"html": "An elevation request is a sentence: I need production database admin to investigate the replication lag. An approver reads it and agrees."
},
{
"type": "p",
"html": "What the credential then permits is the entire role. In a typical cloud environment that is hundreds of API operations, including many with nothing to do with replication lag — exporting the dataset, altering retention, creating new credentials."
},
{
"type": "p",
"html": "The approver did not authorise those. They authorised a stated purpose, and the enforcement layer has no representation of purpose."
},
{
"type": "h2",
"text": "Three consequences"
},
{
"type": "ol",
"items": [
"Scope creep is invisible. Nothing distinguishes the operations related to the stated purpose from the ones that are not. Both look like authorised use.",
"A stolen elevated session is maximally valuable. The window is the attacker's window too, and everything inside it is permitted.",
"Evidence is at the wrong granularity. You can show the role was granted. You cannot show a human intended the specific destructive operation."
]
},
{
"type": "h2",
"text": "Signing operations rather than elevations"
},
{
"type": "p",
"html": "The productive inversion: leave elevation as it is, and put the signature on the small number of operations that are consequential."
},
{
"type": "code",
"text": "# Elevated session is active. The operation is still gated.\n\n$ aws rds delete-db-snapshot --db-snapshot-identifier prod-2026-04-01\n\n This operation requires a signed authorisation.\n\n Operation: rds:DeleteDBSnapshot\n Account: prod (4471-8823-9910)\n Snapshot: prod-2026-04-01 (1.4 TB, taken 13 days ago)\n Retention: no other snapshot within 13 days\n Requested: d.okafor@example.com at 14:22 UTC\n\n Touch your security key to authorise.\n\n→ receipt stored with the operation; verifiable offline"
},
{
"type": "p",
"html": "The engineer works normally inside their elevated session. The prompt appears only for operations on the gated list, which in practice is a handful per role."
},
{
"type": "h2",
"text": "Choosing the gated list"
},
{
"type": "p",
"html": "Three questions per operation, and the answer is usually obvious."
},
{
"type": "table",
"head": [
"Question",
"If yes"
],
"rows": [
[
"Can this be undone from inside the system?",
"Not gated — the cost of a mistake is bounded"
],
[
"Does it move money, change who can access, or destroy data?",
"Gate it"
],
[
"Would you want a name attached to it in a post-incident review?",
"Gate it"
]
]
},
{
"type": "p",
"html": "A typical infrastructure role produces five to fifteen gated operations. That is a tractable prompt volume — a few times a week rather than a few times an hour."
},
{
"type": "h2",
"text": "What this changes for an auditor"
},
{
"type": "p",
"html": "The question \"who authorised this deletion\" currently resolves to a chain: a log line, an account, a session, an elevation request, an approval in a ticketing system. Each link requires trusting a different system's records."
},
{
"type": "p",
"html": "With a per-operation receipt it resolves to one artefact that verifies against a published key. The chain collapses, and it collapses in a way that does not depend on the integrity of the systems being audited."
},
{
"type": "h2",
"text": "Two things this does not do"
},
{
"type": "p",
"html": "It does not stop an authorised engineer from doing something harmful deliberately. It attributes it, which is a different and more achievable goal."
},
{
"type": "p",
"html": "It also does not replace PAM. Bounded elevation windows, session recording and approval workflow all remain useful. This adds per-operation evidence to a system that produces per-session evidence, and the two answer different questions."
},
{
"type": "h2",
"text": "Choosing the gated set"
},
{
"type": "table",
"caption": "Three questions per operation",
"head": [
"Question",
"If yes"
],
"rows": [
[
"Can this be undone from inside the system?",
"Not gated — the cost of a mistake is bounded"
],
[
"Does it move money, change access, or destroy data?",
"Gate it"
],
[
"Would you want a name attached in a post-incident review?",
"Gate it"
]
]
},
{
"type": "p",
"html": "A typical infrastructure role produces five to fifteen gated operations — a prompt a few times a week rather than a few times an hour, which is what keeps it readable."
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“This reintroduces the friction JIT removed.” Only on the gated operations. Routine work inside the elevated session is untouched, which is the point of gating operations rather than elevations."
},
{
"type": "p",
"html": "“Does this replace PAM?” No. Bounded windows, session recording and approval workflow all remain useful. This adds per-operation evidence to a system that produces per-session evidence."
}
],
"faq": [
{
"q": "Doesn't this reintroduce approval friction?",
"a": "Only on the gated operations — typically five to fifteen per role, hit a few times a week. Routine work inside the elevated session is unchanged."
},
{
"q": "Should we stop using PAM?",
"a": "No. Bounded windows and session recording remain valuable. This addresses a different question: what specific operation did a specific human intend."
},
{
"q": "How do you decide what to gate?",
"a": "Operations that cannot be undone from inside the system, that move money or access, or that you would want a name attached to in a post-incident review."
},
{
"q": "Does this prevent insider misuse?",
"a": "No. It attributes it to a named human with non-repudiable evidence, which is achievable; preventing a determined authorised insider is not."
},
{
"q": "Does this reintroduce friction?",
"a": "Only on five to fifteen operations per role, hit a few times a week. Routine work inside the session is unchanged."
},
{
"q": "Does it prevent insider misuse?",
"a": "No. It attributes it to a named human with non-repudiable evidence, which is achievable; preventing a determined authorised insider is not."
}
],
"sources": [
{
"t": "Cloud provider documentation on temporary credentials and role assumption."
},
{
"t": "NIST SP 800-53 Rev. 5 — Security and Privacy Controls",
"u": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"
},
{
"t": "AWS — temporary security credentials and role assumption",
"u": "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html"
},
{
"t": "Audit framework requirements for privileged operation evidence."
},
{
"t": "CISA — implementing phishing-resistant MFA",
"u": "https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa"
},
{
"t": "W3C Web Authentication Level 3",
"u": "https://www.w3.org/TR/webauthn-3/"
}
],
"related": [
{
"slug": "okta-cross-tenant-impersonation-architectural-lessons-2023-support",
"title": "Support access and standing authority",
"category": "Developer"
},
{
"slug": "servicenow-ticket-manipulation-preventing-unauthorized-admin-elevation",
"title": "When the approval record is a database row",
"category": "Developer"
},
{
"slug": "illusion-zero-trust-network-microsegmentation-fails-against",
"title": "The illusion of Zero Trust",
"category": "Developer"
}
],
"image": "https://cdn.twc.sh/images/igcache/Just%20In%20Time%20Elevation%20Gap/1200_630/blog.jpg",
"wordcount": 900,
"url": "/blog/privileged-access-management-pam-under-attack-gating-just.html",
"reading_time": "4 min read",
"meta_description": "Just-in-time access narrowed the window in which admin power exists. Inside that window it is unrestricted, and the window is hours long.",
"hub": {
"slug": "topics/privileged-identity",
"title": "Privileged identity and account recovery"
},
"answer": "What you do with the privilege. JIT narrowed when administrative power exists, which was a real improvement over standing access. Inside the window it remains the entire role — hundreds of API operations, most unrelated to the stated purpose — and the approval was attached to a sentence.",
"answer_q": "What does just-in-time elevation not bound?",
"glossary": [
{
"term": "Just-in-time elevation",
"def": "Granting privilege temporarily on request rather than permanently."
},
{
"term": "Scope creep",
"def": "Using elevated access for operations unrelated to the stated purpose — invisible because both look like authorised use."
},
{
"term": "Per-operation evidence",
"def": "A receipt tied to one action rather than to the session it happened in."
}
],
"checklist": {
"title": "Adding per-operation gating",
"id": "gate",
"desc": "Four steps.",
"steps": [
{
"name": "List the destructive operations per role.",
"text": "Five to fifteen is typical."
},
{
"name": "Render the effect, not the command.",
"text": "Account, resource, size, recoverability."
},
{
"name": "Require a signature at the operation.",
"text": "Inside the elevated session, not at elevation."
},
{
"name": "Store the receipt with the operation record.",
"text": "So the audit question resolves to one artefact."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "Manav requires a fresh assertion bound to the specific action, from a credential under the person's sole control. A stolen session reaches the endpoint and cannot produce it.",
"href": "../docs.html",
"label": "See step-up gating"
}
}