The limb the indicator is named for
“What do we scan to prove just-in-time access?” splits into limbs a rule settles, one an inventory hands to a reviewer, and one — the just-in-time part itself — that lives in an approval record no API returns. Two IAM recipes, same service, different ratings, show where the line falls.
The indicator is called Authorizing Just-in-Time, and the question your team will be asked is “what do we scan to prove just-in-time access?” The honest answer has the same shape as the cryptography one: it is several claims, most of which a machine settles — and the one the indicator is named for is the one no machine holds.
“Just-in-time” is a sequence. Access is asked for, someone entitled to say yes says yes, the grant happens, and it ends when the time runs out. The cloud estate holds the third of those as a log line and puts a ceiling on the fourth. The first two live in whatever workflow you built around the console — or nowhere.
“Do we have just-in-time access?”
No credential outlives its rotation
Every console password has a second factor behind it and every active access key was rotated inside the window you set.
measured · answered by A rule with a line
Nothing keeps access it never uses
No role, key, password or permission has sat idle past the age you configured — findings, and an empty set for the privileged ones.
measured · answered by A rule with a line
No policy grants everything
No policy you wrote allows every action on every resource — with the rule's own scope stated, because it reads only the policies you manage.
measured · answered by A rule with a line
Every grant is the least it could be
Each principal's attached and inline policies, read against the access you documented as intended — a complete snapshot, and a verdict the snapshot does not contain.
cited · answered by An inventory to compare
Privilege arrives on request and leaves on schedule
Each elevation was asked for, approved by someone entitled to approve it, bounded in time, and removed when the time ran out — the request and the approval first of all.
cited · answered by No scan — an approval record
Notice what the measured limbs have in common: they are all proofs of absence. No stale key, no idle grant, no policy that says everything. A rule can prove those because each is a value against a line — a date against a window, a finding count against zero, a policy document against a pattern. The limbs that are not measured are the ones that ask whether a decision was the right one.
Here is the distinction in two recipes from this site’s own corpus. Same plane, same service, both a plain listing of the account’s principals — and different ratings:
Account-wide credential report proving MFA is active per principal and that passwords/access keys are rotated within policy
fetch
$ aws iam generate-credential-report$ aws iam get-credential-report --query GeneratedTime --output text$ aws iam get-credential-report --query Content --output text | base64 --decodemaps to: ia-2, ia-5 · cadence: monthly · full recipe: /collect/iam-credential-report
The columns are the verdict. password_enabled, mfa_active, access_key_1_last_rotated: for every row the pass or fail is a comparison the report already lets you make, with nothing left for a reader to decide. That is why it rates as it does — and why the recipe still states the report's scope, which stops at the first two keys per user and does not see service-specific credentials at all.
Full snapshot of every IAM user, group, role, and attached/inline policy with their relationships, used to review that granted permissions match least-privilege intent
fetch
$ aws iam get-account-authorization-details --query 'UserDetailList[].{User:UserName,Groups:GroupList,Attached:AttachedManagedPolicies[].PolicyName,Inline:UserPolicyList[].PolicyName}'$ aws iam get-account-authorization-details --filter Role --query 'RoleDetailList[].{Role:RoleName,Trust:AssumeRolePolicyDocument,Attached:AttachedManagedPolicies[].PolicyName}'maps to: ac-2, ac-3, ac-6.1 · cadence: quarterly · full recipe: /collect/iam-account-authorization-details
The output is complete — every user, group, role, and every policy attached to each — and it contains no verdict. Whether a grant is 'least privilege' is a comparison against the access you documented as intended, and the snapshot does not contain your intentions. The recipe says so in its notes rather than scoring itself on the enumeration. One column short of a verdict is the whole distance between these two badges.
And then the limb that gives the indicator its name. The corpus holds a recipe for it, and the recipe is not a scan:
Documented just-in-time / break-glass privilege-elevation process backed by IAM Identity Center permission sets and account assignments, showing privileged access is role/attribute-based, time-bound, and approval-gated rather than standing
fetch
# aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text# aws sso-admin list-permission-sets --instance-arn <INSTANCE_ARN># aws sso-admin describe-permission-set --instance-arn <INSTANCE_ARN> --permission-set-arn <PERMISSION_SET_ARN> --query 'PermissionSet.{Name:Name,SessionDuration:SessionDuration}'# aws sso-admin list-account-assignments --instance-arn <INSTANCE_ARN> --account-id <ACCOUNT_ID> --permission-set-arn <PERMISSION_SET_ARN>maps to: ac-3, ac-6, ac-6.5 · cadence: quarterly · full recipe: /collect/identity-center-jit-elevation-workflow
The listing proves that permission sets exist and that each session has a ceiling — Identity Center lets you set it between one and twelve hours, and signs the user out when it elapses. What the listing cannot show is that a given elevation was requested, that the right person approved it, or that it was removed because the task ended rather than because the clock did. AWS's own reference for this — its temporary elevated access management sample — is a custom application with its own request, approval and audit trail, which is the clearest statement available that the platform does not hold those on your behalf.
So the judgement, stated plainly: the cleanup is measured — the estate can prove, continuously, that nothing has outlived its rotation, sat idle past its age, or been granted everything. The choreography is cited — that privilege was asked for, approved, and ended on purpose is a record you keep, and an assessor asks to read it next to the log line that shows the role being assumed. A team that answers the question with the cleanup alone has proved that standing access is small. It has not proved that access is just-in-time.
Eight questions follow. Sort each into the thing that answers it. Two belong in the bucket that is not a scanner, and one of those two is designed to feel like a log question.
The record this step keeps pointing at is, again, the deliverable nobody sells you: for every elevation, who asked, who approved, when it began, when it was removed, and the ticket that says why — kept where the log line that shows the role being assumed can be laid beside it. If your elevation workflow already writes that down, the evidence is a query. If it does not, no scan will find it later.
Every recipe named here is at /collect, and the controls behind this indicator — including the ones that close as documents about people rather than principals — are on /frontier.
Exit check — a customer asks “what do we scan for just-in-time access?” What do you say first?
Split the question before answering it. Credential rotation, unused access, and the absence of grant-everything policies are rules with a line — collected continuously, verdict in the output. What each principal holds is an inventory, complete and machine-readable, whose verdict is a comparison against a baseline you wrote. Who assumed a role and when is a log. Whether that assumption was requested and approved first is a record no scan emits — and it is the limb the indicator is named for. If you can also say why the inventory recipe and the credential report both rate partial for different reasons — one has no assertion to write, the other has assertions and a factor type it cannot see — the step held.