Credential Strength and Binding

Control Statement

Identities shall be proofed to a level commensurate with the access they confer, and bound to credentials whose strength matches that level.

Purpose. To ensure the credential is as strong as the access behind it, so that proofing and authentication assurance are matched rather than assumed.

Discussion

The failure this addresses is drift rather than misconfiguration. A person proofed at one level and issued a credential appropriate to it accumulates access over subsequent years, and nothing re-examines whether the original proofing still justifies the current entitlement. WF-2 catches this for privileged humans; this control generalises it to every identity including non-human ones, where the problem is worse because service identities are routinely issued long-lived secrets and then granted whatever access their consuming application later requires.

Goals and Metrics

A metric that cannot come out badly is not a metric. Each of these is capable of reporting that the control is not working.

Accountability

Exactly one role is accountable, and every other role carries at least Informed — no control in the published catalog leaves a role with zero relationship to it. That is a stated property of how these were authored, not a coincidence, and not a claim that every role's work is worth equal attention here.

Inputs and Outputs

Activities

1. L2Record the proofing level applied to each identity.
2. L2Record the credential type bound to each identity.
3. L2Raise a finding where credential strength is below the access conferred.
4. L3Define the required proofing and credential strength per access tier, with provenance per GA4.
5. L3Apply the requirement to non-human identities — service accounts, workload identities, API credentials — where binding is to an owning system and a named accountable human rather than to a person.
6. L3Require phishing-resistant credentials for identities reaching decisive points, and record exceptions with expiry.
7. L3Re-examine proofing adequacy when access changes, not only when the identity is created.
8. L4Measure the gap between proofing level and access conferred across the population, and trend it.
9. L4Measure the count and age of long-lived non-human secrets, since these are the credentials least likely to be rotated and most likely to be exfiltrated.
10. L5Move non-human identities to short-lived, workload-attested credentials where the platform permits, retiring the long-lived secret class rather than managing it.

Measurement

Evidence and Assessment

Related Guidance

Position in the Chain

Derived from the other controls’ own declarations, so the two directions cannot disagree.

Where This Control Is Used

Derived, in every case, from the declaration at the other end: the forms whose techniques name this control, the artifacts whose producing and consuming controls include it, the layers whose control lists name it, and the roles its own accountability chart puts to work. Nothing here is authored on this page, so the sheet cannot claim an edge the other end does not.