Step 1. Define your scope
Before giving an implementation a rating, state what you reviewed:- The website or app
- User and account groups
- Browsers, operating systems and credential managers
- Countries and time period
- Anything excluded or not tested
N/A only when a requirement does not apply to the reviewed implementation.
Also state whether each capability is built in, configurable, requires integration work or requires custom development. This separates the quality of the result from the effort needed to achieve it.
Step 2. Grade each criterion
Every flow page ends with its acceptance criteria, each carrying an ID such asW1.1-AC03. Grade them one by one.
Test important platforms separately. A feature that works on Chrome but fails on Safari is one pass and one fail, not one combined result.
Criteria come in two levels. Core covers behavior that must work: security, account binding, completion, cancellation and fallback. Quality covers measurement, testing and maintainability.
Use a simple review table:
Also record how strong the evidence is:
Two pieces of flow metadata decide how a criterion is judged. Benchmark as sets how strictly the flow is required, and User reach describes how much of the user base it touches. Both are listed for every flow in the availability matrix.
Benchmark as
User reach
This is a qualitative estimate for the full audience. It is not a measure of overall importance, it does not affect whether a criterion passes and the labels must never be added together as a score. Credential management and Signal API reconciliation have low user reach but high reliability and lifecycle value.
Availability
Exact version requirements are listed on each flow page and in the availability matrix.
Step 3. Roll up to a flow rating
Step 2 grades one criterion at a time. A flow has around ten of them, so step 3 turns those results into a single verdict per reviewed platform. That verdict, not the individual criteria, is what the pillars in step 4 consume. The roll-up is not simply “all passed”. It separates Core from Quality: a flow whose Core criteria all pass but which fails one Quality criterion is Core met, which is a usable, secure flow with a measurement or maintainability gap. That is a different finding from Not met, where something a user depends on is broken.Step 4. Score the four pillars
Do not rate adoption by counting passed criteria. A login strategy, an optional enhancement and a management feature have different purposes. Instead, review four separate areas:
A primary flow provides the main result for a pillar. A secondary flow improves or protects that result but cannot satisfy the pillar by itself.
Give each pillar the highest level it fully meets:
Rate each included website or app separately. If an implementation uses a different flow to achieve the same result, assess it against the same acceptance criteria. If a pillar does not reach Basic or was not reviewed, the overall result is Incomplete.
Step 5. Determine adoption potential
This is the final result of the review. It rates the whole implementation, where User reach in the catalogue rates a single flow. Do not average the pillars. Apply these rules:
Determine adoption potential for web and native separately, then take the lowest result across the included applications, ordered
Incomplete < Low < Mid < High. An application that was not reviewed counts as Incomplete. Always show the individual results and state what was not included.
This rates adoption potential, not actual adoption. A live deployment should also report enrollment, passkey login share, success, fallback and error rates for a stated user group and time period.For automatic creation, calculate the upgrade rate as successful server registrations divided by conditional-registration requests sent after a completed password sign-in. Do not estimate whether the credential provider considered a request eligible.