AccessOps

AccessOps, as this Atlas uses the word, is the operation of access at the moment it is needed: how a person asks for access beyond their birthright (what a job role receives automatically on joining, run by IdentityOps), who or what approves it, how it is granted for a limited time, how a privileged session is recorded, how it ends, and how someone later checks it. Most rigour goes to privileged access. The target: fast access when needed, no standing access otherwise, every privileged action attributable to a person.

NSA and CISA give the reason: privileged accounts “should be separately managed using a Privileged Access Management (PAM) solution”, and just-in-time provisioning “reduces the number of privileged accounts that an attacker could target”^[1]. For engineers who need production access, the IAM teams running the tooling, and auditors.

The usual starting point is standing privilege: an admin group, a shared root password, a cloud role everyone holds “just in case”. The documented cases show the cost: a stolen session inherits everyday production rights, too many people can use powerful tools, vendor access is hard to bound, and secure emergency access can slow recovery. Ordinary access has a quieter version: project access never taken back. Symptoms: admin groups that only grow, approval by whoever answers a chat, untested break-glass passwords, hundreds of review lines approved in minutes.

• Not identity lifecycle or sign-in (joiner-mover-leaver, birthright, single sign-on (SSO), MFA, the identity governance and administration (IGA) platform): IdentityOps.
• Not permission design (least-privilege roles, role- or attribute-based access control (RBAC/ABAC), policy as code): IAMOps. AccessOps decides when a role is active and how that is approved and recorded.
• Not audit evidence mapping (ComplianceOps) or detection (DetectionOps, SOC Ops); AccessOps produces their records. Not a product category or physical security.

“AccessOps” has no founding document; the practices matured separately. NIST SP 800-53 restricts, reviews and logs privileged accounts and removes temporary and emergency accounts “after a predefined time period rather than at the convenience of the system administrator” (AC-2(2))^[9]. Zero trust moved the unit of access to the session: “Access to individual enterprise resources is granted on a per-session basis” (NIST SP 800-207, 2020)^[10]. CISA’s Zero Trust Maturity Model 2.0 (2023) added an “Access Management” function whose top stage authorises “just-in-time and just-enough access”^[11]. Cloud platforms built elevation in: Entra Privileged Identity Management (PIM)^[12], Google Cloud Privileged Access Manager^[13], AWS IAM Identity Center with partner tools or an open-source sample^[14][15].

The mental model: privileged access is a loan. Every grant needs five fields — who, what scope, why, until when, approved by whom (or which rule) — and the system, not the borrower, ends it. Each loan passes four moments: request, elevate, use, review. Most failures are a missing field or moment.

stateDiagram-v2
  direction TB
  [*] --> Eligible: entitlement defined
  Eligible --> Requested: request with reason
  Requested --> Denied: approver says no
  Requested --> Active: approved, or rule auto-approves
  Active --> Expired: time limit reached
  Active --> Revoked: task done early or incident
  Expired --> Eligible: use sampled against reason
  Revoked --> Eligible: use sampled against reason
  Denied --> [*]
  Eligible --> Removed: review campaign says no
  Removed --> [*]

flowchart TB
  ID["IdentityOps"]
  IAM["IAMOps"]
  INC["IncidentOps"]
  CHAT["ChatOps"]
  END_["EndpointOps"]
  ACC["AccessOps: how and when"]
  ID -->|"who exists"| ACC
  IAM -->|"what a role may do"| ACC
  INC -->|"on-call schedule"| ACC
  CHAT -->|"requests"| ACC
  END_ -->|"privileged workstation"| ACC
  ACC -->|"evidence"| CMP["ComplianceOps"]
  ACC -->|"logs, alarms"| DET["DetectionOps, SOC Ops"]
  ACC -->|"what is recorded"| PRV["PrivacyOps"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class ACC core
  class ID,IAM,CMP,DET,INC,CHAT,END_,PRV neutral

Mission. Engineers get the access a task needs within minutes, nobody holds privileged access they are not using, and every privileged action traces to a person, a reason and an approval.

1. Eligible, not active. Few named exceptions; break-glass accounts are one, since Microsoft assigns their Global Administrator role “as permanent active (not eligible)”^[19].
2. Five fields per grant, with a structured reason; generic reasons like “Team foo needed access” should “set off alarm signals”^[18].
3. The system ends access (SP 800-53 AC-2(2)). Standing break-glass accounts are its accounts of last resort, which “remain available and are not subject to automatic disabling or removal dates”^[9].
4. A grant is not a session. Bound session lifetime; keep a way to end sessions (what expiry really ends).
5. Friction in proportion to impact. Classify access by what it can damage^[18].
6. Approvers can say no: “make sure the technology and social dynamics allow someone to say no”^[18].
7. The emergency path is independent, loud and rehearsed^[20].
8. Evidence by default, stored off the host where the action happens. Non-goals: identities, permission design, audit mapping, detection (what it is not).
9. Frequent requests are a design signal: Google reads breakglass need as a sign that a safer API is missing^[18].

The resource owner decides eligibility and maximum duration; the access platform team runs broker, issuers, vault, gateway and break-glass kit; security operations answers alarms (SOC Ops); compliance samples evidence, never approves access.

R = responsible, A = accountable, C = consulted, I = informed. “Owner / approver” is the resource owner or their delegated approvers; the platform runs campaign tooling, the owner answers for outcomes. In a small company one person holds several columns; approver and requester still differ.

Day 0 designs tiers, entitlements and the break-glass kit; Day 1 converts one team and measures time to access; Day 2 runs reviews, drills and break-glass reviews and automates frequent requests (roadmap).

Access tiers (an Atlas proposal):

Cadences:

• Break-glass use: security operations confirms each use within one business day; the owning team discusses it at its next meeting (Google’s practice^[18]).
• Metrics mostly monthly (per-KPI cadence); privileged eligibility quarterly.
• Other access at least annually: the floor in CIS Safeguard 6.8 (Implementation Group 3)^[25] and, for New York-regulated financial firms, 23 NYCRR 500.7^[26].
• Exceptions: an owner and an end date.

flowchart TB
  REQ["Engineer or service: request with reason"]
  APP["Approvers, on-call schedule, ticket system"]
  BRK["Access broker: catalogue, policy, approvals"]
  VLT["Credential vault: checkout, rotation, injection"]
  ISS["Grant issuers: role binding, group, short-lived certificate"]
  GW["Session gateway: proxy and recording"]
  TGT["Targets: cloud, hosts, databases, clusters"]
  BG["Break-glass kit: separate path"]
  EVD["Evidence store and SIEM"]
  REV["Review engine: campaigns"]
  REQ --> BRK
  APP --> BRK
  BRK --> VLT
  BRK --> ISS
  VLT --> GW
  ISS -->|"certificates"| GW
  GW --> TGT
  ISS -->|"cloud role bindings"| TGT
  BG -.-> TGT
  BRK --> EVD
  GW --> EVD
  TGT -->|"audit logs"| EVD
  BG --> EVD
  EVD --> REV
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class BRK,ISS,GW core
  class BG,VLT risk
  class REQ,APP,TGT,EVD,REV neutral

sequenceDiagram
  autonumber
  participant A as Approver
  participant B as Access broker
  participant E as Engineer
  participant T as Target via gateway
  E->>B: Request role, 2 h, ticket
  B->>A: Approve? (context shown)
  A->>B: Approved
  Note over B: Logs request and decision
  B->>E: Grant active until expiry
  E->>T: Recorded session
  Note over T: Record streamed to SIEM
  Note over B: Expiry: grant removed, logged
  Note over T: Open session ended, if configured
  B->>A: Weekly review sample

Happy path: a rule checks the ticket, an approver who did not raise it approves, the grant starts and ends, the session is sampled in review. Exception paths: no approver answers → escalate to a second group after a fixed time (AWS asks for approvals that “operate effectively both inside and outside business hours”^[20]); on-call engineer → auto-approve a short Tier 1 grant; broker or identity provider down → break-glass; task done early → end the grant (a Google Cloud PAM preview, October 2026^[13]).

Removing a role ends the grant. Sessions and credentials issued during it may continue, removal takes time to spread, and whatever the holder created with it stays.

On-call access. Google’s SRE authors describe temporary access granted “during on-call rotations, or via expiring group memberships”^[18]. Teleport’s PagerDuty plugin automates it, approving whoever is on call for a service named in the role’s pagerduty_services annotation^[21]. Preconditions: PagerDuty joins the approval path, since whoever can edit schedules, escalation policies or user e-mail addresses can make someone “on call” (restrict and log those rights; alert on a schedule change followed by a request); the Teleport username must be “the email address associated with a PagerDuty account”. The walkthrough approves “any requests from users on the on-call team” and shows no check that an incident is open^[21].

Break-glass. Microsoft’s Entra guidance is a concrete public baseline (October 2026): two or more cloud-only accounts with phishing-resistant authentication unlike normal admins’, excluded from blocking Conditional Access policies, alerted and reviewed on every use, validated “at least every 90 days”^[19]. AWS adds that the path must not depend on the normal identity provider and “can be considered a backdoor”^[20].

Most requested access is not privileged (a group, an application role, a data set); the same loan applies with less friction. Microsoft’s entitlement management bundles resources into “access packages” whose policies set “which identities can request, who must approve their access, and when access expires”^[35], and can refuse requests incompatible with access already held^[36].

1. Catalogue: publish what can be requested, each item with an owner and tier (mostly Tier 2–3).
2. Default expiry: every requested assignment ends unless renewed (this page suggests 90 to 180 days).
3. Separation of duties at request time: block incompatible pairs (raising and approving payments) before approval.
4. Approver: the resource owner, not the requester’s manager by default.
5. Birthright feedback: when most of a team requests the same item, propose it as birthright to IdentityOps.

Acceptance: no requested assignment without an end date; conflicts blocked, not flagged.

A vault beats JIT roles where the target has no personal identities: network devices, appliances, local administrator, database owner and service accounts. Rotation after use is a product feature: Vault’s LDAP engine “automatically rotates the associated password when the client checks the service account back in”^[37]; Windows LAPS can rotate a local administrator password after use, following a grace period^[38].

Example status: syntax-checked (bash -n); not executed (needs a Vault server with the LDAP secrets engine). Paths and parameters follow HashiCorp’s documentation, October 2026^[39][40]; the set’s ttl caps any requested lease.

# Two shared admin accounts: 1-hour lease by default, 4 hours with renewal at most;
# only the client that checked an account out may check it in.
vault write ldap/library/netops-admins \
  service_account_names="netadm1@example.com,netadm2@example.com" \
  ttl=1h max_ttl=4h disable_check_in_enforcement=false
vault write -f ldap/library/netops-admins/check-out ttl=30m   # one account + password
vault write -f ldap/library/netops-admins/check-in            # early return; rotates

flowchart TB
  R["Request with reason"]
  T0{"Tier 0 credential?"}
  DC["Second person approves"]
  CO["Exclusive check-out to one holder, short lease"]
  U["Use, injected by the gateway where possible"]
  CI["Check-in, or lease ends"]
  ROT["Vault rotates the password"]
  OK{"Dependants still work?"}
  RDY["Available for the next check-out"]
  FIX["Update the missed dependant; add it to discovery"]
  R --> T0
  T0 -- yes --> DC
  T0 -- no --> CO
  DC --> CO
  CO --> U
  U --> CI
  CI --> ROT
  ROT --> OK
  OK -- yes --> RDY
  OK -- no --> FIX
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class CO,U,CI,ROT core
  class T0,OK decision
  class FIX risk
  class R,DC,RDY neutral

1. Prerequisites: MFA enforced; eligible assignments supported; break-glass tested (a sign-in raises an alert).
2. Measure members and last use of admin rights; remove those unused for 90 days after showing them the request path.
3. Convert the rest to eligible (two- to four-hour maximum, MFA, ticket reference); publish the path, wait and on-call exception.
4. Watch two weeks: time to access, denials, break-glass use. Rollback: raise the maximum or add on-call auto-approval; never restore standing membership.

Other sector rules (payment cards, health, government contracts) were not checked; map obligations with ComplianceOps.

Examples, not a shortlist; checked against documentation in October 2026 (CyberArk: a 2019 certification and its current product page).

Documented facts, October 2026; “not checked” means the opened source did not say.

Automate ticket checks, on-call approvals, expiry and review decisions. Microsoft’s reviews recommend “Deny” after 30 days without sign-in^[51]; Google Cloud previews service accounts as approvers that validate tickets “directly from ITSM systems”^[13]. No opened source documents an AI system that safely decides privileged access; a language model may summarise a request or recording for a human, not approve Tier 0–1.

Non-human borrowers and approvers. The five fields apply unchanged to a workload identity. Google Cloud PAM lets service accounts and agent identities “self-elevate and assume roles only when needed for automated tasks” instead of holding roles, and, in Preview as of October 2026, act as approvers^[13][34]; Microsoft’s entitlement management can, in preview, assign groups, API permissions and roles to agent IDs^[35]. An automated approver is Tier 0: whoever controls its credentials can grant all it may approve, so scope it narrowly (one entitlement, a where predicate), alert on its decisions, and keep a human approver for Tier 0.

Artefact 1 — Teleport roles for requesting, reviewing and auto-approving database access.

Example status: YAML syntax-checked; fields from Teleport v18 documentation^[32][21][33]; role version v7 (v18 docs use v8, which needs v18 agents; v7 is supported^[33]); not applied to a cluster. Access Requests need Teleport Enterprise.

# The privileges themselves (designed with IAMOps); nobody holds this role permanently.
kind: role
version: v7
metadata:
  name: prod-db-admin
spec:
  options:
    max_session_ttl: 2h
    require_session_mfa: true
    disconnect_expired_cert: true   # end open sessions when the certificate expires
    client_idle_timeout: 15m
  allow:
    db_labels:
      env: prod
    db_users: ['dba']
    db_names: ['*']
---
# Engineers may request it with a ticket; one reviewer approves; 4 h at most.
kind: role
version: v7
metadata:
  name: prod-db-requester
spec:
  allow:
    request:
      roles: ['prod-db-admin']
      max_duration: 4h
      reason:
        mode: 'required'
        prompt: 'Ticket or incident ID, and what you will change'
      thresholds:
        - approve: 1
          deny: 1
      annotations:
        pagerduty_services: ['payments-db']
---
# Database leads may review those requests (users cannot approve their own).
kind: role
version: v7
metadata:
  name: prod-db-reviewer
spec:
  allow:
    review_requests:
      roles: ['prod-db-admin']
---
# The PagerDuty plugin may approve only requests tied to the payments-db service.
kind: role
version: v7
metadata:
  name: access-plugin-pagerduty
spec:
  allow:
    rules:
      - resources: ['access_request']
        verbs: ['list', 'read']
      - resources: ['access_plugin_data']
        verbs: ['update']
    review_requests:
      roles: ['prod-db-admin']
      where: 'contains(request.system_annotations["pagerduty_services"], "payments-db")'

The plugin approves only when the requester is on call for payments-db^[21]; its credentials are Tier 0, and PagerDuty administration joins the approval path (on-call access).

Artefact 2 — a Google Cloud PAM entitlement for Tier 1 database administration.

Example status: YAML syntax-checked against the documented schema^[34]; command not executed (needs a project with PAM); the documented command is in the gcloud alpha surface as of October 2026.

# entitlement.yaml — Tier 1: one db-leads approver; at most one hour; reason required.
privilegedAccess:
  gcpIamAccess:
    resourceType: cloudresourcemanager.googleapis.com/Project
    resource: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
    roleBindings:
      - role: roles/cloudsql.admin
maxRequestDuration: 3600s
eligibleUsers:
  - principals:
      - group:db-oncall@example.com
approvalWorkflow:
  manualApprovals:
    requireApproverJustification: true
    steps:
      - approvalsNeeded: 1
        approvers:
          - principals:
              - group:db-leads@example.com
requesterJustificationConfig:
  unstructured: {}
additionalNotificationTargets:
  adminEmailRecipients:
    - security-alerts@example.com

gcloud alpha pam entitlements create prod-sql-breakfix \
  --entitlement-file=entitlement.yaml \
  --location=global \
  --project=PROJECT_ID

Required approvals must not exceed the approving group’s members, “Otherwise, grants will remain perpetually stuck”^[34]. For Tier 0, approvalsNeeded: 2 or a second step are available “only if the Security Command Center Premium or Enterprise tier is activated”^[34]. Manage IAM with non-authoritative Terraform resources so PAM’s bindings survive^[13].

Artefact 3 — alert on every break-glass sign-in, adapted from Microsoft’s Azure Monitor sample (threshold above zero, severity 0)^[19]:

Example status: query text from Microsoft’s documentation with placeholder GUIDs; not executed.

SigninLogs
| where UserId == "00000000-0000-0000-0000-000000000001"
    or UserId == "00000000-0000-0000-0000-000000000002"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress,
    ResultType, ResultDescription

Artefact 4 — Entra PIM role settings for one directory role, through Microsoft Graph. PIM keeps a role’s settings as rules in a policy, changed with PATCH requests that answer 204 No Content^[52]. First read the role’s policyId, then patch its rules:

Example status: requests and bodies follow Microsoft’s documented examples (page dated 2025-08-29) with this page’s values^[52]; JSON syntax-checked; not sent to a tenant (needs Privileged Role Administrator).

GET   /v1.0/policies/roleManagementPolicyAssignments?$filter=scopeId eq '/'
      and scopeType eq 'DirectoryRole' and roleDefinitionId eq '<role template id>'
PATCH /v1.0/policies/roleManagementPolicies/<policyId>/rules/<rule id>

Rule Expiration_EndUser_Assignment: an activation lasts at most two hours (the setting allows one to 24^[49]):

{
  "@odata.type": "#microsoft.graph.unifiedRoleManagementPolicyExpirationRule",
  "id": "Expiration_EndUser_Assignment",
  "isExpirationRequired": true,
  "maximumDuration": "PT2H",
  "target": {
    "@odata.type": "microsoft.graph.unifiedRoleManagementPolicyRuleTarget",
    "caller": "EndUser",
    "operations": ["All"],
    "level": "Assignment",
    "inheritableSettings": [],
    "enforcedSettings": []
  }
}

Rule Enablement_EndUser_Assignment: MFA, a justification and a ticket number at activation:

{
  "@odata.type": "#microsoft.graph.unifiedRoleManagementPolicyEnablementRule",
  "id": "Enablement_EndUser_Assignment",
  "enabledRules": ["Justification", "MultiFactorAuthentication", "Ticketing"],
  "target": {
    "@odata.type": "microsoft.graph.unifiedRoleManagementPolicyRuleTarget",
    "caller": "EndUser",
    "operations": ["All"],
    "level": "Assignment",
    "inheritableSettings": [],
    "enforcedSettings": []
  }
}

Preconditions^[49]: the ticket field is “information-only” (“Correlation with information in any ticketing system isn’t enforced”), so the ticket check is yours to build; a third rule, Approval_EndUser_Assignment, names approvers (primaryApprovers, a user or group)^[52]. Microsoft recommends at least two; with none named, approval required and every Global and Privileged Role Administrator only eligible, the runbook’s lockout follows.

Labs 1 and 3 were executed on 2026-10-16 (Ubuntu 20.04, Python 3.8.10, OpenSSH 8.2p1) and Lab 2’s checks on 2026-10-17 with sudo 1.8.31; installing the rule was not. Output is real; data is synthetic.

Objective: from a review export, compute completion and revocation rates, list privileged access approved though unused, and flag reviewers whose pattern suggests no real review. Prerequisites: Python 3.8+. Cost and risk: none.

1. Save the export as decisions.csv (empty days_since_use means never used):

Example status: executed on 2026-10-16 as input to the script below.

entitlement,privileged,holder,reviewer,decision,seconds,days_since_use
prod-db-admin,yes,ana,raj,approve,4,210
prod-db-admin,yes,ben,raj,approve,3,2
prod-db-admin,yes,chen,raj,approve,5,
k8s-cluster-admin,yes,dev,raj,approve,4,95
k8s-cluster-admin,yes,eli,raj,approve,3,11
billing-export,no,fay,mia,approve,48,5
billing-export,no,gus,mia,revoke,61,180
crm-read,no,hal,mia,approve,35,1
crm-read,no,ivy,mia,revoke,52,400
aws-org-admin,yes,jon,leo,approve,90,30
aws-org-admin,yes,kim,leo,revoke,75,120
vault-root-ops,yes,lou,leo,none,,
siem-admin,yes,max,leo,approve,66,3

2. Save the script as review_report.py:

Example status: executed on 2026-10-16 (Python 3.8.10).

#!/usr/bin/env python3
"""Access-review report: completion, revocations, unused approvals, rubber stamps."""
import csv
import statistics
import sys
from collections import defaultdict

UNUSED_DAYS = 90       # approved but unused for longer than this is suspicious
FAST_SECONDS = 10      # median decision time below this suggests no real review
MIN_DECISIONS = 5      # only judge reviewers with enough decisions


def main(path):
    with open(path, newline="") as handle:
        rows = list(csv.DictReader(handle))
    decided = [r for r in rows if r["decision"] in ("approve", "revoke")]
    revoked = [r for r in decided if r["decision"] == "revoke"]
    print(f"items: {len(rows)}  decided: {len(decided)} "
          f"({100 * len(decided) / len(rows):.0f}% complete)")
    share = 100 * len(revoked) / len(decided)
    print(f"revoked: {len(revoked)} ({share:.0f}% of decided)")

    print("approved but unused (or never used) for more than", UNUSED_DAYS, "days:")
    for r in decided:
        unused = r["days_since_use"] == "" or int(r["days_since_use"]) > UNUSED_DAYS
        if r["decision"] == "approve" and unused:
            flag = "PRIVILEGED " if r["privileged"] == "yes" else ""
            last = r["days_since_use"] or "never"
            print(f"  {flag}{r['entitlement']} held by {r['holder']} (last use: {last})")

    by_reviewer = defaultdict(list)
    for r in decided:
        by_reviewer[r["reviewer"]].append(r)
    print("reviewer signals:")
    for name, items in sorted(by_reviewer.items()):
        approve_rate = sum(r["decision"] == "approve" for r in items) / len(items)
        median_s = statistics.median(int(r["seconds"]) for r in items)
        stamp = (len(items) >= MIN_DECISIONS and approve_rate == 1.0
                 and median_s < FAST_SECONDS)
        note = "  <- possible rubber stamp" if stamp else ""
        print(f"  {name}: {len(items)} decisions, {approve_rate:.0%} approved, "
              f"median {median_s:g} s{note}")
    pending = [r["entitlement"] + "/" + r["holder"]
               for r in rows if r["decision"] == "none"]
    print("undecided:", ", ".join(pending) or "none")
    return 1 if pending else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

3. Run python3 review_report.py decisions.csv.

Expected output (exit code 1: one item is undecided):

items: 13  decided: 12 (92% complete)
revoked: 3 (25% of decided)
approved but unused (or never used) for more than 90 days:
  PRIVILEGED prod-db-admin held by ana (last use: 210)
  PRIVILEGED prod-db-admin held by chen (last use: never)
  PRIVILEGED k8s-cluster-admin held by dev (last use: 95)
reviewer signals:
  leo: 3 decisions, 67% approved, median 75 s
  mia: 4 decisions, 50% approved, median 50 s
  raj: 5 decisions, 100% approved, median 4 s  <- possible rubber stamp
undecided: vault-root-ops/lou

Validation: raj approved five privileged items in a median of 4 seconds, three of them unused. Troubleshooting: KeyError means a header differs; ValueError a non-numeric seconds on a decided row. Interpretation: a flag is a question, not proof; the thresholds are this lab’s (Microsoft’s recommendations use 30 days of inactivity^[51]; CIS, 45 days for dormant accounts^[41]). Teardown: delete the two files.

Objective: a sudoers rule with a start and end time, two exact commands that cannot start a shell, a command timeout and input/output logging. Prerequisites: the original sudo (sudo.ws) 1.8.20 or later with cvtsudoers (added in 1.8.23)^[53]; a disposable Linux VM for the optional install. Check which sudo you have first. Ubuntu 25.10 and 26.04 LTS install sudo-rs by default (26.04: 0.2.13), which as of October 2026 has no NOTBEFORE/NOTAFTER, TIMEOUT, I/O logging, sudoreplay or cvtsudoers^[29][54][30]. If sudo --version reports sudo-rs, switch to sudo.ws with update-alternatives --config sudo^[54] or use another distribution. Cost and risk: none for the checks; a broken file in /etc/sudoers.d/ can lock you out of sudo, so install only on a VM after visudo -c.

1. Save the rule as 90-jit-alice (a broker would write it and delete it after expiry):

Example status: syntax-checked with visudo -c -f and parsed with cvtsudoers on 2026-10-17 (sudo 1.8.31).

# JIT grant CHG-4821: alice may restart nginx and read its log on web-01 until 18:00 UTC.
# Written by the access broker; removed by the broker after expiry.
alice web-01 = (root) NOTBEFORE=20261016140000Z NOTAFTER=20261016180000Z \
    TIMEOUT=15m LOG_INPUT: LOG_OUTPUT: /usr/bin/systemctl restart nginx, \
    NOEXEC: /usr/bin/journalctl --no-pager -u nginx

2. Check and parse it without installing:

Example status: executed on 2026-10-17 as a normal user.

visudo -c -f 90-jit-alice
cvtsudoers -f json 90-jit-alice

Expected output: 90-jit-alice: parsed OK, then JSON with one entry per command; both carry "command_timeout": 900, "notbefore": "20261016140000Z", "notafter": "20261016180000Z", "log_input": true and "log_output": true; the journalctl entry adds "noexec": true. A malformed NOTAFTER=2026-10-16 fails with invalid notafter value; the format is Generalized Time, yyyymmddHHMMSSZ^[31].

3. Not executed here — disposable VM only: sudo install -m 0440 90-jit-alice /etc/sudoers.d/, then, as root or a user with ALL (sudo restricts -U to them^[55]), run sudo -l -U alice /usr/bin/systemctl restart nginx before, during and after the window. Validation: the command is allowed only inside the window; outside it sudo exits with status 1^[55]. Plain sudo -l -U alice lists the rule at any time, with its NOTBEFORE and NOTAFTER dates^[56]. Sessions are logged under /var/log/sudo-io by default and listed with sudoreplay -l^[57].

Troubleshooting: if visudo -c rejects NOTBEFORE or cvtsudoers is missing, you are on sudo-rs (see Prerequisites); if sudo -l shows nothing, check the host name in the rule. Lesson: expiry is real only if no granted command can start another program: a root pager, editor or shell outlives NOTAFTER and can plant lasting access. Plain journalctl opens a pager, “a security boundary” under sudo in systemd’s manual; systemd 245 (Ubuntu 20.04) lacks the later automatic secure mode^[58]. Hence --no-pager, NOEXEC: and sudoedit^[31]. Forward logs off the host. Teardown: delete the file (and /etc/sudoers.d/90-jit-alice on the VM).

Objective: issue SSH user certificates from a CA, as Vault’s SSH engine does^[45], and observe what a validity period ends. Prerequisites: OpenSSH 8.x on a Linux machine you control. Cost and risk: low; a temporary, unprivileged sshd listens only on 127.0.0.1:22422 and is stopped at the end. Do not run it on a shared production host without permission.

1. Create a CA, a key and a certificate valid for the next ten minutes (back-dated five minutes for clock skew), then an sshd that trusts only the CA:

Example status: executed on 2026-10-16 (OpenSSH 8.2p1); fingerprints and times will differ on your machine.

mkdir -p ~/ssh-ca-lab && cd ~/ssh-ca-lab
ssh-keygen -q -t ed25519 -N '' -C 'lab-user-ca' -f user_ca          # the CA
ssh-keygen -q -t ed25519 -N '' -C 'operator' -f id_operator         # the engineer's key
# Valid from 5 min ago (clock skew) to 10 min from now; local account; change ID.
ssh-keygen -s user_ca -I "operator@CHG-4821" -n "$(whoami)" -V -5m:+10m \
  -O clear -O permit-pty id_operator.pub
ssh-keygen -L -f id_operator-cert.pub
# A throwaway sshd that trusts only this CA (no authorized_keys at all).
ssh-keygen -q -t ed25519 -N '' -f host_key
cat > sshd_config <<CFG
Port 22422
ListenAddress 127.0.0.1
HostKey $PWD/host_key
PidFile $PWD/sshd.pid
UsePAM no
PasswordAuthentication no
AuthorizedKeysFile none
TrustedUserCAKeys $PWD/user_ca.pub
StrictModes no
LogLevel VERBOSE
CFG
# Absolute paths: sshd re-executes itself for each connection.
/usr/sbin/sshd -f "$PWD/sshd_config" -E "$PWD/sshd.log"
ssh -p 22422 -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new \
  -o UserKnownHostsFile=known_hosts -i id_operator 127.0.0.1 \
  'echo "logged in as $(whoami)"'

Expected output (abridged):

Signed user key id_operator-cert.pub: id "operator@CHG-4821" serial 0 for ubuntu
  valid from 2026-10-16T23:29:09 to 2026-10-16T23:44:09
        Key ID: "operator@CHG-4821"
        Valid: from 2026-10-16T23:29:09 to 2026-10-16T23:44:09
        Principals:
                ubuntu
        Extensions:
                permit-pty
logged in as ubuntu

2. Validation — three refusals. Try the private key without its certificate (copied elsewhere), a copy signed with -V -2h:-1h, and one signed for principal root. All three got Permission denied (publickey,keyboard-interactive); sshd.log recorded Certificate invalid: expired and Certificate invalid: name is not a listed principal. TrustedUserCAKeys also refuses certificates without principals^[59].

3. The lesson — expiry is checked at login. Sign a one-minute certificate and hold a session open past its end:

Example status: executed on 2026-10-16.

cp id_operator id_short && cp id_operator.pub id_short.pub
ssh-keygen -s user_ca -I "operator@CHG-4822" -n "$(whoami)" -V -1m:+1m id_short.pub
ssh -p 22422 -o IdentitiesOnly=yes -o UserKnownHostsFile=known_hosts -i id_short \
  127.0.0.1 'date -u +%T; sleep 80; date -u +%T; echo "still open after expiry"'
ssh -p 22422 -o IdentitiesOnly=yes -o UserKnownHostsFile=known_hosts -i id_short \
  127.0.0.1 true

Expected output: the certificate expired at 23:35:09; the session printed 23:34:09, then 23:35:29 and still open after expiry, so it outlived the certificate by 20 seconds; the second login was refused. Pair short certificates with session timeouts and a way to end sessions.

Troubleshooting: kex_exchange_identification: ... Connection reset by peer means sshd was started with a relative -f path; Permission denied with a valid certificate usually means a principal that does not match the login name. Teardown: kill "$(cat sshd.pid)"; delete ~/ssh-ca-lab.

Meta’s case is physical access, kept for the trade-off; the other responses cost speed, so measure it.

Definitions and targets are Atlas proposals; no standard prescribes them.

• The access system is the crown jewel. Whoever administers the broker, CA or vault can grant anything: separation of duties (AC-5^[9]); broker policy changes need two people.
• Self-approval and collusion. Check that the tool refuses self-approval (Teleport does^[42]); the Twitter report suggests second-employee approval for high-risk functions^[61].
• Stolen sessions. MFA at activation (PIM can^[12]) and per session where possible (require_session_mfa^[33]).
• Recording is not complete evidence. Users “can conceal terminal commands by encoding them (e.g., using base64)” or by running scripts^[23]; basic session logging only keeps “the honest people honest”^[18]. Prefer narrow tools and structured logs.
• Privacy. Recordings hold personal data and secrets. NIST’s session-audit control (AU-14) says to act “in consultation with legal counsel” and to activate it “under well-defined situations”^[9], so recording every admin session is an organisational choice with a documented purpose and retention; rules differ by country. Set retention and viewers with PrivacyOps.
• Log integrity: store evidence where target admins cannot edit it^[24]. Regulation varies by sector and country; this page is not legal advice.

• Licences and tiers (October 2026): see the edition row of the comparison matrix; Entra access reviews and entitlement management also need Entra ID Governance or Entra Suite, some capabilities P2^[47].
• Recording storage: Boundary estimates about 20 KB per minute of simple shell activity, and transfers cost about their own size^[24]. Illustrative: 2,000 sessions a month × 30 minutes × 20 KB ≈ 1.2 GB; one recorded 5 GB export costs more.
• People’s time: 3,000 review items at a careful 30 seconds is 25 hours; at 4 seconds, a rubber stamp. Sustainability is not material here.

• Reconcile daily, and at grant end for Tier 0: a privileged assignment, key or role change the broker did not grant is drift (what expiry really ends)^[13].
• Canary grant: a daily synthetic grant; alert if it still works after expiry plus the propagation margin^[28].
• Drill break-glass at least every 90 days^[19] and in incident and recovery exercises^[20].
• Sample sessions weekly against their reasons; peers with context spot misuse best^[18].

1. Declare an incident (IncidentOps); confirm the failure mode: provider healthy, MFA working, no approvers.
2. Retrieve the kit: two authorised people (our recommendation) take a break-glass FIDO2 hardware security key (a phishing-resistant passkey) from the safe to the secure workstation Microsoft calls for^[19]. Log the time.
3. Sign in and expect the alarm; security operations confirms the use is expected. No alarm is a second failure.
4. Make the smallest change: add a current approver group, or give a named administrator a time-bound assignment ending today. Never fix the original outage with the break-glass account.
5. Verify that a normal administrator can activate the role through PIM.
6. Exit: sign out, return the key, rotate or re-seal credentials (AWS’s advice^[20]).
7. Review within one business day (security operations), then at the team’s next meeting: match every audit-log action of the account to the timeline (Microsoft asks for a review after any use^[19]).
8. Prevent: alert when a Tier 0 approver list has under two active members; add the scenario to the drill.

Contingency: if the first account fails, use the second (different method and location); if both fail, only provider account recovery is left.

• “We have a PAM tool, so it is managed.” Week-long checkouts are standing privilege with extra steps; keep leases short and rotate on check-in (vault check-out).
• “Just-in-time means attackers can’t use it.” A session stolen during a grant has the grant’s rights (CircleCI).
• “Every request needs a manager’s approval.” Managers approve what they cannot judge; hard approvals breed generic justifications^[18]. Rules for low tiers, context for high ones.
• Break-glass as convenience. AWS’s anti-pattern: users who misuse emergency access “as they find it easier to make changes directly than submit changes through a pipeline”^[20]; weekly use means the normal path is broken.
• Reviews as the main control. CISA puts “permanent access with periodic review” at the Traditional stage^[11]. Recording everything, watching nothing: unsampled recordings deter nobody.
• Myth: zero standing privileges means zero administrators. Break-glass accounts stay permanent by design^[19].

Use the full model when several people hold production or control-plane rights, vendors need production access, or someone asks for evidence. Scale it down for small teams: three engineers sharing one cloud account gain little by approving each other. Start with separate admin accounts (CIS 5.4^[41]), MFA for admin access (CIS 6.5^[25]), central logs and two tested break-glass accounts; then time-bound activation, then approvals for Tier 0.

Do not start here when identities are not under control (shared accounts, no SSO, no leaver process): fix that in IdentityOps first, because JIT on shared accounts attributes nothing. Nor to excuse a task that should be automated (zero touch).

Hidden costs: Tier 0 systems to run, approver cover, drills, a retention decision on recordings.

flowchart TB
  Q1{"Normal path working?"}
  BG["Break-glass, alarmed, reviewed"]
  Q2{"Can automation do it?"}
  TOOL["Build the tool; no elevation"]
  Q3{"Which tier?"}
  T0["Two approvers, strong MFA"]
  T1["One approver or on-call rule"]
  Q4{"Needed daily?"}
  T2["Self-activate with ticket"]
  T2S["Narrow standing role, reviewed"]
  Q1 -- no --> BG
  Q1 -- yes --> Q2
  Q2 -- yes --> TOOL
  Q2 -- no --> Q3
  Q3 -- "Tier 0" --> T0
  Q3 -- "Tier 1" --> T1
  Q3 -- "Tier 2" --> Q4
  Q3 -- "Tier 3" --> T2S
  Q4 -- no --> T2
  Q4 -- yes --> T2S
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class Q1,Q2,Q3,Q4 decision
  class TOOL,T0,T1,T2,T2S core
  class BG risk

Durations follow the tier proposal. A daily Tier 0–1 need is a design signal (principle 9): build the tool or pre-approve a narrow rule, never a standing role.

Quick wins: remove unused admin rights, alert on break-glass sign-ins, fill empty approver lists. Dependencies: IdentityOps (MFA), IAMOps (roles worth activating).

• Inventory of Tier 0–1 roles and holders, with last use
• Two break-glass accounts with separate authentication and alerts; drill passed
• Tier table published; pilot team chosen
• Request, approval and grant logs reach the SIEM

• At least two active approvers and an out-of-hours escalation path
• Maximum duration set; extension path documented
• On-call exception tested with a staged incident
• Infrastructure as code cannot overwrite time-bound bindings

• Sign-in tested from the designated workstation; alert acknowledged
• No dependency on the normal identity provider, broker or blocking policies
• Authorised users and credential locations current; every use since the last drill reviewed

• Privileged and unused access first; last use shown; no-response default chosen deliberately
• Results applied; rubber-stamp signals followed up

Access request intake form:

ACCESS REQUEST
Requester:            <name>              Target role / resource: <role, scope>
Tier:                 0 / 1 / 2           Duration requested:     <minutes or hours>
Reason (structured):  <ticket or incident ID>   What will you change: <one line>
On call now?:         yes / no            Approver(s):            <group or rule>
Session recorded?:    yes (Tier 0-1)      Ends early when done?:  yes

Break-glass procedure (kept with the credentials):

BREAK-GLASS PROCEDURE - <system>
Use only when: <normal path unavailable: IdP down / approvers missing / broker down>
Never use for: routine changes, speed, or avoiding review
1. Open an incident; name the incident lead.
2. Two authorised people retrieve credential <n> from <location>.
3. Sign in from <designated workstation>; confirm the alert reached <SOC channel>.
4. Make the smallest change that restores the normal path; log each action.
5. Verify the normal path works; sign out; re-seal or rotate the credential.
6. Review all actions within one business day; record the root cause.
Owner: <team>    Last drill: <date>    Next drill due: <date, <= 90 days>

Review campaign charter:

REVIEW CAMPAIGN - <resource or role group>     Period: <dates>
Scope:          <privileged roles first; then unused access>
Reviewers:      <resource owners, not the holders' managers by default>
Decision aids:  last use, original reason, tier
No response:    <no change | remove | take recommendations> and why
Auto-apply:     yes / no      Escalation after: <days>
Quality checks: approved-but-unused, decisions faster than <n> s, 100 % approvers
Report to:      <security lead>; evidence to <ComplianceOps owner>

Architecture decision record:

ADR-<n>: <title, e.g. "On-call engineers auto-approved for Tier 1 database access">
Context:      <incident data, p90 time to access, risks>
Decision:     <pattern, tier, max duration, approver rule>
Alternatives: <standing role; approval always; break-glass only>
Consequences: <risk accepted, controls added, metric to watch>
Review date:  <date>

Is AccessOps the same as PAM? No. PAM is a tool category (vault, rotation, session manager); AccessOps, as used here, is the operating model around requested and privileged access, which may use PAM, cloud-native JIT, access platforms or SSH certificates.

Does just-in-time access replace access reviews? No. Reviews still decide who stays eligible and catch roles outside the JIT system; they become smaller.

What about service accounts and AI agents? Inventory belongs to IdentityOps, permissions to IAMOps. The same loan applies with an automated borrower, and an automated approver is Tier 0 (Automation and AI).

Is approval through Slack or Teams safe? Yes, if chat carries only the request and decision, the access system makes and ends the grant (ChatOps), and the bot holds no standing rights.

Are quarterly reviews enough for auditors? They exceed the annual floor of CIS Safeguard 6.8^[25], but a review can complete without removing anything; report revocations and approved-but-unused access alongside completion.

How should a vendor get production access? As the same loan with stricter fields: a named person (federated or sponsored, never a shared account), a support case as the reason, a device you manage or a gateway you control (Okta’s change after 2022^[62]), a grant that ends with the case, a recorded session. Customer Lockbox shows the provider-side shape: case-bound, time-bound, customer-approved, audited^[64]. Measure: every vendor session maps to a case.

• Zero touch: Google works to remove “direct human access to production roles”, humans acting through tooling and “resilient multi-party approval systems”^[18]: the maturity model’s endpoint.
• Authorising requests, not people: Google’s “three-factor authorization” approves a specific request on a second, hardened device (against compromised workstations); MPA protects against insiders^[18].
• Dynamic privilege: SP 800-53 AC-2(6) describes “immediate revocation of privileges from users as opposed to requiring that users terminate and restart their sessions”^[9]; today mostly a gateway feature.
• Standard approval protocols: the OpenID Foundation announced on 2026-06-15 that its AuthZEN group had approved an Access Request and Approval Profile (AARP) as a Working Group Draft, with “interoperable patterns for requesting, tracking, satisfying, and re-evaluating” approval prerequisites^[66]. A draft, not a standard.

• Prerequisites: SSO and MFA (IdentityOps); roles and least privilege (IAMOps).
• One day: the PIM overview^[12] and Microsoft’s emergency-access guidance^[19]; Lab 1.
• One week: Labs 2 and 3; draw your tier table; find every standing Tier 0 assignment.
• Thirty days: the first roadmap window and a break-glass drill; chapter 5 of Building Secure and Reliable Systems^[18].
• Specialise: PAM suites, access platforms, or review design with ComplianceOps. Portfolio project: an SSH CA that signs one-hour certificates only after a second person approves.

You should now be able to explain the meanings of “AccessOps” and the identity-trio split, design tiers, approval rules and a break-glass kit, operate JIT grants, reviews and drills, and evaluate a programme by standing, speed and review-quality metrics.

“AccessOps” has no standard meaning, but under this page’s meaning lies a well-documented discipline: access that is requested, time-bound, recorded where privileged, and reviewed. In the cases, the damage came from rights that were standing, broad or hard to bound, and every fix cost some speed.

The work is to make access a loan with a due date the system enforces, to know what a grant can leave behind, to keep one emergency path that shares nothing with the normal one, and to check that reviews and approvals can say no. The test: at 03:00, can the right engineer get the right access in minutes, and can you show next morning who did what, why, and that it ended?

Changelog

• 2026-10-16 — r0: first draft; ambiguous (five unrelated uses); 6 diagrams; Labs 1 and 3 executed, Lab 2 parsed only; evidence in research/accessops-ledger.md.
• 2026-10-17 — r1 (reviews/accessops-r1-superseded-20261017T0411.md): Lab 2 rule closed to shell escapes; IAM-capable grants, Teleport session termination, PagerDuty preconditions, ordinary requests and vault check-out added; figures redrawn.
• 2026-10-17 — r2 (reviews/accessops-r1.md, reviews/accessops-r1-response.md): sudo-rs caveats; cvtsudoers from 1.8.23; -U needs root; dates and cadences made precise; six-column RACI; non-human approvers; Vault commands; Lockbox limits.
• 2026-10-17 — r3 (reviews/accessops-score.md, reviews/accessops-r2-response.md): birthright defined; Tier 0 linked; Entra agent-ID wording; CircleCI time zone; Lab 2 prerequisites split; sudo-rs README pinned; Entra PIM Graph artefact, vendor FAQ and mastery check 6 added; figure 2 extended; restatements trimmed.
• 2026-10-17, post-score polish (reviews/accessops-polish.md, reviews/accessops-polish-check.md): GitHub descriptor, PIM lockout condition, cadence list, non-goals named, figure 3 uncrossed, HashiCorp footnotes version-pinned.