Who should be accountable for defining when passkeys are used for login versus trusted action workflows?

Accountability should sit with identity, security, and application owners together, because the control affects authentication, authorisation, and workflow design. Teams need explicit policy for which actions require stronger proof of intent, how approvals are logged, and what evidence is retained for audit and incident review. Without clear ownership, passkey adoption can stop at login only.

Why This Matters for Security Teams

Passkeys change the login ceremony, but they do not automatically decide when a user has truly proven intent for a sensitive action. That boundary matters because authentication and authorisation are not the same control, and workflow owners often assume passkey login is enough for approvals, fund transfers, admin changes, or key rotation. Security teams need a shared policy model that separates sign-in from step-up verification and records who can define that threshold. NIST SP 800-53 Rev 5 Security and Privacy Controls makes that separation explicit through control families for identification, authentication, and access enforcement.

The accountability question is therefore organisational, not just technical. Identity teams usually own the authentication method, security teams own assurance and auditability, and application owners understand the risk of each workflow. When those three groups do not agree, passkeys get treated as a universal “done” signal and high-risk actions remain underprotected. NHI Management Group’s research on the Ultimate Guide to NHIs shows how often identity governance breaks down when ownership is unclear, with 97% of NHIs carrying excessive privileges. In practice, many security teams encounter this only after an approval flow or privileged action has already been granted an authentication level that was never designed for it.

How It Works in Practice

Clear accountability starts by defining three decisions: what counts as ordinary login, what counts as a trusted action, and who approves the policy that separates them. Identity owners typically manage passkey enrollment, recovery, and assurance requirements. Security owners define the minimum proof needed for step-up, such as re-authentication, device binding, session freshness, or phishing-resistant verification. Application owners map those rules to concrete workflows like payroll changes, API key issuance, account recovery, or delegated admin actions.

In mature environments, that policy is enforced at runtime rather than left to app developers to interpret. The workflow checks context such as the action type, data sensitivity, recent authentication strength, device posture, and whether the session has been continuously bound to the authenticated user. NIST guidance on access control and auditability supports this kind of evidence-driven design, especially where sensitive actions need explicit logging and review.

• Use passkeys for login by default, but require separate policy for trusted actions that alter risk.
• Assign one accountable owner for authentication policy, one for workflow risk, and one for audit evidence.
• Define which actions require step-up, re-authentication, or manager approval before execution.
• Log the policy decision, not just the login event, so incident review can reconstruct intent.

This is especially important when passkeys are combined with privileged workflows or machine-assisted approvals, because the question shifts from “did the user sign in?” to “was the action itself sufficiently authorised and evidenced?” The same logic appears in NHI governance where poor credential discipline creates exposure, as discussed in the GitHub Action tj-actions Supply Chain Attack analysis. These controls tend to break down when legacy applications only understand login success and cannot evaluate action-level policy at request time because the authorisation layer is too shallow.

Common Variations and Edge Cases

Tighter action-level controls often increase friction, requiring organisations to balance stronger assurance against user experience and operational speed. The right answer is not always “more prompts.” In some internal tools, passkey login may be sufficient for low-risk actions if the session is fresh and the user is operating within a narrow role. In high-risk workflows, current guidance suggests stronger proof of intent, but there is no universal standard for exactly which threshold should apply across every business function.

Edge cases usually appear in delegated administration, break-glass access, shared workstations, and workflows that mix human approval with automation. For those scenarios, accountability should still be explicit: policy definition belongs to the security governance function, implementation belongs to the application or platform owner, and exception handling belongs to the risk owner. External review under NIST SP 800-53 Rev 5 Security and Privacy Controls helps ensure the decision is documented, testable, and auditable. The practical failure point is usually hybrid environments where one app supports passkeys and another still relies on brittle session logic, because the policy boundary becomes inconsistent across the workflow.

Related resources from NHI Mgmt Group

• Who should be accountable for governing credentials used by developers, pipelines, and AI agents?
• How should security teams govern API keys used for generative AI access?
• Who is accountable when automated workflows retry a failed access action?
• Who is accountable when a trusted cloud identity is used for business email compromise?