The column that says TRUE for both

The indicator is called Adopting Passwordless Methods, and its text asks for passwordless sign-in where feasible and, where not, strong passwords with phishing-resistant multi-factor authentication. The question your team will be asked is “what do we scan to prove that?” The honest answer has the shape the last two steps taught: several claims, two of which a rule settles outright — and the one the indicator is named for is not held by any API in the estate.

“Phishing-resistant” is a term of art. NIST’s authentication guideline defines it as an authenticator that cannot hand its secret to an impostor site even if the user is fooled, and says plainly that anything a person types in— a six-digit code from an app, a text message — does not qualify. Passkeys and security keys do. AWS supports all of these for the same user, and its own guidance recommends the passkey. So the question is not “is MFA on?” It is “which kindis on?” — and that is a different column, one the scan does not have.

The two measured limbs are again proofs of absence: no password without a factor behind it, no credential that belongs to nobody. The unmeasured limbs come in two kinds this time, and the step turns on keeping them apart. One is the familiar inventory — a complete count whose verdict is a comparison you make. The other two are facts the estate never held in the first place: what kind of factor was presented, and whether the identity presenting it is one person.

Here is the distinction in two recipes from this site’s own corpus. Same plane, the same rule engine reading the same IAM users, neighbouring subject matter — and different ratings:

Now look at what neither recipe claims. The credential report and the managed rule both reduce a user’s second factor to one bit: enabled or not. AWS’s own documentation for the report lists mfa_activeas TRUE when “an MFA device has been enabled” — any device. The console shows a type per user (Virtual, Security key, Hardware), but no recipe in this corpus reads it, and for the users this indicator most wants — the federated ones, signing in through Identity Center or an external identity provider — IAM never sees the factor at all. The challenge was issued somewhere else, and only that somewhere else knows what kind it was.

So the judgement, stated plainly: the presence of a second factor is measured — continuously, per user, verdict in the output. The kind of factor is cited: it is a report you pull from your identity provider, and an assessor reads it beside the empty non-compliant set. And the person behind the identity is a record — the roster, and the process that keeps a subject in the identity store bound to one employee and removes it when they leave. A team that answers the question with the managed rule alone has proved that MFA is on. It has not proved that the method is passwordless, or that the factor is the kind the indicator names.

Eight questions follow. Sort each into the thing that answers it. Two belong to the identity provider and two to a personnel record, and one of the provider’s two is designed to feel like a column of the credential report.

The deliverable this step points at is a short one: from your identity provider, the list of enrolled authenticators by type, per user, dated — and the policy that forbids enrolling the other kinds. Laid beside the managed rule’s empty set, that is the whole indicator. If your provider can export it, the evidence is a query. If your users are IAM users with virtual devices, the export will say so, and the honest finding is the one the indicator anticipates: passwordless where feasible, and a plan for where it is not yet.

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.