A team can distribute security keys and help people register passkeys while leaving an older sign-in method available for the same applications. The enrollment project may be complete, but the claim that those applications require phishing-resistant authentication still needs evidence.
For cybersecurity award reviewers, the achievement lies in making stronger authentication dependable in ordinary work. That includes the protected sign-in routes, the people who can use them, the handling of lost devices, and the exceptions that remain. A convincing nomination connects those details to an improvement the nominee helped deliver.
Establish what the authentication method protects
Phishing-resistant authentication prevents a user from completing a valid authentication exchange with an impostor posing as the legitimate service. WebAuthn, the technology behind FIDO passkeys, binds authentication to the legitimate service's domain. A person cannot simply copy its authentication response into a convincing imitation website as they might relay a one-time code.
That distinction matters when evaluating a nomination. Text-message codes and manually entered authenticator codes can be phished. Matching a number in a push notification can improve on a simple approval prompt, but number matching alone does not make that method phishing-resistant. Likewise, a passwordless label does not establish phishing resistance.
Ask which method the team deployed and how users verify themselves. A passkey used with a device PIN or biometric can combine possession with user verification for multifactor authentication. Passkeys may be synced through a provider or bound to one device, including a physical security key. A good submission explains the choice in its environment without implying that every employee must carry a USB key.
Keep the conclusion bounded. Stronger sign-in does not establish protection against every endpoint compromise, stolen session, or abuse of authorized access.
Define coverage around real access routes
Start with the people, applications, devices, and period covered by the rollout. Administrative access might be the first priority, followed by a wider employee population. Contractors and guests may have different device or identity arrangements. State those boundaries explicitly.
Then separate three questions: who registered an eligible method, who used it, and where policy required it. Each answers something useful. None should stand in for the others.
Trace an application through its actual access routes. Does it rely on the central sign-in policy? Can a local account reach the same resource? Does another client follow different rules? If older authentication routes remain, explain their treatment. A strong central policy cannot prove coverage of a route that bypasses it.
Keep automated workloads separate from human sign-ins. A service identity running a scheduled task is not an employee who can respond to a device prompt. Explain which identities the reported coverage includes and who owns any separate safeguards for automation.
The guide to documenting cybersecurity impact for an award nomination can help turn this scope into a clear baseline and a result that reviewers can verify.
Ask for a successful sign-in and a rejected fallback
A registration report shows readiness. An enforced access decision shows whether the chosen requirement affects entry to the protected resource.
Ask for an approved test using a representative account and device. Show that the intended method allows access and that an older, disallowed method cannot satisfy the requirement on the same protected route. Record the application, account group, policy state, time, and observed decision. Report-only policy results can inform deployment, but they do not demonstrate that access was blocked.
Consider a hypothetical team that moves an administrative application from accepting either a passkey or a text-message code to requiring an approved phishing-resistant method. Its nomination could show the policy change, a successful passkey sign-in, and a denied attempt using the older method. That supports a specific claim about that application and tested route. It does not establish equivalent coverage for every application in the organization.
Use controlled test identities and approved procedures. An award submission does not need a live phishing exercise or exposed credentials to make the access decision understandable.
Follow recovery through to restored protection
A rollout must accommodate someone who loses a phone, damages a key, changes devices, or cannot use the expected verification method. Synced and device-bound passkeys create different recovery dependencies, so reviewers should ask what happens in the arrangement actually deployed.
Follow one approved recovery scenario from the request to normal access. Who verifies the person's identity? Who can authorize replacement or temporary access? How is the lost credential handled? What confirms that the replacement works and that any temporary arrangement has ended?
Judge a recovery path on its own terms. If it permits a weaker temporary method, name that exception and its boundaries. A claim about routine sign-in should not silently become a claim that every recovery step has the same phishing resistance.
Emergency access also deserves an accountable explanation. Reviewers need enough evidence to understand ownership, monitoring, testing, and the reason for an exception. They do not need the actual account names, recovery codes, or operating instructions that would expose sensitive access.
Recognize support that makes enforcement sustainable
People use different devices and work in different settings. Shared workstations, accessibility needs, remote onboarding, and restrictions on personal phones can change which methods are practical. Look for evidence that the team discovered those conditions before treating everyone as ready.
Useful support tells a person how to enroll, what to expect at sign-in, and where to get help. It also gives service desk staff a procedure they can follow without improvising an exception under pressure. The article on cybersecurity awareness that changes everyday decisions offers a useful way to assess whether guidance works beyond a training attendance record.
Ask what changed after a pilot. Perhaps the team supplied an alternative device, revised confusing enrollment instructions, or corrected an application policy. Credit the person who found and resolved that obstacle alongside the person who configured the identity platform.
Measure enforced coverage and unresolved gaps
Choose measures that match the claim. A nomination might report the share of in-scope users with a usable method, the share of relevant sign-ins meeting the enforced requirement, and the applications still awaiting coverage. Give every figure a period, denominator, and source.
Explain exclusions and exceptions beside the result. A high enrollment percentage can coexist with substantial access through older methods. Likewise, an increase in support requests during a pilot may reveal friction the team is actively fixing; it is not automatically evidence of a failed rollout.
Compare like periods and populations when describing improvement. Do not turn a short incident-free interval into proof that account takeover has been eliminated. Policy results, controlled checks, recovery records, and operational observations support narrower claims that reviewers can assess directly.
Make the shared contribution visible
Identity engineers, application owners, endpoint teams, service desk staff, and users all influence whether the change lasts. The discussion of breaking down silos in security teams helps identify the handoffs behind that result.
A focused nomination should answer five questions:
- Which people and access routes gained an enforced phishing-resistant requirement?
- What evidence distinguishes registration, use, and enforcement?
- What happened when a disallowed method was tested?
- How did recovery, support, and exceptions work in practice?
- What did the nominee contribute, and who maintains the improvement?
The strongest recognition makes a practical change visible: people can use the intended method, protected routes require it, and the organization understands what still falls outside that protection.