Specify how business access should work, including recovery

The Swiss NCSC/BACS technology brief published on 19 October presents five authentication security categories, adapted from NIST and extended for real-time phishing resistance. Its HTML summary explicitly says this is not a basis for formal testing or certification. This is an evergreen requirements guide, not a new weekly announcement. (Swiss National Cyber Security Centre / BACS)

Start with the access a person actually has

Before comparing sign-in products, choose a few representative roles. An agency’s identity administrator, a colleague handling daily customer records and a person viewing occasional reports have different operating responsibilities. Use those roles to discuss consequences and recovery needs, rather than assigning everyone the same feature checklist.

For each role, record the applications it reaches, who grants and removes access, and which actions need a separate decision. Keep the inventory about access relationships; a requirements worksheet should contain references to managed records, not passwords, private keys or recovery codes.

An answer such as “MFA enabled” leaves several cells open. Ask which method is enabled for this account and which alternatives remain available. A product may offer a suitable capability without the relevant plan, policy or account actually using it.

Separate phishing resistance from key custody

NIST SP 800-63B-4 requires a phishing-resistant option to be offered at AAL2. AAL3 additionally requires a non-exportable private key; syncable authenticators do not meet that condition. These are technical assurance criteria, not a statement of Swiss legal obligations for every business. (NIST)

The distinction changes the questions you ask. If a team needs to prevent a credential being copied between devices, evidence about phishing resistance alone cannot answer that requirement. Equally, the fact that a credential can be synchronised does not by itself make it unsuitable for every role. Select the property the role needs, then assess the implementation against it.

The UK NCSC describes passkeys managed by credential managers, including synchronisation between trusted devices, and recommends passkeys where available. This explains a useful access method; it does not establish that every implementation, account-recovery path or enterprise policy has identical properties. (UK National Cyber Security Centre)

Keep convenience and custody as separate lines in the decision record. A team might value access across several managed devices for ordinary work, while a particular administrative function may have a different custody requirement. Those are proposed role decisions to validate, not product rankings or a formal mapping to BACS categories.

Evaluate the route back into the account

A normal sign-in demonstration is only part of an acceptance review. In an authorised test environment or provider-supported rehearsal, ask how the team would handle the following situations. No recovery or phishing test was performed for this article.

• A person loses their usual device but still has another approved authenticator. What evidence and approval permit access to continue?
• The only available authenticator is lost. Who can start recovery, what establishes the requester’s identity and how is the recovered account checked?
• A colleague leaves. Which account, authenticator and active-session records need review, and who records completion?
• A credential manager or device is suspected to be compromised. Which responsible person coordinates the separate investigation and access decisions?

The purpose is to expose dependencies before a real lockout or departure. A recovery procedure that depends on one unavailable administrator, an unrecorded personal device or an unknown helpdesk process is an open operating question. Record the gap and the responsible owner rather than declaring the whole service approved because its primary sign-in method looked strong.

Choose evidence before choosing a label

Ask a prospective provider to explain the method, its configuration, credential custody, recovery and session controls for the plan you would buy. Then ask for the evidence your team can retain: documented settings, an acceptance result for an agreed scenario and a named operating owner. Avoid filling a requirements matrix with marketing labels that nobody can verify.

The detailed BACS PDF was not reviewed for this guide, so no product receives one of its five categories here. The recommendations above are an editorial worksheet, not a certification, an assurance-level assessment or a finding that an organisation complies with a regulation.

No subscription or hardware-key prices have been verified. When budgeting, separate licensing, device provision, enrolment, recovery support and staff time. Available methods and administrative controls must be checked on the actual platform and plan; a public guide does not establish those entitlements.

A useful first deliverable is one completed role-based requirement record, reviewed by the person responsible for business access and the person who will support it. Resolve unknown recovery and offboarding responsibilities before treating a successful everyday sign-in as the end of the work.