[ { "productId": "feitian", "storyId": "agent-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any enterprise API for provisioning, ordering, or assignment of keys — all documentation is consumer/end-user setup guides, and probes for API/docs endpoints returned 404s.", "evidenceIds": [ "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "agent-key-audit", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There is a SK Manager GUI tool for managing FIDO/PIV/OTP functions, but no evidence of any programmatic API, CLI output, or SDK exposing serial, firmware version, enabled applications, or credential state for automated fleet auditing by an agent; probes for API/docs endpoints all returned 404.", "evidenceIds": [ "feitian-docs-9", "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Feitian is a hardware FIDO key vendor with no evidence of an llms.txt or agent-oriented documentation; probes explicitly show 404s for llms.txt, markdown docs, and OpenAPI endpoints.", "evidenceIds": [ "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys is a hardware authentication device (security key) for FIDO2/WebAuthn login, not a data platform or analytics product; it has no data store or content for AI to generate insights from. This axis is a category error for a hardware security key.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are physical authentication hardware, not an automation/agent platform; autonomous background automations are entirely outside this product's category (wrong axis).", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware security/authentication tokens; they have no AI assistant functionality and the category itself is unrelated to AI task delegation.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian is a hardware FIDO security key/authentication device, not an AI agent or platform that consumes MCP tools; plugging in MCP servers is a wrong-axis question for this product category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys is a hardware security-key/authentication product, not an AI agent platform or service with an ecosystem for exposing tools to agents; MCP server connectivity is a wrong-axis question for this product category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are physical hardware authentication tokens; natural-language/AI-agent command interaction is not a relevant axis for a hardware security key product.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-public-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication devices with no documented public API for programmatic/agentic control; probes for llms.txt, docs-md, and OpenAPI specs all returned 404, and no evidence describes any API surface for AI agents to drive.", "evidenceIds": [ "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian is a hardware FIDO security key/authenticator product, not an API/credential-issuing platform or agent framework; issuing scoped API credentials for an AI agent is outside its product category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys is a hardware authentication device, not a service or platform with event-driven architecture; webhooks are a wrong axis for a physical security key product.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "api-interactive-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication devices, not an API/SDK product; an interactive API reference with runnable examples is a category mismatch (wrong axis) rather than a missing feature.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Feitian's FIDO key documentation covers WebAuthn/FIDO2 standards and setup guides but no OpenAPI/Swagger spec is published; explicit probes for llms.txt, docs-md, and openapi.json all returned 404.", "evidenceIds": [ "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys is a hardware authentication device, not a software/API product with sandbox vs production environments; the sandbox-testing story is a category error for this product type.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "api-versioning-policy", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication devices implementing the FIDO/WebAuthn standard, not a software service with an API surface for AI agents to consume; versioned APIs and deprecation policies are not a relevant axis for this product category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "attestation-enforcement", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack discusses FIDO attestation, AAGUID verification, metadata service (MDS) support, or any mechanism for security engineers to validate genuine Feitian key models at registration; the docs cover general FIDO compatibility, interfaces, and setup guides only.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication devices; defining automation rules triggered on events is a software/workflow automation capability entirely outside this product's category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication tokens for identity verification, not workflow/automation tools; scheduling recurring jobs is entirely outside this product's category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are hardware authentication devices; versioning, reviewing, or rolling back automations is not a capability applicable to this product category.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "backup-key-strategy", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "FAQ entries state that a lost key can be worked around by logging in with a backup security key or another method, then disabling the lost key and provisioning a new one, which is a real but minimal statement of a lockout-recovery strategy (feitian-docs-14, feitian-docs-24). However, there is no dedicated recovery guide explaining what is and isn't recoverable (e.g., per-relying-party re-registration necessity, loss of resident/discoverable credentials, biometric enrollment data) beyond this brief FAQ mention. Missing for 10: a structured recovery/lockout doc, explicit treatment of what is NOT recoverable (credentials tied to lost key), and guidance on enrolling multiple backup keys per service rather than just a generic FAQ answer.", "evidenceIds": [ "feitian-docs-14", "feitian-docs-24" ] }, { "productId": "feitian", "storyId": "bulk-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows per-device configuration tools (SK Manager, iePassManager) for individual FIDO/PIV/OTP settings, not organization-wide bulk provisioning, pre-registration workflows, or lifecycle/inventory tracking across a fleet of keys. No admin console, CSV/bulk import, or enterprise deployment tooling is documented.", "evidenceIds": [ "feitian-docs-9", "feitian-docs-10", "feitian-docs-15", "feitian-docs-22" ] }, { "productId": "feitian", "storyId": "certified-hardened-models", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of FIPS 140 validation, Common Criteria certification, or durability testing (water/crush resistance) for any Feitian key; all citations focus on protocol compatibility, interfaces, and setup guides. Missing for 10: FIPS 140 validation documentation, Common Criteria certification documentation, water/crush resistance durability specs.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "cli-key-management", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Feitian offers GUI tools (SK Manager, iePassManager, OTP Tool) for managing FIDO/PIV/OTP functions, PINs, and slots, but these are graphical utilities, not documented as scriptable CLIs. No evidence of a command-line interface, scripting API, or automation-friendly tooling for enabling apps, setting PINs, or reading device state. missing for 10: dedicated CLI tool, scripting/automation documentation, examples of headless/scriptable configuration workflows.", "evidenceIds": [ "feitian-docs-9", "feitian-docs-10", "feitian-docs-15", "feitian-docs-22" ] }, { "productId": "feitian", "storyId": "connector-lineup", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers interfaces (USB/NFC/BLE), biometric and OpenSK products, but never mentions specific form factors like USB-C vs USB-A connectors, keychain design, or nano/low-profile sizing — no product lineup breakdown by physical form is shown.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "credential-management", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "FEITIAN provides tools (SK Manager, iePassManager) described as managing 'FIDO PIN and credential related operations' on the key, implying some list/delete capability, and one product page claims 'no limit to accounts' for the MultiPass key. However, there is no explicit documentation of a list/delete-passkey UI, no discussion of credential capacity limits for other models, and no guidance on capacity awareness before a key fills up. missing for 10: explicit list/delete UI screenshots or steps, documented per-model credential capacity limits, and warnings/behavior when storage is full.", "evidenceIds": [ "feitian-docs-9", "feitian-docs-15", "feitian-docs-12" ] }, { "productId": "feitian", "storyId": "cross-platform-compat", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Feitian documents cross-platform compatibility (Windows, macOS, Linux, Android/iOS) and integration guides for specific platforms (Windows Hello, Azure AD, GitHub/OpenSSH, Google Advanced Protection, PIV/macOS), and multi-interface support (USB/NFC/BLE) which implies broad OS/browser reach. However there is no published, centralized compatibility catalog or matrix listing supported browsers/services, and no independent verification of claims. Missing for 10: a formal published compatibility catalog/matrix of supported services and browsers, independent/hands-on verification of cross-platform claims.", "evidenceIds": [ "feitian-docs-1", "feitian-docs-2", "feitian-docs-6", "feitian-docs-8", "feitian-docs-10", "feitian-docs-19", "feitian-docs-20", "feitian-docs-25" ] }, { "productId": "feitian", "storyId": "enterprise-delivery-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any API, console, or enterprise fulfillment/logistics/shipping-management capability; probes confirm no API/docs exist for this. Evidence covers only device features (FIDO2, biometrics, NFC/BLE/USB) and setup guides, nothing about distributed shipping orchestration.", "evidenceIds": [ "feitian-probe-1", "feitian-probe-2", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "fido2-resident-passkeys", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Feitian's keys are explicitly W3C WebAuthn/FIDO2 compliant and marketed for passwordless sign-in scenarios like Windows Hello and Google Advanced Protection, which typically rely on discoverable credentials, but the evidence never explicitly names 'resident keys' or 'discoverable credentials' or confirms a specific stored-credential capacity/no-username login flow. Missing for 10: explicit documentation of resident-key/discoverable-credential support, stated credential storage limits, and a hands-on demonstration of username-less WebAuthn sign-in.", "evidenceIds": [ "feitian-docs-1", "feitian-docs-2", "feitian-docs-25", "feitian-docs-11" ] }, { "productId": "feitian", "storyId": "firmware-update-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of security advisories, CVE tracking, affected-model lookup tools, or a documented firmware update delivery mechanism; only general product/setup docs and an OpenSK build guide are present, none of which address vulnerability response or patch distribution.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "guided-enrollment", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Feitian provides first-party guided documentation for pairing keys (BLE setup guide), registering with specific platforms (Windows, Azure AD, Microsoft, GitHub/Linux via OpenSSH), and a dedicated SK Manager desktop app for configuring FIDO/PIV/OTP functions, which together resemble a guided enrollment flow for a power user. However, missing for 10: independent/hands-on user reports confirming the setup experience is clear in practice, and no single unified 'wizard' walkthrough spanning consumer-account registration (e.g., Google/Microsoft account UI) rather than platform/OS-level docs.", "evidenceIds": [ "feitian-docs-5", "feitian-docs-6", "feitian-docs-7", "feitian-docs-8", "feitian-docs-9", "feitian-docs-21" ] }, { "productId": "feitian", "storyId": "hardware-approval-for-agents", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Feitian keys are standard FIDO2/WebAuthn/U2F hardware tokens that inherently require a physical touch to complete authentication (feitian-docs-1, feitian-docs-4, feitian-docs-18), which is the underlying mechanism that could be wired into an agent's approval flow via WebAuthn. However, there is no evidence of any AI-agent-specific integration, SDK, or documented workflow showing the key used as a human-approval gate for agent-initiated actions. Missing for 10: explicit AI-agent/automation integration examples, documentation of using the key as an approval gate in agentic pipelines, and any third-party corroboration of this use case.", "evidenceIds": [ "feitian-docs-1", "feitian-docs-4", "feitian-docs-18" ] }, { "productId": "feitian", "storyId": "hardware-backed-ssh", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Feitian docs explicitly cover FIDO2 sk-ssh usage for OpenSSH/GitHub/Linux server login (feitian-docs-6) and PIV smart-card functionality including macOS PIV logon via SK Manager (feitian-docs-9, feitian-docs-10), supporting hardware-backed SSH auth with physical touch. However, no OpenPGP-based SSH key support is documented anywhere in the pack. Missing for 10: explicit OpenPGP applet/SSH support, independent/hands-on verification of sk-ssh workflow, and unified documentation tying all three methods together.", "evidenceIds": [ "feitian-docs-6", "feitian-docs-9", "feitian-docs-10" ] }, { "productId": "feitian", "storyId": "idp-policy-integration", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Feitian keys are documented as fully W3C WebAuthn/FIDO2-compliant HID devices with explicit setup guides for Azure AD-joined Windows, Microsoft applications, and Google Advanced Protection, which implies interoperability with major identity providers. However, there is no explicit documentation or guide for Okta or Google Workspace integration, nor any mention of admin-side policy enforcement (e.g., requiring hardware-key-only auth) within these IdPs. Missing for 10: Okta-specific integration guide, Google Workspace-specific setup docs, and evidence of IdP admin policy controls enforcing hardware-key requirements.", "evidenceIds": [ "feitian-docs-1", "feitian-docs-8", "feitian-docs-21", "feitian-docs-25", "feitian-docs-2" ] }, { "productId": "feitian", "storyId": "nfc-mobile-tap", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "MultiPass FIDO Security Key explicitly supports NFC as one of three interfaces and is documented compatible with Android/iOS platforms, implying tap-to-authenticate via NFC on mobile; however, evidence doesn't explicitly confirm NFC (vs BLE) works with specific mobile browsers/apps or provide hands-on confirmation. missing for 10: explicit mobile browser/app NFC tap walkthrough, independent hands-on verification of NFC mobile authentication.", "evidenceIds": [ "feitian-docs-4", "feitian-docs-18", "feitian-docs-19" ] }, { "productId": "feitian", "storyId": "official-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers WebAuthn/FIDO2 standard support, OS integrations (Windows Hello, Azure AD, OpenSSH), and firmware provisioning via Google's OpenSK repo, but nothing indicates Feitian ships its own official SDK for developers to embed key support into custom desktop/mobile apps. Probe results also confirm no API/docs discoverability artifacts. This is an applicable axis for a hardware key vendor (SDKs are common in this space) but no evidence of one existing.", "evidenceIds": [ "feitian-docs-11", "feitian-docs-23", "feitian-probe-3" ] }, { "productId": "feitian", "storyId": "open-source-firmware", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Feitian offers a specific OpenSK hardware variant where users can build firmware from Google's open-source OpenSK repo and flash it themselves, directly addressing the transparency concern for that model. However, the flagship BioPass and MultiPass FIDO keys firmware is not documented as open source or independently audited, and no third-party security audit reports are cited anywhere in the pack. missing for 10: independent firmware audit reports for mainstream product lines, confirmation that BioPass and MultiPass firmware not just the niche OpenSK SKU is open or audited, and hands-on verification that shipped OpenSK devices match the public source", "evidenceIds": [ "feitian-docs-11", "feitian-docs-23" ] }, { "productId": "feitian", "storyId": "openness-api-parity", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "openness-open-license", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Feitian ships a specific 'OpenSK' hardware variant that can run firmware built from Google's open-source OpenSK repository, giving some access to readable/open-licensed source for that SKU, but this is a third-party (Google) codebase, not Feitian's own firmware for its mainstream BioPass/MultiPass keys, which remain closed. Missing for 10: evidence that Feitian's own primary product firmware/source is published under an open license, and no indication of a public source repo, license file, or docs-as-markdown/API spec for the broader product line.", "evidenceIds": [ "feitian-docs-11", "feitian-docs-23" ] }, { "productId": "feitian", "storyId": "openness-self-host", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "The FIDO key is inherently a local, on-device hardware authenticator (not a hosted service), and Feitian explicitly documents that users can build firmware from Google's open-source OpenSK repository and provision it onto the hardware themselves, giving genuine control over the 'core product' without vendor cloud dependency. This is a reasonable analog to self-hosting for a hardware device, but it's not a full self-hostable software stack with deployment docs, and there's no evidence of self-hosted backend/server components (e.g., FIDO server, attestation service) that would round out a complete self-hosting story. Missing for 10: documentation of self-hosting any server-side/relying-party components, deployment guides beyond firmware flashing, and independent confirmation of OpenSK build success.", "evidenceIds": [ "feitian-docs-11", "feitian-docs-23" ] }, { "productId": "feitian", "storyId": "openpgp-onkey", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers FIDO/U2F, PIV, OTP, and OpenSSH use cases, but there is no mention of OpenPGP key storage, git commit signing, or encrypted email support anywhere in the pack.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "otp-legacy-slots", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Feitian documents HOTP functionality that emulates HID keyboard to auto-type OTP values, plus an OTP Tool to switch protocols and an SK Manager to manage OTP/PIV/FIDO functions, confirming legacy OTP slot support beyond WebAuthn. However, there's no detail on TOTP support, challenge-response mode, or number of OTP slots available. Missing for 10: TOTP-specific documentation, challenge-response mode details, slot capacity/configuration specifics, and independent hands-on verification.", "evidenceIds": [ "feitian-docs-13", "feitian-docs-22", "feitian-docs-9" ] }, { "productId": "feitian", "storyId": "pin-biometric-verification", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Feitian documents biometric (fingerprint) on-device user verification for BioPass keys, explicitly noting 'losing the key will cause no security risk at all,' and separately documents FIDO PIN management via iePassManager for PIN/credential operations, satisfying the on-device UV requirement. Missing for 10: independent/hands-on verification of PIN enforcement or biometric FAR/FRR, and no explicit CTAP2 'uv' flag documentation.", "evidenceIds": [ "feitian-docs-3", "feitian-docs-17", "feitian-docs-15", "feitian-docs-9" ] }, { "productId": "feitian", "storyId": "piv-smartcard-login", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Feitian documents PIV smart card functionality via the SK Manager tool, including macOS PIV smart card logon configuration and general PIV/FIDO/OTP management, supporting workstation sign-in use cases. However, evidence does not explicitly confirm VPN certificate-based authentication or code signing use cases with PIV, nor detail Windows/Active Directory PIV smart card logon specifically. Missing for 10: explicit VPN certificate-auth documentation, code-signing workflow evidence, Windows PIV smart card logon docs, and independent/third-party validation of PIV compliance.", "evidenceIds": [ "feitian-docs-9", "feitian-docs-10" ] }, { "productId": "feitian", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys are physical hardware authentication devices with no cloud data storage component; data residency/region choice is not applicable to a local hardware security key that stores no user data in a service backend.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Feitian FIDO Keys is a hardware authentication device (security key for FIDO2/U2F/WebAuthn), not an AI service or data platform that trains models on user data. The concept of 'preventing data from being used for AI training' is a category error for this product type.", "evidenceIds": [] }, { "productId": "feitian", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "feitian", "storyId": "webauthn-second-factor", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "First-party docs confirm W3C WebAuthn/U2F compliance and dedicated guides for GitHub (OpenSSH), Microsoft/Azure AD, and Google Advanced Protection, showing broad cross-service compatibility. Missing for 10: explicit password-manager (e.g., 1Password/Bitwarden) integration guidance and independent/hands-on verification beyond vendor documentation.", "evidenceIds": [ "feitian-docs-1", "feitian-docs-6", "feitian-docs-8", "feitian-docs-21", "feitian-docs-25" ] }, { "productId": "google-titan", "storyId": "agent-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "This is a hardware security key with human-driven web console setup (enroll, pair, reset) via support docs; there is no evidence of any enterprise API for agent-driven ordering, assignment, or pre-registration of keys. missing for 10: documented provisioning/management API, evidence of programmatic ordering or fleet assignment, any agent/automation-facing endpoint.", "evidenceIds": [ "google-titan-docs-15", "google-titan-docs-9", "google-titan-docs-11" ] }, { "productId": "google-titan", "storyId": "agent-key-audit", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-agent-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a physical hardware authentication device, not an AI agent or documentation-serving platform; the concept of pointing an agent at llms.txt or agent-oriented docs is a category error for this product type.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not a data/insights product; AI-generated insights from user data is a category error for this product type.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an agent or automation platform; setting up autonomous background automations is outside its category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an AI assistant or agent platform; delegating tasks to a built-in AI assistant is not a fair axis for this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an AI agent or platform capable of connecting to MCP servers or using tools; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an agent or platform that could expose an MCP server; connecting AI agents via MCP is outside its product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an interface that accepts natural-language commands; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-official-cli", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-public-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device for human 2FA/passkey login, not an API credential or agent-identity management system; issuing scoped API credentials for autonomous agents is entirely outside its product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not a service or platform with event-driven APIs; webhook subscriptions are entirely outside its product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "api-interactive-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Google Titan Security Key is a hardware authentication device, not a developer API/platform; interactive API references with runnable examples are not applicable to this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "api-machine-spec", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an API/service product; a machine-readable API spec is a category mismatch (wrong axis) for this kind of product.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a physical hardware authentication device, not an AI/dev platform with a sandbox vs production environment concept; this story's axis does not apply to this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "api-versioning-policy", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an API/SDK product; the concept of versioned APIs with deprecation policy is a category error for this product type.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "attestation-enforcement", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Docs claim the key's hardware chip/firmware 'verifies that the keys haven't been tampered with' and provides 'cryptographic proof' of legitimate registration (google-titan-docs-12, docs-14, docs-20), which gestures at attestation, but there is no documentation or tooling aimed at security engineers for inspecting attestation certificates or enforcing an approved-model allowlist at registration. A hands-on report directly undercuts the 'genuine, approved model' framing: a user's non-Google Feitian MultiPass key (identical hardware to Titan) was accepted by Google's own replacement/registration system as if it were an official Titan key, showing the attestation/verification does not reliably distinguish genuine Titan units from rebranded third-party hardware (google-titan-comm-12, comm-14). Missing for 10: security-engineer-facing attestation verification API/metadata service, documented enforcement of approved key models, and any first-party/independent confirmation that model spoofing is prevented.", "evidenceIds": [ "google-titan-docs-12", "google-titan-docs-14", "google-titan-docs-20", "google-titan-comm-12", "google-titan-comm-14" ] }, { "productId": "google-titan", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device for 2FA/passkey sign-in; it has no automation/rules engine or event-trigger capability, and this axis is a category error for a physical security key.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not a workflow/automation or job-scheduling tool; scheduling recurring jobs is entirely outside its product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device, not an automation/workflow platform; versioning, reviewing, or rolling back automations is not a fair capability to expect from this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "backup-key-strategy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Google docs cover removing a lost key from an account (google-titan-docs-9) and enrolling a security key (google-titan-docs-15), and a community comment notes Google's own guidance to keep one key in daily use and store a backup safely (google-titan-comm-3), implying an informal backup-key strategy. However there is no first-party documentation laying out a full lockout-recovery plan (e.g., how to regain account access before removing the key, what happens if the only registered key is lost, or explicit backup-key enrollment steps). missing for 10: explicit vendor doc on account lockout scenarios, dedicated backup-key enrollment walkthrough, and clarity on what is/isn't recoverable if the sole key is lost", "evidenceIds": [ "google-titan-docs-9", "google-titan-docs-15", "google-titan-comm-3", "google-titan-comm-5" ] }, { "productId": "google-titan", "storyId": "bulk-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers individual end-user setup, pairing, resetting, and removing a single key, but nothing addresses IT-admin fleet capabilities like bulk pre-registration, centralized provisioning, or lifecycle/inventory tracking across an organization. Missing for 10: bulk enrollment tools/API, admin console integration for mass key registration, and lifecycle/inventory tracking dashboards.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "certified-hardened-models", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of FIPS 140 validation or Common Criteria certification for Titan Security Keys, nor documented water/crush resistance specs; in fact, one community report suggests the underlying Feitian hardware is fragile if dropped, contradicting any durability certification claim. missing for 10: FIPS 140 validation documentation, Common Criteria certification documentation, official durability/water-crush resistance specs.", "evidenceIds": [ "google-titan-comm-1" ] }, { "productId": "google-titan", "storyId": "cli-key-management", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "connector-lineup", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Docs confirm two form factors—USB-A/NFC and USB-C/NFC—but there is no evidence of a keychain or nano low-profile model, and community feedback even calls the (Bluetooth) key large rather than low-profile. missing for 10: keychain form factor, nano/low-profile form factor, independent hands-on confirmation of size/portability across the full claimed lineup.", "evidenceIds": [ "google-titan-docs-13", "google-titan-comm-6" ] }, { "productId": "google-titan", "storyId": "credential-management", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence covers removing a key from a Google account and unpairing Bluetooth, but there is no mention of an on-key credential management tool that lists or deletes individual passkeys stored on the Titan key itself, nor any documentation of the key's credential storage capacity or warnings about it filling up.", "evidenceIds": [ "google-titan-docs-9", "google-titan-docs-10" ] }, { "productId": "google-titan", "storyId": "cross-platform-compat", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Google's docs claim broad cross-platform support (Android/iOS NFC, Linux setup via udev, FIDO CTAP1 compatibility with third-party sites) but there is no published catalog of specific supported services/sites—just a generic FIDO-standard compatibility statement. Community reports directly contradict smooth cross-browser/OS support: one user found keys 'only' worked with Chrome and failed on Mac despite official docs, while others reported success with Firefox on Linux and pairing issues on Mac, showing inconsistent real-world compatibility. missing for 10: an actual published list/catalog of compatible services, and confirmation that browser/OS support claims hold up without conflicting user reports.", "evidenceIds": [ "google-titan-docs-3", "google-titan-docs-4", "google-titan-docs-6", "google-titan-comm-4", "google-titan-comm-7", "google-titan-comm-8", "google-titan-comm-13" ] }, { "productId": "google-titan", "storyId": "enterprise-delivery-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any bulk-shipping logistics, distribution API, admin console, or fleet-provisioning workflow for shipping keys to distributed employees; evidence covers only individual key setup, replacement RMA process, and hardware/community feedback.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "fido2-resident-passkeys", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "Docs confirm passkey creation for Google Accounts (implying a discoverable, device-bound credential that lets sign-in without typing a password) via google-titan-docs-2, but the same docs explicitly describe third-party site support only via 'FIDO CTAP1 standards' (google-titan-docs-4), which does not guarantee resident-key/FIDO2 support broadly. No explicit mention of FIDO2/CTAP2 or 'discoverable credentials' terminology anywhere in the pack. Missing for 10: explicit FIDO2/CTAP2 protocol documentation, direct mention of resident/discoverable credentials, and independent verification of username-less sign-in across non-Google WebAuthn services.", "evidenceIds": [ "google-titan-docs-2", "google-titan-docs-4", "google-titan-docs-15", "google-titan-docs-16" ] }, { "productId": "google-titan", "storyId": "firmware-update-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "There is concrete real-world evidence of one incident: a BLE pairing vulnerability was disclosed, Google emailed affected users ('Update on your Titan Security Key') and ran a replacement program rather than a firmware patch, showing some vulnerability-response process exists but it worked through physical device replacement, not an in-field firmware update, and users found the replacement process cumbersome. There is no published advisory list/CVE tracker or affected-model lookup tool in the evidence — docs only vaguely mention Google-engineered firmware for tamper verification. Missing for 10: a public security-advisory/CVE page, a documented affected-model/serial lookup tool, and an actual firmware-update delivery mechanism (evidence shows fixes require full device replacement, not a firmware push).", "evidenceIds": [ "google-titan-docs-12", "google-titan-docs-20", "google-titan-comm-9", "google-titan-comm-10", "google-titan-comm-11", "google-titan-comm-12" ] }, { "productId": "google-titan", "storyId": "guided-enrollment", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Google's support docs give step-by-step guided enrollment (sign in, 'Enroll your security key', device detects it and walks through sign-in) and cover related setup nuances like Linux udev rules and NFC/Bluetooth pairing, but there is no dedicated setup app—just web help pages. Community reports also note friction during first-time use (Chrome-only compatibility issues, Bluetooth key not pairing with Mac), suggesting the guided flow isn't universally smooth across platforms/browsers. Missing for 10: a purpose-built setup wizard/app, cross-browser first-run guidance, and independent confirmation that the documented steps work smoothly on all platforms.", "evidenceIds": [ "google-titan-docs-15", "google-titan-docs-16", "google-titan-docs-1", "google-titan-docs-6", "google-titan-comm-4", "google-titan-comm-13" ] }, { "productId": "google-titan", "storyId": "hardware-approval-for-agents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows Titan Security Key being used for standard account sign-in / 2-Step Verification via FIDO/U2F, with no mention of any API, SDK, or workflow that lets an AI agent request a physical-touch approval gate for its own automated actions. Nothing in the docs or community discussion ties the key's touch requirement to agent-initiated or automated action approval.", "evidenceIds": [ "google-titan-docs-1", "google-titan-docs-14", "google-titan-docs-4" ] }, { "productId": "google-titan", "storyId": "hardware-backed-ssh", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers only FIDO2/U2F use for Google/web sign-in, Bluetooth pairing, NFC, and physical hardware details — there is no mention of sk-ssh, PIV, OpenPGP, or any SSH-key hardware-backing capability. missing for 10: sk-ssh/FIDO2 SSH key support, PIV applet, OpenPGP applet, any developer SSH workflow documentation.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "idp-policy-integration", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers consumer/personal account setup, Bluetooth pairing, form factors, and hardware attestation, but contains no evidence of IT-admin-facing integration with identity providers like Okta, Entra ID, or Google Workspace admin console policy enforcement for hardware-key-only authentication. This is a fair axis for a hardware security key vendor to address (fleet policy enforcement via IdP), but no such capability or documentation is present.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "nfc-mobile-tap", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs confirm the USB-A/NFC and USB-C/NFC key models work over NFC with compatible Android and iOS devices (iOS 13.3+), covering mobile browser/app authentication. Missing for 10: independent hands-on confirmation of NFC tap-to-auth specifically in third-party mobile apps (community evidence focuses mainly on Bluetooth/desktop use, not NFC mobile app flows).", "evidenceIds": [ "google-titan-docs-3", "google-titan-docs-13", "google-titan-docs-21" ] }, { "productId": "google-titan", "storyId": "official-sdks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "open-source-firmware", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Google explicitly states firmware is 'developed by Google' and used to verify tamper-resistance, but there is no evidence of open-source firmware or independent third-party audit reports; community evidence only discusses hardware manufacturing (Feitian OEM) and a Bluetooth vulnerability, not firmware transparency/auditing. missing for 10: any published audit report, open-source firmware repository, or independent verification of firmware code.", "evidenceIds": [ "google-titan-docs-12", "google-titan-docs-20", "google-titan-comm-9" ] }, { "productId": "google-titan", "storyId": "openness-api-parity", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "openpgp-onkey", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a FIDO/U2F authenticator with no documented OpenPGP applet or smartcard support for git commit signing or encrypted email; evidence only covers FIDO2/U2F sign-in use cases.", "evidenceIds": [ "google-titan-docs-4", "google-titan-docs-14" ] }, { "productId": "google-titan", "storyId": "otp-legacy-slots", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a FIDO/U2F/WebAuthn hardware authenticator; no evidence indicates it supports TOTP/HOTP seed storage or generic challenge-response slots for legacy OTP services. All documentation focuses on FIDO CTAP1/U2F/WebAuthn use cases only.", "evidenceIds": [ "google-titan-docs-4", "google-titan-docs-14" ] }, { "productId": "google-titan", "storyId": "pin-biometric-verification", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes Titan Security Keys as simple touch-based FIDO/U2F/FIDO2 keys (USB-A/NFC, USB-C/NFC, Bluetooth) with no mention of an on-device PIN pad or biometric sensor for user verification; all sign-in flows described are 'insert/tap key' without any PIN or biometric step. Missing for 10: any documentation of a FIDO2 PIN-setting flow, a fingerprint/biometric sensor, or independent confirmation of on-device user verification.", "evidenceIds": [ "google-titan-docs-2", "google-titan-docs-15", "google-titan-docs-16", "google-titan-docs-13" ] }, { "productId": "google-titan", "storyId": "piv-smartcard-login", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence only covers FIDO/U2F/FIDO2 authentication (Google Sign-In, CTAP1 sites, Advanced Protection) — no mention of PIV smart card mode, certificate-based login, workstation sign-in via smart card, VPN client certs, or code-signing use cases.", "evidenceIds": [ "google-titan-docs-4", "google-titan-docs-11", "google-titan-docs-14" ] }, { "productId": "google-titan", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a physical hardware authentication device, not a data storage or cloud service; data residency/region choice is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Titan Security Key is a hardware authentication device for account security; it has no relationship to AI training data usage or data governance controls, so this axis does not apply to this product category.", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "google-titan", "storyId": "webauthn-second-factor", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Google's own docs confirm broad FIDO/U2F and CTAP1 compatibility beyond Google services and even Advanced Protection use, implying standards-based interoperability, but no evidence explicitly names GitHub, Microsoft, or password-manager integrations. Community reports also flag real-world friction (e.g., 'You can only use Security Keys with Google Chrome' on Mac), showing cross-browser/service compatibility isn't seamless everywhere.\nmissing for 10: explicit confirmation/testing with GitHub, Microsoft accounts, and specific password managers; resolution of the Chrome-only browser limitation reported by users.", "evidenceIds": [ "google-titan-docs-4", "google-titan-docs-5", "google-titan-docs-11", "google-titan-comm-4", "google-titan-comm-7", "google-titan-comm-8" ] }, { "productId": "nitrokey", "storyId": "agent-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Nitrokey documents an nitropy CLI for on-device configuration and an Entra ID provisioning integration, but there is no evidence of a documented enterprise API supporting agent-driven ordering, assignment, or pre-registration workflows — OpenAPI/API probes all returned 404. missing for 10: documented REST/enterprise API for ordering and fleet assignment, evidence of programmatic pre-registration, any API reference beyond CLI tooling.", "evidenceIds": [ "nitrokey-docs-18", "nitrokey-docs-14", "nitrokey-probe-3", "nitrokey-probe-rt-1" ] }, { "productId": "nitrokey", "storyId": "agent-key-audit", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "The official nitropy CLI (and Python SDK) can programmatically query device attributes such as version and connected devices (e.g., 'nitropy version', device listing), giving agents a scriptable way to pull serial/firmware info, and firmware update tooling is documented. However, there is no evidence of a documented way to enumerate 'enabled applications' or 'stored credentials' via CLI/API for fleet-wide security audits, and no fleet-management or structured (JSON/API) output is shown. Missing for 10: documented commands/output for enabled applications and stored credential enumeration, structured machine-readable output format, and any fleet-audit tooling or API/OpenAPI spec (probes show none exists).", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-rt-1", "nitrokey-probe-4", "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly confirm no llms.txt or agent-oriented docs endpoint exists (404s), and no evidence of AI-native documentation is present anywhere in the pack.", "evidenceIds": [ "nitrokey-probe-1", "nitrokey-probe-2", "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/authentication device (FIDO2, OpenPGP, PIV, encrypted storage); it has no data-analysis or AI-insight surface, so AI-generated insights from user data is a category error for this product type.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM for authentication, encryption, and key storage — it has no automation/orchestration layer for background autonomous tasks; this axis is a category error for a security token product.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product for authentication, encryption, and secure key storage — it has no AI assistant feature, and delegating tasks to a built-in AI assistant is entirely outside its product category.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Nitrokey ships an official CLI (nitropy) that installs headlessly via pip/uvx and can be scripted, which is the closest evidence to CI-style automation (nitrokey-docs-14, nitrokey-probe-4, nitrokey-probe-rt-1). However, there is no documentation of CI pipelines, headless authentication flows, or automation guides, and the core use cases (FIDO2/OTP/PGP) inherently require physical touch presence, limiting true headless operation. Missing for 10: explicit CI/automation documentation, examples of nitropy used in pipelines, and clarification on how touch-required operations are handled headlessly.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1" ] }, { "productId": "nitrokey", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM device for authentication, encryption, and credential storage — it has no relevant role as an MCP client or agentic tool host, so plugging in MCP servers is a category error for this product.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM device, not an AI agent or service platform that would expose an MCP server for agent connectivity; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a physical hardware security key/token operated via touch, PIN entry, and a technical CLI (nitropy) for configuration — natural-language command interaction is not a relevant axis for this class of authentication hardware.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Nitrokey ships an official, actively maintained CLI (nitropy) documented at docs.nitrokey.com and verified at runtime to install cleanly via PyPI/uvx and report its version, confirming it works as claimed for scripting/automation-style interaction with the device. Missing for 10: no evidence of AI-agent-specific integration, tool-calling support, or third-party corroboration of the CLI's use in agentic workflows.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1" ] }, { "productId": "nitrokey", "storyId": "agentic-public-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Nitrokey ships a documented CLI/SDK (nitropy, pynitrokey) that lets scripts/agents drive the hardware token programmatically, confirmed by runtime probes showing it installs and runs from PyPI. However, there is no REST/OpenAPI-style public API — explicit probes for llms.txt, docs-md, and openapi.json all 404 — so an AI agent has no network-callable documented API, only a local CLI/SDK. Missing for 10: a documented HTTP/OpenAPI public API, machine-readable API spec, and any AI-agent-specific integration guidance.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1", "nitrokey-probe-1", "nitrokey-probe-2", "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product for authentication, encryption, and signing (FIDO2, OpenPGP, PIV, etc.), not an API/credential-issuing platform for AI agents. Issuing scoped API credentials for an agent is a category error for this product type.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Nitrokey publishes an official CLI (nitropy) and a Python SDK (pynitrokey) on PyPI, both confirmed working via runtime probes, and firmware/source are open on GitHub — giving developers a real path to build against official tooling. However there's no evidence of broader multi-language SDKs, API references beyond nitropy, or any AI/agent-specific integration surface (no OpenAPI, no llms.txt, probes for both 404). Missing for 10: multi-language/official SDKs beyond Python, formal API docs/OpenAPI spec, AI-agent-specific integration examples.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1", "nitrokey-gh-2", "nitrokey-probe-1", "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product; webhooks/event subscription is a SaaS/API integration concept that does not apply to this category of device.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Probes explicitly show no OpenAPI/interactive API reference exists (404s for openapi.json, swagger.json, etc.), and no docs mention runnable examples or an interactive API explorer despite Nitrokey having a CLI (nitropy) and Python SDK.", "evidenceIds": [ "nitrokey-probe-3", "nitrokey-probe-1", "nitrokey-probe-2", "nitrokey-docs-14" ] }, { "productId": "nitrokey", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key vendor; the probe explicitly checked for a machine-readable API spec (openapi.json, swagger.json, etc.) and all candidates returned 404, with no OpenAPI/Swagger spec documented anywhere in the evidence pack.", "evidenceIds": [ "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product for authentication, encryption, and key storage — not an AI agent, SaaS platform, or testing framework with sandbox/production data separation for AI workflows. This axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Nitrokey ships a versioned CLI (nitropy) and Python SDK, but there is no evidence of a documented API deprecation policy, versioned public API, or OpenAPI spec — probes explicitly show 404s for OpenAPI/llms.txt discovery. The axis applies since Nitrokey does provide developer tooling, but no deprecation-policy documentation exists in the evidence.", "evidenceIds": [ "nitrokey-probe-3", "nitrokey-probe-1", "nitrokey-probe-rt-1", "nitrokey-docs-14" ] }, { "productId": "nitrokey", "storyId": "attestation-enforcement", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Nitrokey ships FIDO2 (which includes device attestation) and PIV, but there is no documentation of an attestation verification workflow for registration, and a hands-on report notes attestation certificates can't be exported via standard PKCS#11 and require a custom vendor tool plus a non-standard ASN.1 cert format, adding real friction for engineers building attestation checks. missing for 10: first-party docs on attestation cert format/verification API, standard PKCS#11/FIDO2 attestation export support, independent confirmation of a smooth registration-time attestation check.", "evidenceIds": [ "nitrokey-docs-1", "nitrokey-comm-2" ] }, { "productId": "nitrokey", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Nitrokey ships a CLI (nitropy) and Python SDK that could in principle be scripted, but no evidence in the pack shows any documented bulk-operation workflow (e.g., batch provisioning, mass key management, scripted multi-device automation) for AI-native or automated bulk use. Only single-device/product feature lists and an 'Entra ID provisioning' mention appear, with no concrete bulk-operation documentation or example. missing for 10: documented bulk/batch API or CLI commands, evidence of managing many items/devices at once, automation examples for large-scale provisioning.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-docs-18", "nitrokey-probe-rt-1" ] }, { "productId": "nitrokey", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/token for authentication, encryption, and key storage — not an automation/rules-engine product; defining event-triggered rules is outside its category of functionality.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/token for authentication, encryption, and key storage; scheduling recurring jobs or workflows is entirely outside its product category as a physical security device.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product for authentication, encryption, and key storage — it has no concept of 'automations' to version, review, or roll back; this axis belongs to workflow/agent orchestration tools, not a security token.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "backup-key-strategy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item documents a vendor-provided lockout-recovery strategy (e.g., registering a backup Nitrokey, or what OpenPGP/FIDO2/PIV credentials are or are not recoverable if a key is lost). The closest mention is a third-party community comment about offline key escrow for the unrelated HSM product, not official documentation of recovery/backup-key enrollment.", "evidenceIds": [ "nitrokey-comm-1" ] }, { "productId": "nitrokey", "storyId": "bulk-fleet-provisioning", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Nitrokey ships an official CLI (nitropy) and Python SDK for scripting device operations, and docs reference 'Nitrokey Provisioning for Entra ID,' suggesting some enterprise provisioning path exists, but there is no evidence of bulk pre-registration workflows, centralized fleet dashboards, or lifecycle/audit tracking across many issued keys. missing for 10: bulk enrollment/pre-registration tooling, centralized admin console for fleet inventory, lifecycle/revocation tracking at scale, independent case studies of large deployments.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-rt-1", "nitrokey-docs-18" ] }, { "productId": "nitrokey", "storyId": "certified-hardened-models", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Nitrokey documents a Common Criteria EAL 6+ certified secure element in the Nitrokey 3 (nitrokey-docs-16), satisfying the certification half of the story, but there is no mention anywhere in the evidence of FIPS 140 validation, nor any documented water/crush-resistance or ruggedization specs. Community hands-on feedback actively undercuts the durability angle, describing the U2F key as feeling 'flimsy' compared to competitors (nitrokey-comm-3, nitrokey-comm-4). Missing for 10: FIPS 140 validation evidence, explicit IP/MIL-STD or water/crush durability specs, and independent corroboration of ruggedness rather than community complaints about build quality.", "evidenceIds": [ "nitrokey-docs-16", "nitrokey-comm-3", "nitrokey-comm-4" ] }, { "productId": "nitrokey", "storyId": "cli-key-management", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Nitrokey ships an official CLI, nitropy, documented at docs.nitrokey.com/software/nitropy and verified installable/runnable via PyPI, described as a tool to interact with Nitrokey devices (identity/version checks, firmware updates, etc.), plus a companion Python SDK — this covers scriptable device configuration and management. Missing for 10: explicit documentation/examples in the evidence pack of specific subcommands for PIN-setting, slot management, and app enable/disable, and independent hands-on confirmation of full feature parity across all device operations.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1", "nitrokey-docs-13" ] }, { "productId": "nitrokey", "storyId": "connector-lineup", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence indirectly shows both USB-A and USB-C variants exist (the shop page references 'nk3an-nitrokey-3a-nfc' and a community comment mentions ordering a 'Nitrokey 3C NFC'), suggesting the lineup covers both port types. However, there is no evidence of keychain or nano low-profile form factors anywhere in the pack, and one community comment even complains about waiting years for a Type-C model, casting some doubt on breadth/availability. Missing for 10: explicit nano/keychain form-factor SKUs, confirmed current availability of USB-C models, first-party spec sheet comparing form factors.", "evidenceIds": [ "nitrokey-docs-4", "nitrokey-comm-4", "nitrokey-comm-6" ] }, { "productId": "nitrokey", "storyId": "credential-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "While Nitrokey ships FIDO2 support and an official nitropy CLI, the evidence pack contains no documentation or mention of commands/features to list resident passkeys, delete individual credentials, or view credential storage capacity/limits. This is a fair capability to expect from a FIDO2 authenticator, but no evidence confirms it.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "cross-platform-compat", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Docs scatter claims of broad compatibility (SSH, FIDO2, OTP, PIV, OpenPGP, Windows/AD, Office 365, Nextcloud, Thunderbird, OpenVPN) but there is no single published compatibility catalog/matrix of supported services or browsers. Community evidence concretely contradicts smooth cross-platform delivery: users report needing to allow unsigned driver installation on Windows, and multiple reports that Nitrokey 3 still lists many features as 'planned' and lags Yubikey in feature parity years after purchase. missing for 10: a unified compatibility matrix/catalog page, confirmation of parity across all claimed services, resolution of the Windows driver-signing friction.", "evidenceIds": [ "nitrokey-docs-2", "nitrokey-docs-4", "nitrokey-docs-5", "nitrokey-comm-5", "nitrokey-comm-6", "nitrokey-comm-7" ] }, { "productId": "nitrokey", "storyId": "enterprise-delivery-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers device features (FIDO2, OpenPGP, PIV), firmware/CLI tooling, and community feedback on hardware/support quality, but nothing addresses enterprise bulk-shipping/fleet logistics, an API/console for distributing keys directly to distributed employees, or any provisioning-and-delivery service comparable to fleet-management logistics.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "fido2-resident-passkeys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm FIDO2 support and explicitly market 'passwordless login' to Microsoft/Nextcloud (nitrokey-docs-4), which implies discoverable/resident-key credentials, and FIDO2 is listed as a core feature (nitrokey-docs-1, nitrokey-docs-16). However, no documentation explicitly names 'resident keys' or 'discoverable credentials,' and community reports note the Nitrokey 3 has lagged on FIDO2 feature parity with competitors (many features listed as 'planned'), raising doubt about completeness. Missing for 10: explicit resident-key/discoverable-credential documentation, independent hands-on verification of usernameless sign-in working end-to-end.", "evidenceIds": [ "nitrokey-docs-1", "nitrokey-docs-4", "nitrokey-docs-16", "nitrokey-comm-6", "nitrokey-comm-7" ] }, { "productId": "nitrokey", "storyId": "firmware-update-policy", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Nitrokey documents a firmware-update mechanism (dedicated firmware-update guide, nitropy CLI, tagged GitHub releases like v1.8.3) and open-source firmware for transparency, but there is no evidence of a formal security-advisory feed, CVE list, or affected-model lookup tool comparable to a vendor security bulletin process; a community post references a real key-extraction issue discussed ad hoc rather than via a documented advisory pipeline. Missing for 10: dedicated security advisories page, CVE/vulnerability database, affected-model/version lookup tool, and clear SLA for how fixes reach devices beyond generic update docs.", "evidenceIds": [ "nitrokey-docs-13", "nitrokey-docs-14", "nitrokey-probe-rt-1", "nitrokey-probe-rt-2", "nitrokey-comm-8", "nitrokey-gh-1" ] }, { "productId": "nitrokey", "storyId": "guided-enrollment", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Nitrokey provides scattered feature-specific docs (SSH, PIV, OpenPGP, FIDO2, general instructions) and a CLI tool (nitropy) for device management, which can guide account registration for specific services, but there's no single unified setup wizard/app walking a user end-to-end through registering with major accounts. Community feedback also flags real setup friction (e.g., needing to allow unsigned driver installation) that undercuts a smooth guided experience. Missing for 10: a dedicated onboarding app/wizard, first-party account-registration walkthroughs (e.g., for Google/Microsoft/GitHub), and independent hands-on confirmation that setup is smooth.", "evidenceIds": [ "nitrokey-docs-9", "nitrokey-docs-10", "nitrokey-docs-14", "nitrokey-probe-rt-1", "nitrokey-comm-5" ] }, { "productId": "nitrokey", "storyId": "hardware-approval-for-agents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Nitrokey documents generic touch-confirmation for OpenPGP/FIDO2 operations, but there is no evidence tying this to AI-agent or automated-action approval workflows, MCP, or any agentic tooling — the capability as described in the story is unevidenced.", "evidenceIds": [ "nitrokey-docs-6", "nitrokey-docs-1", "nitrokey-docs-9" ] }, { "productId": "nitrokey", "storyId": "hardware-backed-ssh", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm SSH login via certificates, PIV support, and OpenPGP card with touch confirmation, and a dedicated 'SSH Keys' page under the FIDO2 section suggests sk-ssh key support, aligning with the hardware-backed SSH story. However, there's no explicit walkthrough of FIDO2 sk-ssh key generation/usage, and community threads note the Nitrokey 3 has lagged in reaching feature parity with competitors, raising some doubt about full FIDO2 SSH robustness. Missing for 10: explicit sk-ssh setup documentation/examples, independent hands-on confirmation of FIDO2 SSH touch-to-authenticate working end-to-end.", "evidenceIds": [ "nitrokey-docs-1", "nitrokey-docs-3", "nitrokey-docs-6", "nitrokey-docs-11", "nitrokey-comm-6" ] }, { "productId": "nitrokey", "storyId": "idp-policy-integration", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Nitrokey documents FIDO2/PIV/OpenPGP protocol support and a specific 'Nitrokey Provisioning for Entra ID' tool, showing some IdP integration, but there is no evidence of Okta or Google Workspace integration, nor any admin console/policy engine to enforce hardware-key-only authentication fleet-wide. Missing for 10: Okta integration, Google Workspace integration, centralized policy enforcement/fleet management console, documentation of admin-side enrollment/compliance workflows.", "evidenceIds": [ "nitrokey-docs-18", "nitrokey-docs-5", "nitrokey-docs-11" ] }, { "productId": "nitrokey", "storyId": "nfc-mobile-tap", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Nitrokey sells an NFC-enabled model (Nitrokey 3A NFC) and documents FIDO2/U2F/OTP login flows and an Android/NitroPhone integration, implying NFC tap-to-auth is technically supported, but no evidence explicitly confirms tapping the key against a phone to authenticate in mobile browsers/apps, nor any hands-on report of this working. Missing for 10: explicit documentation or user testimony of NFC-based authentication on phones, coverage across major mobile browsers/apps, and confirmation it works as smoothly as competitors.", "evidenceIds": [ "nitrokey-docs-4", "nitrokey-docs-16", "nitrokey-docs-19", "nitrokey-docs-9" ] }, { "productId": "nitrokey", "storyId": "official-sdks", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Nitrokey provides nitropy CLI and a Python 'nitrokey' SDK on PyPI plus PIV/OpenPGP/PKCS#11 support that developers can integrate into tooling, but there is no evidence of official mobile SDKs (iOS/Android app libraries) or desktop app integration SDKs beyond the low-level Python/CLI tooling. missing for 10: dedicated mobile (iOS/Android) SDKs, higher-level desktop app integration libraries (e.g. for Electron/Swift/Java), first-party sample apps or API docs showing SDK usage in third-party apps.", "evidenceIds": [ "nitrokey-probe-rt-1", "nitrokey-docs-14", "nitrokey-docs-19" ] }, { "productId": "nitrokey", "storyId": "open-source-firmware", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Nitrokey 3 firmware is confirmed open source (Rust, dual Apache2.0/MIT licensed, tagged releases on GitHub) which lets engineers inspect what runs on the device, but the HSM applet is explicitly noted as not open source, and there is no evidence of an independent third-party security audit of the firmware. missing for 10: independent audit report, confirmation that all product lines (not just Nitrokey 3) are open source, no audit mention for the closed HSM applet.", "evidenceIds": [ "nitrokey-gh-1", "nitrokey-gh-2", "nitrokey-gh-3", "nitrokey-probe-rt-2", "nitrokey-comm-1" ] }, { "productId": "nitrokey", "storyId": "openness-api-parity", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Nitrokey ships an official CLI (nitropy) and Python SDK that can configure/manage devices programmatically, confirmed to install and run via PyPI, but there is no formal REST/OpenAPI interface (all API endpoint probes 404) and no explicit vendor claim of full UI/CLI feature parity for AI-native automation. Missing for 10: documented API/OpenAPI spec, explicit parity statement between GUI app and nitropy CLI, and independent verification that all UI-exposed features are scriptable via nitropy.", "evidenceIds": [ "nitrokey-docs-14", "nitrokey-probe-4", "nitrokey-probe-rt-1", "nitrokey-probe-3" ] }, { "productId": "nitrokey", "storyId": "openness-full-export", "verdict": "disputed", "quality": 3, "confidence": "low", "rationale": "Nitrokey's firmware and licensing are open source (nitrokey-gh-1, nitrokey-gh-3) and it uses open standards like FIDO2/OpenPGP/PIV, which in principle avoid lock-in, but a hands-on user report describes the opposite of clean data portability: Nitrokey attestation certs 'can't be exported via PKCS#11' and require a 'custom vendor shell' with a non-standard ASN.1 cert container (nitrokey-comm-2) — directly contradicting an open, portable data-export claim. Missing for 10: any first-party documentation of a bulk/data export feature or standard export format for stored secrets, and no counter-evidence resolving the community-reported non-standard export path.", "evidenceIds": [ "nitrokey-gh-1", "nitrokey-gh-3", "nitrokey-comm-2" ] }, { "productId": "nitrokey", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Nitrokey 3 firmware source is hosted on GitHub, explicitly stated to be fully open source, dual-licensed under Apache 2.0/MIT, with tagged releases confirming active open development. This directly satisfies reading source under an open license for the core firmware. Missing for 10: confirmation that all components (e.g., HSM applet, some proprietary parts noted in community evidence) are open, and no independent audit of license completeness beyond firmware repo.", "evidenceIds": [ "nitrokey-gh-1", "nitrokey-gh-2", "nitrokey-gh-3", "nitrokey-probe-rt-2" ] }, { "productId": "nitrokey", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "openpgp-onkey", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Nitrokey devices support the OpenPGP smart card standard with on-device key generation, touch confirmation, and documented integration with Thunderbird for encrypted email; the OpenPGP card standard is also the basis for git commit signing via GPG, which is a well-known standard use case for OpenPGP smart cards. Docs explicitly cover keygen-on-device, touch confirmation, and Thunderbird email use. Missing for 10: explicit first-party documentation naming 'git commit signing' as a use case, and independent hands-on corroboration of the OpenPGP-card signing workflow.", "evidenceIds": [ "nitrokey-docs-5", "nitrokey-docs-6", "nitrokey-docs-7", "nitrokey-docs-17", "nitrokey-docs-16" ] }, { "productId": "nitrokey", "storyId": "otp-legacy-slots", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs explicitly list 'Two Factor Authentication' and OTP support (login using OTP for Google/Facebook), and the Nitrokey 3 product page mentions 'one-time passwords' among combined features, indicating TOTP/HOTP slot support. However, no explicit mention of HOTP challenge-response mode, no detail on number of slots, no independent hands-on verification of OTP functionality, and community evidence focuses on other features (HSM, durability) without confirming OTP reliability. Missing for 10: explicit challenge-response documentation, slot-count/configuration details, independent hands-on confirmation of OTP/HOTP working as advertised.", "evidenceIds": [ "nitrokey-docs-2", "nitrokey-docs-9", "nitrokey-docs-16" ] }, { "productId": "nitrokey", "storyId": "pin-biometric-verification", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence confirms Nitrokey devices support FIDO2 and mentions 'Touch Confirmation' (a presence check), but nowhere does it document a FIDO2 PIN or biometric on-device user-verification mechanism that would block use by a mere possessor of a stolen key. Missing for 10: explicit documentation of FIDO2 PIN setup/enforcement, biometric sensor support, or any UV (user verification) flag being satisfied — only touch/presence confirmation is evidenced, which is a different, weaker security property.", "evidenceIds": [ "nitrokey-docs-1", "nitrokey-docs-6", "nitrokey-docs-16" ] }, { "productId": "nitrokey", "storyId": "piv-smartcard-login", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Nitrokey documents PIV support explicitly (nitrokey-docs-11) plus Windows Login/AD, S/MIME, PAM (Linux), OpenVPN and on-device keygen with touch confirmation (nitrokey-docs-5,6,7,8,15), covering workstation login, VPN and code-signing-adjacent use cases with non-exportable keys. However, code-signing evidence is limited to CLI/attestation tooling rather than a dedicated PIV code-signing workflow, and community reports flag missing feature parity and cryptographic limitations (Ed25519 unsupported, non-standard attestation cert formats) versus competitors, plus slow/incomplete rollout of promised features. Missing for 10: dedicated PIV-specific code-signing documentation/integration guide, independent hands-on verification of PIV smart-card login working end-to-end, and confirmation that PIV certs are exportable/usable in enterprise CA workflows.", "evidenceIds": [ "nitrokey-docs-11", "nitrokey-docs-5", "nitrokey-docs-7", "nitrokey-docs-8", "nitrokey-docs-15", "nitrokey-comm-2", "nitrokey-comm-7" ] }, { "productId": "nitrokey", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a physical hardware security key that stores secrets locally on-device; there is no cloud/regional data-residency concept applicable to this product category.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Nitrokey is a hardware security key/HSM product for authentication, encryption, and credential storage; it has no relation to AI model training data usage or opting out of AI training, which is an entirely different product category axis.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers Nitrokey's hardware features (FIDO2, OpenPGP, PIV), its open-source firmware/CLI (nitropy), and community commentary on durability/support, but contains no mention of any telemetry, usage tracking, or opt-out settings for its software (nitropy CLI, firmware update service) or hardware. Since Nitrokey ships software tools that could in principle collect usage data, the axis applies, but there is no evidence either confirming or denying telemetry practices.", "evidenceIds": [] }, { "productId": "nitrokey", "storyId": "webauthn-second-factor", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm FIDO2/U2F support and explicitly name Google/Facebook U2F login and Microsoft passwordless login, and general 'Two Factor Authentication' docs exist, but GitHub and password-manager compatibility are never explicitly evidenced. Community reports also note the Nitrokey 3 lagging in feature parity vs. competitors and having 'planned' rather than shipped features, raising some doubt about full protocol coverage. Missing for 10: explicit GitHub WebAuthn/U2F confirmation, password-manager (e.g. Bitwarden/1Password) compatibility evidence, and independent hands-on confirmation across these specific services.", "evidenceIds": [ "nitrokey-docs-1", "nitrokey-docs-2", "nitrokey-docs-4", "nitrokey-docs-9", "nitrokey-docs-16", "nitrokey-comm-6", "nitrokey-comm-7" ] }, { "productId": "solokeys", "storyId": "agent-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "There is no evidence of any enterprise/fleet management API for ordering, assignment, or pre-registration of keys — the CLI is a local hardware management tool (list, flash, LED), and probe evidence shows no OpenAPI/API docs exist and the CLI itself is bit-rotted. This is a consumer/hacker hardware key product with no enterprise provisioning system at all.", "evidenceIds": [ "solokeys-probe-3", "solokeys-probe-rt-1", "solokeys-gh-4" ] }, { "productId": "solokeys", "storyId": "agent-key-audit", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The Solo 2 CLI exposes some device-state commands (`solo2 list` for connected devices/serials, `solo2 app admin ...` for config) suggesting basic programmatic querying, but there is no evidence of commands to enumerate firmware version, enabled applications, or stored credentials for fleet auditing. A runtime probe also shows the official Python CLI tooling (solo-python) is broken due to dependency incompatibility, undermining reliability of programmatic access. missing for 10: documented API/CLI output for firmware version and enabled-app enumeration, credential enumeration, a working/maintained CLI tool, any structured/machine-readable output format for fleet-scale auditing.", "evidenceIds": [ "solokeys-gh-4", "solokeys-gh-3", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Explicit probes confirm docs.solokeys.dev has no llms.txt (404) and no openapi/markdown-alternative endpoints; the only llms.txt found is a generic Shopify shopping-agent file unrelated to technical/product documentation, so there is no agent-oriented documentation to point an AI agent at.", "evidenceIds": [ "solokeys-probe-1", "solokeys-probe-2", "solokeys-probe-3", "solokeys-probe-rt-2" ] }, { "productId": "solokeys", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key for authentication (passkeys/FIDO2/OATH/PIV/OpenPGP); it does not process or store user data in a way that would support AI-generated insights or suggestions. This axis is a category error for an authentication hardware token.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key for authentication (passkeys/FIDO2/OTP); it has no automation/workflow-orchestration capability and the concept of 'background autonomous automations' does not apply to a physical security token requiring touch confirmation.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key for FIDO2/WebAuthn authentication, not an AI assistant or agentic platform; delegating tasks to a built-in AI assistant is a category error for this product type.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-headless", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a physical security key requiring human touch confirmation for every action, and while a CLI exists (solo2 list, admin commands), there's no documented support for headless/CI automation; a runtime probe shows the official CLI is bit-rotted (ImportError, incompatible fido2 dependency) with no firmware release in 4 years, further undermining any automation use case.", "evidenceIds": [ "solokeys-docs-1", "solokeys-gh-4", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a hardware security key (FIDO2/WebAuthn/PIV/OpenPGP authenticator), not an AI agent or platform with tool-use capability; MCP server integration is not a fair axis for this product category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key (FIDO2/WebAuthn/OATH/PIV/OpenPGP authenticator); it has no product role as an agent tool server and no evidence of an MCP server offering. Connecting AI agents via MCP is outside this product's category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a hardware security key/authenticator; operating it is inherently physical (touch sensor, insert USB, tap NFC) or via CLI commands, not natural-language interaction. This is a category error—natural-language operation is not a fair axis for a hardware auth token.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-official-cli", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "GitHub docs show an official `solo2` CLI with scriptable commands (list, admin set led, monitor, wipe) suitable for automation, but a runtime probe found the official Solo CLI (solo-python) actually fails to run due to a dependency ImportError, and no Solo 2 firmware release has shipped in 4 years despite ongoing CI commits — concretely contradicting the claim of a working, maintained official CLI. Missing for 10: evidence of AI-agent-specific CLI usage/documentation, confirmation the solo2 (Rust) CLI itself runs cleanly, and independent corroboration beyond the vendor's own repo.", "evidenceIds": [ "solokeys-gh-3", "solokeys-gh-4", "solokeys-docs-7", "solokeys-docs-10", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "agentic-public-api", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Solo 2 exposes a hardware CLI (solo2 app/list) and standard protocols like FIDO2/PIV/OpenPGP, but there is no documented public REST/programmatic API for AI-driven control, and probes confirm no OpenAPI spec or llms.txt exists (404s) while the closest thing to an SDK (solo-python CLI) is reported bit-rotted and broken via ImportError. No evidence of a working, documented API surface an AI agent could drive.", "evidenceIds": [ "solokeys-probe-3", "solokeys-probe-1", "solokeys-probe-rt-1", "solokeys-probe-rt-2" ] }, { "productId": "solokeys", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key (FIDO2/WebAuthn/PIV/OpenPGP authenticator); it has no concept of API credentials or agent-scoped access tokens, which is entirely outside its product category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows firmware-build tooling (Rust/cargo builds, solo2 CLI, customization docs) rather than an official SDK for third-party/AI-native application development, and the one CLI tool cited is reported bit-rotted and broken in 2026 (ImportError, no releases in 4 years). No client library, API reference, or SDK package is documented for developers to build against.", "evidenceIds": [ "solokeys-docs-6", "solokeys-docs-8", "solokeys-gh-9", "solokeys-probe-rt-1", "solokeys-probe-3" ] }, { "productId": "solokeys", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a hardware security key (USB/NFC FIDO2 device); webhooks/event subscriptions are not a fair capability for this product category, which has no server-side or event-driven architecture.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "api-interactive-docs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key with a CLI/firmware toolchain, not an API/SaaS product; there is no API surface for which an interactive reference with runnable examples would be a meaningful offering. The probes confirm no OpenAPI/API docs exist, but this reflects the product category, not a missing capability.", "evidenceIds": [ "solokeys-probe-3", "solokeys-gh-4" ] }, { "productId": "solokeys", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "SoloKeys is a hardware security key with a CLI and firmware documentation, not an API/web service; a machine-readable OpenAPI spec would be a fair thing to ask for if it exposed a network API, but probes explicitly show no OpenAPI/swagger spec exists at any candidate path and no llms.txt for the technical docs.", "evidenceIds": [ "solokeys-probe-3", "solokeys-probe-1", "solokeys-probe-rt-2" ] }, { "productId": "solokeys", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a physical hardware security key; the concept of a 'sandbox environment vs production data' for AI-native testing does not apply to this product category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "api-versioning-policy", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key that implements standard protocols (FIDO2/WebAuthn, OATH, PIV, OpenPGP); it is not an API-driven service or SDK for which a versioned API deprecation policy would be a meaningful axis. This story is a category error for this product type.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "attestation-enforcement", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The docs confirm Solo 2 ships with a factory attestation key and even allow customizing/generating your own attestation key pair for bulk deployment, implying WebAuthn/FIDO2 attestation is present in principle. However there is no documentation of a FIDO Alliance MDS listing, stable AAGUID, or any RP-side verification workflow that a security engineer could use to confirm the device model at registration — and the ability to swap the attestation key yourself could actually undermine trust in a fixed identity. missing for 10: MDS/AAGUID metadata for RP verification, documented attestation-cert chain details, guidance for enterprises on enforcing genuine-model checks, independent confirmation that registration-time attestation works as expected.", "evidenceIds": [ "solokeys-docs-5", "solokeys-docs-14", "solokeys-gh-1" ] }, { "productId": "solokeys", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a hardware security key (FIDO2/passkey/OATH/PIV authenticator); it has no rules/automation engine or event-trigger system, and this axis is a category error for an authentication hardware token.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key for authentication; scheduling recurring jobs/workflows is not a capability that applies to this product category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "SoloKeys Solo 2 is a hardware security key/authenticator; 'automations' with version/review/rollback is not a concept applicable to this product category.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "backup-key-strategy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence in the pack discusses backup key enrollment, multi-key registration strategies, or what is/isn't recoverable if a Solo 2 is lost — documentation covers setup, building, and CLI usage but never addresses lockout/recovery planning.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "bulk-fleet-provisioning", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence covers individual key setup, CLI device listing/config (`solo2 list`, `admin set led`), and custom attestation-key generation, with one offhand mention of building attestation keys 'for maybe 100,000 devices'—but there is no documented bulk-enrollment workflow, admin console, pre-registration pipeline, or lifecycle/issuance tracking system for organizations. Runtime probes further show the official CLI is broken (ImportError) and no firmware has shipped in 4 years, undercutting any claim of active enterprise tooling.", "evidenceIds": [ "solokeys-docs-14", "solokeys-gh-4", "solokeys-gh-3", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "certified-hardened-models", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of FIPS 140 validation or Common Criteria certification anywhere in the pack; only a community comment mentions 'water resistant' informally (solokeys-comm-7), and another comment casts doubt on tamper-resistance claims (solokeys-comm-1). No documented crush resistance or regulated-environment certification exists.", "evidenceIds": [ "solokeys-comm-7", "solokeys-comm-1" ] }, { "productId": "solokeys", "storyId": "cli-key-management", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "Docs and GitHub show a `solo2` CLI with some admin commands (`solo2 list`, `solo2 app admin set led`, firmware `update`) but no documented commands for setting PINs or managing slots, and reading device state relies on generic third-party `fido2-token` rather than a Solo-specific command. A runtime probe found the official Solo CLI (solo-python) actually fails to even run (`ImportError: cannot import name CTAP1`) due to incompatibility with current fido2 2.x, and firmware hasn't been released in 4 years — concrete evidence the tooling has bit-rotted rather than delivering the claimed scriptable management. missing for 10: working PIN-setting command, slot management, device-state reporting, and a CLI that runs without import errors on current dependencies.", "evidenceIds": [ "solokeys-gh-3", "solokeys-gh-4", "solokeys-docs-10", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "connector-lineup", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows Solo 2 exists as a security key with NFC variant and generic USB port compatibility, and community comments mention a 'reversible USB-A'/'reversible usb plug', but there is no evidence of a broader lineup with distinct USB-C vs USB-A SKUs or keychain vs low-profile nano form factors — only a single case/color accessory line is mentioned.", "evidenceIds": [ "solokeys-docs-3", "solokeys-docs-4", "solokeys-comm-5", "solokeys-comm-7", "solokeys-docs-15" ] }, { "productId": "solokeys", "storyId": "credential-management", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence describes per-passkey listing, deletion, or credential-capacity reporting; the only related CLI ops shown are `solo2 list` (lists connected devices, not credentials) and `fido2-token -R` (wipes the entire key, not selective deletion). Additionally, a runtime probe shows the official CLI is now broken (ImportError against modern fido2 libs), further undermining any credential-management workflow.", "evidenceIds": [ "solokeys-gh-4", "solokeys-docs-10", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "cross-platform-compat", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "Solo 2 claims broad compatibility (any USB port, no drivers, FIDO2/passkey standard, NFC for Android/iOS, OATH/PIV/OpenPGP) but there is no published compatibility catalog listing specific supported services/sites, and a runtime probe shows the official CLI tooling has bit-rotted and firmware hasn't been updated in years, raising doubts about maintained cross-platform support. Missing for 10: a published service/site compatibility list, browser-specific compatibility documentation, and evidence the tooling/firmware is actively maintained to keep pace with OS/browser changes.", "evidenceIds": [ "solokeys-docs-2", "solokeys-docs-3", "solokeys-docs-4", "solokeys-gh-1", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "enterprise-delivery-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of any enterprise provisioning/shipping API, console, or fleet-deployment logistics integration; SoloKeys is a consumer hardware key sold via a Shopify store with no fleet-management tooling documented, and CLI/API evidence is limited to device-local admin commands and firmware building. Probes even show bit-rot in the CLI and no API/OpenAPI documentation exists.", "evidenceIds": [ "solokeys-probe-3", "solokeys-probe-rt-1", "solokeys-docs-15", "solokeys-gh-4" ] }, { "productId": "solokeys", "storyId": "fido2-resident-passkeys", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Solo 2 is marketed explicitly as a passkey/WebAuthn security key that stores credentials on-device rather than in a cloud, and general FIDO2 passkey support inherently implies discoverable/resident credentials for usernameless sign-in ([solokeys-docs-2], [solokeys-docs-9], [solokeys-gh-1]). Missing for 10: explicit documentation of resident-key storage limits/technical FIDO2 conformance details, and independent hands-on confirmation of a usernameless login flow (only marketing copy corroborates this).", "evidenceIds": [ "solokeys-docs-2", "solokeys-docs-9", "solokeys-gh-1" ] }, { "productId": "solokeys", "storyId": "firmware-update-policy", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "The GitHub docs describe a signed, SHA-256-verified update mechanism (solokeys-gh-2), but there is no evidence of published security advisories or an affected-model lookup, and a runtime probe shows the official CLI is bit-rotted (ImportError against current fido2 lib) and no firmware release has shipped in ~4 years despite ongoing dependency commits — directly undercutting the claim that fixes reliably reach devices. missing for 10: security advisory feed/CVE list, affected-model/version lookup tool, evidence of recent firmware releases actually reaching users, working update tooling.", "evidenceIds": [ "solokeys-gh-2", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "guided-enrollment", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs mention simple plug-and-play basics ('insert into USB port, no software required', 'touch sensor to confirm') but there is no evidence of a dedicated setup app or step-by-step account-registration walkthrough; the FIDO2 side of onboarding is essentially per-website. Additionally, a runtime probe shows the official companion CLI is bit-rotted (import errors) and firmware hasn't been updated in years, undermining confidence in any first-time-setup tooling. Missing for 10: a documented onboarding wizard/app, account-registration walkthrough for accounts, working companion CLI/tooling.", "evidenceIds": [ "solokeys-docs-1", "solokeys-docs-3", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "hardware-approval-for-agents", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Solo 2 documents a generic touch-to-confirm step for WebAuthn/FIDO2 authentication (solokeys-docs-1), which could theoretically gate any human-in-the-loop confirmation, but there is no evidence tying this to AI-agent-initiated action approval flows, agentic tool integrations, or any AI-native ecosystem support. Additionally, runtime evidence shows the official CLI is broken/bit-rotted and firmware hasn't shipped in 4 years, raising doubts about active ecosystem maintenance. Missing for 10: any documentation or integration example of using Solo 2 touch confirmation as an approval gate for AI/agent workflows, evidence of SDK/API hooks for agent tooling, and independent confirmation of this use case.", "evidenceIds": [ "solokeys-docs-1", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "hardware-backed-ssh", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "GitHub docs assert the device 'speaks OATH (TOTP/HOTP), PIV, and OpenPGP' alongside its core FIDO2/WebAuthn support, which would in principle back sk-ssh (FIDO2), PIV, and GPG-based SSH keys — but a community commenter on the same Solo2 announcement explicitly states 'it doesn't do OpenPGP,' and an independent runtime probe shows the official solo-python CLI is broken (ImportError with current python-fido2) and firmware hasn't shipped since 2022, casting doubt that these advertised protocols are actually usable today for SSH auth. Missing for 10: explicit sk-ssh/PIV/OpenPGP SSH-key setup documentation, working current CLI/firmware evidence, and resolution of the OpenPGP support contradiction.", "evidenceIds": [ "solokeys-gh-1", "solokeys-gh-8", "solokeys-comm-2", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "idp-policy-integration", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack mentions IdP integrations (Okta, Entra ID, Google Workspace), fleet enrollment/management tools, or policy enforcement for hardware-key authentication; evidence only covers WebAuthn/FIDO2 protocol support, firmware building, and hardware details. This is a plausible axis for a security key vendor (many competitors offer admin/fleet consoles), but SoloKeys shows nothing to support it.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "nfc-mobile-tap", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "SoloKeys explicitly markets NFC tap-to-authenticate for compatible Android and iOS devices as a feature of Solo 2, supporting WebAuthn/passkeys which work across mobile browsers/apps. Missing for 10: no independent hands-on confirmation of NFC mobile browser/app compatibility, and community discussion focuses on other aspects (tamper resistance, OpenPGP) rather than validating NFC mobile use.", "evidenceIds": [ "solokeys-docs-4", "solokeys-docs-2", "solokeys-gh-1" ] }, { "productId": "solokeys", "storyId": "official-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only a device-management CLI (solo2 app admin/list) and firmware-building/customization tooling for the key itself, not any SDK for embedding the key into third-party desktop or mobile applications. The runtime probe even shows the existing Solo Python CLI is broken/bit-rotted, and no library/SDK for app integration is documented anywhere in the pack.", "evidenceIds": [ "solokeys-gh-3", "solokeys-gh-4", "solokeys-docs-6", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "open-source-firmware", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "The Solo 2 firmware is openly published on GitHub, buildable from source, and the 'Hacker' variant explicitly supports flashing custom firmware, letting anyone inspect and verify what runs on the device; this is corroborated by community commentary confirming 'it's open source firmware, not open source hardware.' Updates are also SHA-256 verified before flashing, adding transparency to the update process.\n\nmissing for 10: no formal independent third-party security audit is cited, and runtime evidence shows the firmware/tooling has not been updated since 2022, raising questions about ongoing maintenance of the open codebase.", "evidenceIds": [ "solokeys-gh-5", "solokeys-gh-9", "solokeys-gh-2", "solokeys-comm-6", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "openness-api-parity", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Solo 2 supports open standards (WebAuthn, OATH, PIV, OpenPGP) and lets users customize/replace the attestation key or wipe the device, but there is no documentation of any way to export stored credentials/private key material in open formats to migrate elsewhere — by design, FIDO2/PIV/OpenPGP keys generated on-device are non-extractable. missing for 10: any documented data-export/migration path, evidence of extractable key material, or open-format backup/portability tooling.", "evidenceIds": [ "solokeys-docs-10", "solokeys-gh-1", "solokeys-docs-5", "solokeys-docs-14" ] }, { "productId": "solokeys", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The firmware source is hosted openly on GitHub (solokeys/solo2), with build instructions, hackable firmware flashing, and even a dedicated 'Hacker' key edition explicitly for reading/modifying source and firmware end-to-end. Community confirms firmware is open source (though hardware/chip is not), corroborating the licensing model. Missing for 10: no explicit license file/name cited, and no independent audit of license terms beyond community mention that firmware (not hardware) is open.", "evidenceIds": [ "solokeys-gh-5", "solokeys-gh-9", "solokeys-gh-1", "solokeys-docs-6", "solokeys-comm-6" ] }, { "productId": "solokeys", "storyId": "openness-self-host", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "The Solo 2 'Hacker' edition ships with fully open-source firmware that users can build, flash, and customize themselves (own attestation keys, own firmware, full toolchain via Rust/cargo), which is the closest analogue to 'self-hosting' for a hardware security key — no cloud dependency by design. However, runtime evidence shows the surrounding tooling has bit-rotted (solo-python CLI fails on current fido2 libs) and no firmware release has shipped in 4 years, undermining confidence that self-building/self-hosting the core product is currently practical. Missing for 10: a working, up-to-date official build/flash pipeline, and independent confirmation that a user can successfully self-build current firmware today.", "evidenceIds": [ "solokeys-gh-5", "solokeys-gh-9", "solokeys-docs-5", "solokeys-docs-6", "solokeys-docs-8", "solokeys-docs-11", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "openpgp-onkey", "verdict": "disputed", "quality": 3, "confidence": "medium", "rationale": "The GitHub README lists OpenPGP as a supported protocol (solokeys-gh-1, solokeys-gh-8), which would enable git commit signing and encrypted email use cases, but community comments directly contradict this — users report 'it doesn't do OpenPGP' and 'I'm really hoping they bring GPG to the Solokey... but I'm starting to lose confidence' (solokeys-comm-2, solokeys-comm-4). There is no first-party documentation walking through GPG key generation, git signing setup, or email encryption workflows, and no independent hands-on confirmation that OpenPGP actually works on shipped hardware. Missing for 10: verified working OpenPGP applet on shipped Solo 2 units, official docs for GPG/git-signing setup, and independent confirmation resolving the community's contradicting reports.", "evidenceIds": [ "solokeys-gh-1", "solokeys-gh-8", "solokeys-comm-2", "solokeys-comm-4" ] }, { "productId": "solokeys", "storyId": "otp-legacy-slots", "verdict": "full", "quality": 6, "confidence": "medium", "rationale": "GitHub docs explicitly state Solo 2 speaks OATH (TOTP/HOTP) in addition to FIDO2/WebAuthn, PIV, and OpenPGP, directly supporting legacy OTP slot functionality. However, missing for 10: no CLI/setup walkthrough for configuring TOTP/HOTP slots, no independent hands-on confirmation the OATH applet works reliably, and a runtime probe shows the official Solo CLI has bit-rotted (import errors) and firmware hasn't been updated in years, raising doubts about current usability.", "evidenceIds": [ "solokeys-gh-1", "solokeys-gh-8", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "pin-biometric-verification", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows a capacitive touch sensor for user presence confirmation (solokeys-docs-1), which is a presence test, not FIDO2 user verification via PIN or biometric. No documentation or community evidence mentions a settable FIDO2 PIN or biometric sensor on Solo 2, so the specific 'stolen key alone cannot authenticate' verification story is unevidenced.", "evidenceIds": [ "solokeys-docs-1", "solokeys-gh-1", "solokeys-docs-4" ] }, { "productId": "solokeys", "storyId": "piv-smartcard-login", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "GitHub docs confirm Solo 2 'speaks... PIV' alongside FIDO2/OATH/OpenPGP, supporting the core claim that certificate-based smart-card auth is possible, but there is no vendor documentation on PIV provisioning, workstation/VPN sign-in setup, or code-signing workflows, and a runtime probe shows the official CLI is bit-rotted and firmware hasn't shipped a release in 4 years, raising doubt about current enterprise usability. Missing for 10: PIV certificate enrollment/management docs, workstation/VPN sign-in integration guides, code-signing workflow evidence, and confirmation the PIV applet still functions with current tooling.", "evidenceIds": [ "solokeys-gh-1", "solokeys-gh-8", "solokeys-probe-rt-1" ] }, { "productId": "solokeys", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a local hardware security key whose keys never leave the device ('stays on your key, not their cloud') — there is no cloud data storage or region selection concept applicable to this product category.", "evidenceIds": [ "solokeys-docs-2" ] }, { "productId": "solokeys", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Solo 2 is a hardware security key (FIDO2/passkey/OATH/PIV/OpenPGP authenticator); it has no relationship to AI model training data or consent controls over such use. This story is a category error for this product type.", "evidenceIds": [] }, { "productId": "solokeys", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence shows credentials are stored only on-device rather than in a vendor cloud (solokeys-docs-2), and a device wipe is possible via the third-party `fido2-token -R` command (solokeys-docs-10), giving users some control over deletion. However, this is not a first-party, documented retention/deletion feature — it's a generic FIDO2 tool tip buried in a GitHub releases page, with no official SoloKeys documentation on data retention policy or granular per-credential deletion. Missing for 10: native SoloKeys CLI/tool for credential management and wipe, official retention policy documentation, and independent confirmation the wipe command works reliably.", "evidenceIds": [ "solokeys-docs-2", "solokeys-docs-10" ] }, { "productId": "solokeys", "storyId": "privacy-telemetry-optout", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Solo 2 is explicitly marketed as working entirely locally ('stays on your key, not their cloud', no software/drivers required), which implies no cloud usage-tracking to opt out of, but there is no explicit telemetry policy, settings, or opt-out control documented for the CLI/companion tooling. missing for 10: explicit telemetry/privacy policy statement, any opt-out toggle or setting, confirmation that the solo2 CLI/companion app sends no usage analytics.", "evidenceIds": [ "solokeys-docs-2", "solokeys-docs-9", "solokeys-docs-3" ] }, { "productId": "solokeys", "storyId": "webauthn-second-factor", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Solo 2 is a standard WebAuthn/FIDO2/U2F device that would work with any relying party supporting those standards (Google, GitHub, Microsoft, many password managers), and vendor docs confirm FIDO2/passkey and U2F-style support plus broad protocol coverage (OATH, PIV, OpenPGP). However there is no explicit first-party or independent testing evidence confirming compatibility with each named service, and a runtime probe shows the companion CLI tooling has bit-rotted with no firmware update in 4 years, raising doubts about ongoing maintenance/compatibility. Missing for 10: explicit per-service (Google/GitHub/Microsoft/password manager) compatibility confirmation, independent hands-on verification across these services, and evidence of active firmware maintenance to keep pace with protocol changes.", "evidenceIds": [ "solokeys-docs-2", "solokeys-gh-1", "solokeys-docs-1", "solokeys-probe-rt-1" ] }, { "productId": "token2", "storyId": "agent-fleet-provisioning", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Token2 ships an open-source CLI (fido2-manage) for local device configuration and a PowerShell bulk-enrollment script that automates pre-registering keys into Microsoft Entra ID via Microsoft's Graph API — some scriptable, agent-drivable provisioning exists. However, there is no evidence of Token2's own documented enterprise API for ordering or assigning keys to users, and probes confirm no OpenAPI/swagger spec exists on their site. missing for 10: a Token2-owned ordering API, an assignment/fleet-management API, and any documented enterprise API surface beyond third-party (Microsoft) integration scripts.", "evidenceIds": [ "token2-docs-2", "token2-gh-1", "token2-gh-4", "token2-probe-3", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "agent-key-audit", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2's open-source fido2-manage CLI/GUI tool (scriptable over USB/NFC) can view device information, list resident credentials (passkeys) with user handle, manage PINs, and enumerate biometric templates — giving an agent a scriptable path to audit key state across a fleet. However, no evidence documents reading serial numbers, firmware version, or 'enabled applications' specifically, nor is there a structured/JSON API, OpenAPI spec, or llms.txt for machine-readable output (confirmed 404s), so agent-friendly programmatic access is only partially evidenced. Missing for 10: documented serial/firmware-version fields, explicit 'enabled applications' enumeration, and a structured machine-readable output/API for agent consumption.", "evidenceIds": [ "token2-gh-1", "token2-gh-2", "token2-gh-3", "token2-docs-7", "token2-probe-3", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct probes show no llms.txt (404) and no markdown-accessible docs (404), and no OpenAPI/agent-oriented documentation exists; Token2 is a hardware security key vendor with no evidence of agent-discoverable docs.", "evidenceIds": [ "token2-probe-1", "token2-probe-2", "token2-probe-3" ] }, { "productId": "token2", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with management/provisioning tools (FIDO2 device management, TOTP tools, PIV tools); it has no data analytics, AI-generated insights, or suggestion features, and this is a category mismatch rather than a missing capability for its product type.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/FIDO2 management product; there is no concept of autonomous background automations in its evidence. This is a category mismatch (agenticness axis) rather than a missing feature for this authentication-tool product.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/authentication management product (FIDO2/PIV/TOTP tooling); there is no AI assistant feature or agentic task-delegation concept applicable to this product category.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Token2 ships a PowerShell bulk-enrollment script (fido2_bulkenroll_entraid) that could in principle be scripted/automated, and fido2-manage exposes some command-line-style operations (PIN, SSH key management) beyond its Python/tkinter GUI, suggesting some automation potential. However, the flagship tool is explicitly GUI-based and requires physical FIDO2 hardware interaction over USB/NFC, and there is no documented headless mode, CI integration, or automation-focused CLI/API (no OpenAPI, no llms.txt, no CI examples). Missing for 10: dedicated headless/CI-mode documentation, evidence of non-interactive scripted runs without physical key presence, and any CI/pipeline integration guide.", "evidenceIds": [ "token2-docs-2", "token2-gh-4", "token2-docs-8", "token2-probe-4", "token2-probe-3", "token2-probe-1" ] }, { "productId": "token2", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key/authentication vendor with FIDO2/PIV management tools; MCP server integration for AI tool-use is entirely outside its product category.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with management tools (desktop apps, CLI, browser demos), not an AI agent or a platform that could plausibly expose an MCP server for agent connectivity; this axis is a category error for this product type.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/FIDO2 management product (GUI apps, CLI tools, browser demos); natural-language command operation is a wrong axis for this category of product — no evidence of any NL interface, and none would be expected.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2 publishes official open-source tools (fido2-manage, fido2_bulkenroll_entraid) that expose scriptable command operations (list/delete/generate/upload for keys, PIN, biometrics, SSH) usable from the command line, and the PowerShell bulk-enroll tool is inherently a CLI-style utility, but neither is explicitly branded or documented as an 'official CLI' for AI-native/agentic workflows — the flagship fido2-manage tool is described primarily as a GUI (Python/tkinter) application with underlying scriptable functions rather than a dedicated documented CLI interface. Missing for 10: explicit CLI documentation/binary/flags, examples of scripting/automation for AI agents, and independent confirmation the tool is used headlessly.", "evidenceIds": [ "token2-gh-2", "token2-gh-3", "token2-gh-4", "token2-docs-2", "token2-probe-rt-1", "token2-probe-4" ] }, { "productId": "token2", "storyId": "agentic-public-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor; probes explicitly show no public API, no OpenAPI/Swagger spec, and no llms.txt (404s across all checked endpoints). Its tools (fido2-manage CLI, GUI, browser demos) are device-management utilities over USB/NFC/WebAuthn, not a documented public API for programmatic/agentic control.", "evidenceIds": [ "token2-probe-1", "token2-probe-2", "token2-probe-3", "token2-gh-1" ] }, { "productId": "token2", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key (FIDO2/TOTP/PIV) vendor with management tools for keys and passkeys; it has no concept of API credentials or agent-scoped access tokens. Issuing scoped least-privilege API credentials for an AI agent is outside this product's category entirely.", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "token2", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key/FIDO2 vendor with device management tools; webhooks for event subscription are not a fit for this product category, which involves no event-driven API or service to subscribe to.", "evidenceIds": [] }, { "productId": "token2", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with no evidence of an API reference at all — the probes explicitly show no OpenAPI/swagger spec exists (404s across all candidate paths) and no llms.txt or docs.md exposure. There's no indication of an interactive, runnable API explorer anywhere in the evidence.", "evidenceIds": [ "token2-probe-3", "token2-probe-1", "token2-probe-2" ] }, { "productId": "token2", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with desktop/browser tools and a CLI, but there is no evidence of a machine-readable API spec; explicit probes for OpenAPI/Swagger endpoints and llms.txt all returned 404.", "evidenceIds": [ "token2-probe-1", "token2-probe-2", "token2-probe-3" ] }, { "productId": "token2", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with companion tools (FIDO2 management, TOTP generation, PIV/miniDriver tools), not a platform or API with distinct production/sandbox environments; the concept of testing against a sandbox without touching production data does not apply to this product category.", "evidenceIds": [] }, { "productId": "token2", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key vendor with desktop/CLI tools for FIDO2/PIV management; there is no evidence of any versioned public API, and probes confirm no OpenAPI/Swagger spec exists (404s across all candidate paths). No documentation of API versioning or deprecation policy is present anywhere in the evidence.", "evidenceIds": [ "token2-probe-3", "token2-probe-1", "token2-probe-2" ] }, { "productId": "token2", "storyId": "attestation-enforcement", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Token2 provides an AAGUID lookup tool to identify certified authenticators and a WebAuthn registration demo, which touch on device identification, but there is no documented mechanism for verifying attestation certificates or enforcing an allow-list of approved key models at registration. missing for 10: attestation certificate chain validation, FIDO Metadata Service integration, documented enterprise enrollment policy enforcement.", "evidenceIds": [ "token2-docs-10", "token2-docs-5", "token2-docs-2" ] }, { "productId": "token2", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Token2 provides fido2_bulkenroll_entraid, a dedicated PowerShell tool for bulk-provisioning FIDO2 keys into Entra ID, and fido2-manage is a scriptable CLI (list/delete/edit passkeys, PIN and bio-template management, SSH key handling) that can be run in loops/scripts to act across many devices. This is real automation-depth for security-key/credential management but is narrow in scope (security keys/passkeys, one specific IdP integration) rather than a general bulk-operations API. Missing for 10: a general-purpose bulk API/SDK, documented batch endpoints beyond the Entra-specific script, and independent evidence of large-scale bulk use in production.", "evidenceIds": [ "token2-docs-2", "token2-gh-1", "token2-gh-3", "token2-gh-4", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/authentication vendor with management tools for FIDO2/PIV devices; there is no automation/event-trigger rules engine in its product category, and the evidence pack covers device management, provisioning, and demos only, not conditional automation.", "evidenceIds": [] }, { "productId": "token2", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key/authentication tool vendor; nothing in its product scope relates to scheduling recurring jobs or workflows, which is an automation/orchestration concern outside a security-key management product's category.", "evidenceIds": [] }, { "productId": "token2", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/FIDO2 management product; 'automations' with version/review/rollback is a concept from workflow/agent automation platforms, not applicable to a security key management toolset.", "evidenceIds": [] }, { "productId": "token2", "storyId": "backup-key-strategy", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Token2's FAQ includes a 'How Do I Set Up a Backup Key?' entry, indicating some guidance exists, but the evidence pack contains no actual content on what is/isn't recoverable if a key is lost (e.g., resident credentials, PINs, biometrics, or TOTP seeds). Missing for 10: detailed recovery/lockout policy content, explicit statement of non-recoverable data (e.g., resident key private keys), and any independent corroboration of the backup-key workflow.", "evidenceIds": [ "token2-docs-17" ] }, { "productId": "token2", "storyId": "bulk-fleet-provisioning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2 offers a PowerShell-based bulk enrollment tool for Entra ID (fido2_bulkenroll_entraid) and an open-source fido2-manage CLI/GUI for per-key PIN, biometric, and passkey configuration, which supports pre-registration and bulk configuration workflows. However, there is no evidence of an organization-wide inventory, dashboard, or lifecycle-tracking system for issued keys beyond individual device management and Entra-specific scripting. Missing for 10: centralized fleet inventory/dashboard, cross-platform (non-Entra ID) bulk provisioning, and lifecycle status tracking (issued/revoked/expired) across an organization.", "evidenceIds": [ "token2-docs-2", "token2-gh-1", "token2-gh-3", "token2-probe-rt-1", "token2-docs-8" ] }, { "productId": "token2", "storyId": "certified-hardened-models", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack covers management tools and software (companion apps, FIDO2 demo, PIV miniDriver) but contains no mention of FIPS 140 validation, Common Criteria certification, or physical durability specifications (water/crush resistance) for any Token2 hardware devices. missing for 10: FIPS 140 validation certificates, Common Criteria certification listings, IP rating or crush-resistance test documentation for hardware keys.", "evidenceIds": [] }, { "productId": "token2", "storyId": "cli-key-management", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "fido2-manage is an official open-source Token2 tool that supports PIN set/change, resident-credential (passkey) and biometric slot management, and device info viewing, and a probe confirms it is documented as a CLI, giving genuine scriptable control over FIDO2 keys. However most docs describe it primarily as a Python/tkinter GUI rather than a dedicated CLI, and there's no explicit mention of an 'enable applications' feature or comprehensive CLI usage examples/API reference. missing for 10: explicit CLI command reference/examples, 'enable applications' capability, independent hands-on CLI scripting confirmation.", "evidenceIds": [ "token2-gh-2", "token2-gh-3", "token2-gh-1", "token2-docs-8", "token2-probe-4", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "connector-lineup", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack focuses entirely on software tools (FIDO2 management apps, TOTP toolset, PIV drivers) and never describes Token2's physical hardware lineup, connector types (USB-C/USB-A), or form factors (keychain, nano). No mention of product SKUs, dimensions, or port types is present, so there's no basis to confirm coverage of power-user form-factor variety. Missing for 10: hardware product listings, connector-type specs, form-factor descriptions (nano/keychain), any comparison chart of models.", "evidenceIds": [] }, { "productId": "token2", "storyId": "credential-management", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "fido2-manage (with GUI and CLI) lists resident credentials/passkeys with user handle, allows delete and edit metadata, and works over USB/NFC for any FIDO2.1 device, directly covering list/delete of passkeys stored on the key. However, there is no explicit evidence of a feature reporting remaining credential capacity or slot count before the key fills up. Missing for 10: explicit credential-capacity/slots-remaining reporting, independent hands-on confirmation of listing/deleting behavior.", "evidenceIds": [ "token2-gh-1", "token2-gh-2", "token2-gh-3", "token2-docs-7", "token2-docs-8", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "cross-platform-compat", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Evidence shows solid cross-OS/browser support (Windows control panel, Chromium browsers, macOS/Linux companion app, PIV miniDriver) and manufacturer-agnostic FIDO2.1 tooling, but there is no published catalog listing which third-party services/relying parties are certified compatible with Token2 keys. missing for 10: a published service/RP compatibility catalog, independent cross-browser/OS corroboration beyond vendor docs.", "evidenceIds": [ "token2-docs-7", "token2-docs-14", "token2-docs-15", "token2-docs-12", "token2-docs-9", "token2-gh-2" ] }, { "productId": "token2", "storyId": "enterprise-delivery-api", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers device management, bulk enrollment, and provisioning tools but nothing about a logistics/delivery service (e.g., automated shipping of physical keys to distributed employees) driven by API or console. No fulfillment, shipping, or distribution capability is documented anywhere in the evidence pack.", "evidenceIds": [] }, { "productId": "token2", "storyId": "fido2-resident-passkeys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Token2 sells FIDO2 hardware keys explicitly supporting resident/discoverable credentials (passkeys), with documentation and an open-source companion tool (fido2-manage) that lists, edits, and manages resident credentials including user handles, plus a browser-based demo to register and authenticate via WebAuthn without typing a username. Independent GitHub evidence corroborates the resident-key management feature set (list with user handle, delete, edit metadata).\n\nmissing for 10: no explicit third-party/independent test confirming passwordless username-less sign-in flow in production RP scenarios, and no FIDO Alliance certification citation for discoverable credential compliance.", "evidenceIds": [ "token2-gh-1", "token2-gh-2", "token2-docs-5", "token2-docs-7", "token2-docs-8", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "firmware-update-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Evidence covers key management tools (PIN, passkeys, PIV, SSH) but contains no security advisories, CVE/vulnerability disclosure process, affected-model lookup tool, or firmware update delivery mechanism for Token2 devices.", "evidenceIds": [] }, { "productId": "token2", "storyId": "guided-enrollment", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Token2 provides multiple avenues for onboarding: a browser-based FIDO2/passkey demo to test registration (token2-docs-5, token2-docs-16), OS-native guidance for macOS/Linux/Chrome and Windows control panel (token2-docs-13/14/15), a companion GUI app for device/passkey management (token2-docs-1/7/8), and an FAQ entry on setting up a backup key (token2-docs-17). This gives a reasonably guided path but is scattered across docs/tools rather than a single cohesive first-time setup wizard that walks a user through registering with specific real-world accounts (e.g., Google, Microsoft, GitHub). Missing for 10: a unified step-by-step onboarding flow/app tailored to major account providers, and independent user reports confirming ease of first-time setup.", "evidenceIds": [ "token2-docs-5", "token2-docs-16", "token2-docs-13", "token2-docs-14", "token2-docs-15", "token2-docs-17", "token2-docs-1", "token2-docs-7", "token2-docs-8" ] }, { "productId": "token2", "storyId": "hardware-approval-for-agents", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Token2's evidence covers FIDO2 key management, PIV, TOTP tools, and WebAuthn demos, but nothing shows integration with AI agents or automated workflows that would use a physical touch as an approval gate for agent-initiated actions. Missing for 10: any documentation of agent/automation integration, an approval-step API or SDK, or a workflow example tying physical touch to AI-agent action authorization.", "evidenceIds": [ "token2-docs-1", "token2-docs-5", "token2-gh-1", "token2-docs-9" ] }, { "productId": "token2", "storyId": "hardware-backed-ssh", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Token2's fido2-manage tool explicitly supports SSH security keys (generate, list resident, download/rehydrate, ssh-copy-id, add to local ssh-agent), directly evidencing FIDO2 sk-ssh hardware-backed key workflows. PIV is also supported via the Windows miniDriver and Companion App for smartcard-based certificate enrollment, but there is no mention of OpenPGP support for SSH auth. missing for 10: OpenPGP-based SSH key support, independent/hands-on verification of the sk-ssh workflow, and cross-platform PIV parity beyond Windows/macOS.", "evidenceIds": [ "token2-gh-4", "token2-docs-3", "token2-docs-11", "token2-docs-12", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "idp-policy-integration", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Token2 documents a dedicated Entra ID bulk-enrollment tool leveraging the Graph API, showing concrete IdP integration for one provider, and its keys are standard FIDO2 devices that any IdP could require via WebAuthn policy. However, there is no evidence of Okta or Google Workspace-specific integration tooling, nor documentation of admin-side policy enforcement (e.g., conditional access rules mandating hardware-key auth) — these are typically the IdP's own settings, not something Token2 documents supporting or configuring. Missing for 10: Okta integration evidence, Google Workspace integration evidence, and any documentation of fleet-wide policy enforcement/reporting.", "evidenceIds": [ "token2-docs-2", "token2-probe-rt-1", "token2-docs-11" ] }, { "productId": "token2", "storyId": "nfc-mobile-tap", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Token2's own tooling confirms its FIDO2 keys support NFC as a communication transport (used by the fido2-manage companion app to manage keys over USB or NFC), which implies NFC-capable hardware, but there is no explicit documentation stating that users can tap the key on a phone to authenticate within mobile browsers or apps via WebAuthn/CTAP2 NFC. Missing for 10: explicit end-user documentation or demo of phone-NFC-based authentication in mobile browsers/apps, and any independent confirmation of this specific mobile use case.", "evidenceIds": [ "token2-docs-8", "token2-gh-2", "token2-docs-9" ] }, { "productId": "token2", "storyId": "official-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows only management/admin tools (fido2-manage GUI/CLI, bulk enrollment for Entra ID, browser-based WebAuthn demo) rather than an official SDK or library for embedding the key's authentication into a developer's own desktop/mobile applications. No mention of a downloadable SDK, API bindings, or mobile library is found anywhere in the pack.", "evidenceIds": [ "token2-docs-1", "token2-gh-1", "token2-gh-2", "token2-gh-3", "token2-gh-4", "token2-docs-5", "token2-probe-3", "token2-probe-4" ] }, { "productId": "token2", "storyId": "open-source-firmware", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "All evidence concerns open-source host-side management tools (fido2-manage GUI, companion app, bulk-enrollment scripts) that run on a computer to manage the keys — none of it addresses whether the actual device firmware running on the Token2 hardware key itself is open source or has undergone independent security audit.", "evidenceIds": [] }, { "productId": "token2", "storyId": "openness-api-parity", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Token2 ships an open-source CLI (fido2-manage) that overlaps with much of the companion GUI's functionality — resident credential/passkey management, PIN setup, biometric template management, and SSH key operations can all be scripted — giving some AI-native/automation parity with the desktop UI. However, there is no true REST/HTTP API (probes confirm openapi.json/swagger.json all 404), and several UI-only web tools (TOTP toolset, WebAuthn browser demo, factory reset) have no documented programmatic equivalent. Missing for 10: a formal API surface (REST/OpenAPI) covering all UI functions, CLI/API parity for the web-based demo and TOTP tools, and independent confirmation that CLI coverage is fully equivalent to the GUI.", "evidenceIds": [ "token2-gh-1", "token2-gh-3", "token2-gh-4", "token2-docs-7", "token2-docs-4", "token2-docs-5", "token2-probe-3", "token2-probe-4", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2 supports exporting TOTP seeds as open CSV/JSON files for Entra ID import, and its open-source fido2-manage tool lets users list, download, and rehydrate resident credentials and SSH keys from FIDO2 devices, plus it's explicitly manufacturer-agnostic (works with any FIDO2.1 key), supporting migration away from Token2 hardware without lock-in. However, this covers only specific data types (TOTP seeds, credentials, SSH keys) rather than a full account/data export, and there's no unified 'export everything' feature or documentation. Missing for 10: comprehensive account-wide data export, first-party documentation framing this as a full data portability/exit feature, independent verification of export completeness.", "evidenceIds": [ "token2-docs-6", "token2-gh-1", "token2-gh-4", "token2-docs-9", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "openness-open-license", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Token2 open-sources some companion tooling on GitHub (fido2-manage, fido2_bulkenroll_entraid) with real activity (112 stars, recent pushes), letting an AI-native user inspect that code, but the core hardware product/firmware and several web tools (TOTP toolset, FIDO2 demo) are not shown to have public source, and no explicit license file/type is cited. Missing for 10: confirmed OSI license text, source availability for the full product line (not just auxiliary management tools).", "evidenceIds": [ "token2-docs-1", "token2-gh-1", "token2-gh-2", "token2-docs-2", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "token2", "storyId": "openpgp-onkey", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "token2", "storyId": "otp-legacy-slots", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows a browser-based TOTP toolset (docs-4, docs-6) and Entra ID seed export, unrelated to the FIDO2 security key itself carrying TOTP/HOTP slots or challenge-response capability; no documentation shows the hardware key supports legacy OTP protocols. Missing for 10: any spec sheet or docs stating the key itself implements TOTP/HOTP slots, challenge-response mode, or dual-protocol firmware.", "evidenceIds": [ "token2-docs-4", "token2-docs-6" ] }, { "productId": "token2", "storyId": "pin-biometric-verification", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Evidence confirms FIDO2 PIN setup/change and biometric template enrollment/management via the companion tool and fido2-manage (PIN management, min PIN length, biometric templates: list, rename, delete, enroll), and browsers/OS natively prompt for PIN when required, satisfying on-device user verification against theft. missing for 10: no independent/hands-on third-party testing confirming UV enforcement during actual authentication ceremonies, and no explicit CTAP2 'uv' flag/attestation documentation.", "evidenceIds": [ "token2-gh-3", "token2-docs-7", "token2-docs-13", "token2-docs-8", "token2-probe-rt-1" ] }, { "productId": "token2", "storyId": "piv-smartcard-login", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2 documents PIV support via a Windows miniDriver and macOS Companion App enabling smartcard-based certificate enrollment and login with on-prem AD, which covers workstation sign-in use cases. However, there is no evidence for VPN integration or code signing use cases specifically, nor independent/hands-on verification of PIV certificate workflows beyond vendor docs. missing for 10: VPN certificate-auth evidence, code-signing use case evidence, independent/hands-on validation of PIV smartcard login, detail on key non-exportability guarantees for PIV certs.", "evidenceIds": [ "token2-docs-3", "token2-docs-11", "token2-docs-12" ] }, { "productId": "token2", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security-key/authenticator vendor with local management tools; it does not store user data in a cloud service, so data residency/region selection is not an applicable axis for this product category.", "evidenceIds": [] }, { "productId": "token2", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Token2 is a hardware security key/FIDO2 authentication vendor; it has no AI model training data pipeline or data-usage policy relevant to AI training. This axis is a category error for a hardware authentication product line.", "evidenceIds": [] }, { "productId": "token2", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Token2's tools give users direct control to delete data stored on their own security keys — resident credentials/passkeys can be listed, edited, and deleted, biometric templates can be deleted, and factory resets are supported (token2-gh-1, token2-gh-3, token2-docs-7). This covers device-level data deletion but there is no documentation of server-side retention policies, account-level data deletion, or how long any cloud-side telemetry/data is retained. Missing for 10: server-side/account data retention policy documentation, explicit data-deletion request process for any cloud-stored data, independent confirmation of retention practices.", "evidenceIds": [ "token2-gh-1", "token2-gh-3", "token2-docs-7", "token2-docs-8" ] }, { "productId": "token2", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of telemetry, analytics, or usage tracking, nor any settings to opt out of such tracking, for Token2's desktop companion app, fido2-manage tool, or web tools. missing for 10: any documentation of data collection practices, a privacy policy reference, or a telemetry opt-out mechanism.", "evidenceIds": [] }, { "productId": "token2", "storyId": "webauthn-second-factor", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Token2 provides standards-based FIDO2/WebAuthn/U2F hardware keys with strong first-party tooling for Microsoft Entra ID enrollment and a general WebAuthn demo/testing tool, implying broad cross-service compatibility as a certified FIDO2.1 device. However, there is no direct documentation or independent confirmation of successful registration/use with Google, GitHub, or specific password managers. Missing for 10: explicit vendor or third-party evidence of working as a 2FA/passkey with Google, GitHub, and named password managers.", "evidenceIds": [ "token2-docs-2", "token2-docs-5", "token2-docs-9", "token2-docs-16", "token2-gh-2" ] }, { "productId": "yubikey", "storyId": "agent-fleet-provisioning", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Yubico's YubiEnterprise 'YubiKey as a Service' REST API is documented and publicly live (console.yubico.com/apidocs/), providing a programmatic surface for fleet delivery, inventory, and shipment management that an agent could call instead of a human-only console. However, the evidence pack gives no detail on specific endpoints for ordering, assignment, or pre-registration workflows, no sample agent integration, and no independent confirmation of end-to-end automation success. Missing for 10: detailed API endpoint documentation for order/assign/pre-register flows, evidence of actual agent-driven automation, and independent corroboration of the API's completeness.", "evidenceIds": [ "yubikey-probe-rt-2" ] }, { "productId": "yubikey", "storyId": "agent-key-audit", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Yubico's official ykman CLI (and underlying python-fido2/yubikey-manager libraries) exposes exactly this data programmatically: serial number, firmware version, enabled applications, PIN/PIV/OATH/OTP slot state, all scriptable without a client GUI — confirmed both in docs (docs-4, docs-15/25) and a keyless runtime probe showing full scriptable device management (probe-rt-1) plus SDK availability on PyPI (probe-rt-3). An agent can shell out to ykman on each key to build a fleet audit, though Yubico provides no built-in cross-fleet aggregation/reporting endpoint (the YubiEnterprise API in probe-rt-2 covers shipping/inventory, not live security-posture state). Missing for 10: a native fleet-wide audit/reporting API or dashboard aggregating multiple keys' state, and independent hands-on confirmation of scripting this across many devices at scale.", "evidenceIds": [ "yubikey-docs-4", "yubikey-docs-15", "yubikey-docs-25", "yubikey-probe-4", "yubikey-probe-rt-1", "yubikey-probe-rt-3", "yubikey-probe-rt-2" ] }, { "productId": "yubikey", "storyId": "agentic-agent-docs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Direct probes confirm no llms.txt or agent-oriented docs exist on any Yubico domain (404s across docs.yubico.com, developers.yubico.com, www.yubico.com), and no MCP endpoint resolves; documentation is human-oriented HTML only.", "evidenceIds": [ "yubikey-probe-1", "yubikey-probe-2", "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "agentic-ai-insights", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device (security key); it has no data surface, dashboard, or analytics function to generate AI insights from. This axis is a category error for a hardware security key product.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-autonomous-automation", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; it requires physical touch/presence for its security model and cannot run autonomous background automations — this is a category error, not a missing feature.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-builtin-assistant", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; it has no AI assistant of any kind, built-in or otherwise. This story is a category error for this product type.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-headless", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Yubico ships scriptable tooling (ykman CLI, python-fido2 SDK) that can configure/query keys programmatically in scripts or CI pipelines, and a fleet REST API for enterprise management — but the core authentication function inherently requires physical touch/user presence, which cannot be automated headlessly. Missing for 10: any documented way to perform actual FIDO2/PIV/OATH authentication or signing operations without a human touch event, explicit CI/automation guidance, and evidence of true headless operation for the security-critical path (only configuration/management is scriptable).", "evidenceIds": [ "yubikey-docs-4", "yubikey-docs-6", "yubikey-probe-rt-1", "yubikey-probe-rt-2", "yubikey-probe-rt-3" ] }, { "productId": "yubikey", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; plugging MCP servers into it so it can use their tools is a category error—it has no agentic runtime to consume tools. Evidence confirms no MCP endpoint exists, but that's incidental since the axis doesn't apply to this product type.", "evidenceIds": [ "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "agentic-mcp-server", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device, not an agent or platform serving tools to AI agents; connecting agents via MCP servers is a category mismatch for this product type.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-nl-commands", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device operated via physical touch, PIN entry, and traditional CLI tools (ykman) for configuration — there is no natural-language command interface, and the product category (a cryptographic hardware token) does not involve conversational or agentic control surfaces. This axis is a category error for a hardware key rather than an unmet capability.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-official-cli", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "YubiKey ships an official CLI (ykman/yubikey-manager) for device configuration, verified installable via pip/uvx and Homebrew with scriptable device management, but this is a hardware-configuration tool, not an AI-agentic CLI designed for LLM/agent workflows — there's no evidence of AI-native features like structured output for agents, agent-oriented docs, or MCP integration. missing for 10: evidence of AI-agent-oriented usage patterns, structured/machine-readable output tailored for agentic consumption, and any llms.txt/MCP support (explicitly absent per probes).", "evidenceIds": [ "yubikey-docs-4", "yubikey-probe-4", "yubikey-probe-rt-1", "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "agentic-public-api", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "YubiKey exposes genuine programmatic interfaces — the ykman CLI, python-fido2 SDK, PKCS#11/PIV/OpenPGP libraries, and platform SDKs (Android/iOS/.NET) — that let a developer or automated agent drive the device (yubikey-docs-4, yubikey-probe-rt-1, yubikey-probe-rt-3, yubikey-docs-8, yubikey-docs-19). There is also a separate REST API for YubiEnterprise fleet management (yubikey-probe-rt-2). However, there is no unified public REST/OpenAPI spec for the core device (probe-3 confirms 404s), and no AI-agent-oriented discovery layer like llms.txt or MCP (yubikey-probe-1, yubikey-probe-rt-4). Missing for 10: a documented OpenAPI/REST spec for core device operations, and any llms.txt/MCP support for AI-agent consumption.", "evidenceIds": [ "yubikey-docs-4", "yubikey-probe-rt-1", "yubikey-probe-rt-2", "yubikey-probe-rt-3", "yubikey-docs-8", "yubikey-docs-19", "yubikey-probe-3", "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "agentic-scoped-keys", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device for human-presence-based MFA/passkeys/PIV/SSH — it authenticates a person via touch, PIN, or physical possession. It has no concept of issuing scoped, least-privilege API credentials to an autonomous agent (a distinct IAM/OAuth-style capability); its APIs (ykman, YubiEnterprise fleet API, python-fido2) manage the physical device itself, not agent-scoped credentials. This is a category mismatch, not a missing feature.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "agentic-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Yubico publishes and maintains a broad set of official SDKs (python-fido2, java-webauthn-server, .NET SDK, YubiKit Android/iOS, ykman CLI) with dedicated docs, and runtime probes confirm these packages are live and installable from public registries (PyPI, Homebrew) rather than just claimed in docs. This gives developers, including AI-native builders, real programmatic building blocks for passkeys/FIDO2/PIV integration. Missing for 10: no AI-agent-specific SDK examples or agent-oriented tooling, and no independent (non-Yubico) hands-on validation of SDK developer experience.", "evidenceIds": [ "yubikey-docs-13", "yubikey-docs-19", "yubikey-docs-20", "yubikey-docs-21", "yubikey-probe-rt-1", "yubikey-probe-rt-3", "yubikey-docs-12" ] }, { "productId": "yubikey", "storyId": "agentic-webhooks", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device/SDK ecosystem, not an event-driven platform; there is no concept of subscribable events or webhooks applicable to its product category — this is a category error, not a missing feature.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows YubiKey's developer docs are static HTML references (SDK guides, protocol explanations) rather than an interactive, runnable API console; explicit probes for OpenAPI/Swagger specs return 404 and no llms.txt/MCP endpoint exists. The only REST API surface found (YubiEnterprise apidocs) is confirmed live but with no evidence of runnable/try-it-out examples.", "evidenceIds": [ "yubikey-probe-3", "yubikey-probe-rt-2", "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Explicit probes for OpenAPI/Swagger specs at docs.yubico.com and developers.yubico.com all returned 404s, and no llms.txt or machine-readable API spec was found anywhere in Yubico's domains. While a YubiEnterprise REST API console exists, there is no evidence it is exposed as a downloadable OpenAPI/machine-readable spec.", "evidenceIds": [ "yubikey-probe-3", "yubikey-probe-rt-4", "yubikey-probe-rt-2" ] }, { "productId": "yubikey", "storyId": "api-sandbox", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; the notion of a sandbox environment to test against without touching production data is not a meaningful axis for this product category — it's a physical security key, not a service with test/production data separation.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "YubiKey ships multiple SDKs and a REST API (YubiEnterprise) plus CLI tools, so the axis of API stability/versioning is applicable, but nothing in the evidence pack documents a versioning scheme or deprecation policy for any of these surfaces — firmware version references (yubikey-docs-15/25) concern hardware firmware, not API contracts, and probes found no OpenAPI spec or changelog.", "evidenceIds": [ "yubikey-docs-15", "yubikey-docs-25", "yubikey-probe-rt-2", "yubikey-probe-3" ] }, { "productId": "yubikey", "storyId": "attestation-enforcement", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "YubiKey documents PIV attestation explicitly: certificates prove a key was generated on-device (not imported), and python-fido2 provides library support for 'verifying attestation and assertion signatures,' enabling backend registration flows to reject non-genuine or imported keys. This directly supports enforcing genuine device enrollment at registration time. Missing for 10: no independent/hands-on validation of attestation-based enrollment enforcement in production, and no explicit vendor-model allowlisting guide beyond the raw attestation cert mechanism.", "evidenceIds": [ "yubikey-docs-11", "yubikey-docs-18", "yubikey-docs-13", "yubikey-probe-rt-3" ] }, { "productId": "yubikey", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Yubico exposes a scriptable CLI (ykman) and a YubiEnterprise fleet-management REST API that could be used to configure or manage many keys programmatically, hinting at bulk-capable automation, but no docs explicitly describe a bulk/batch operation (e.g., configuring N keys or revoking many credentials in one call). Missing for 10: explicit bulk-operation API/CLI documentation, batch examples, and independent confirmation that many items can be processed in one automated action.", "evidenceIds": [ "yubikey-probe-rt-1", "yubikey-probe-rt-2", "yubikey-docs-4" ] }, { "productId": "yubikey", "storyId": "automation-rules-engine", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication/security key (FIDO2, PIV, OpenPGP, OTP) — it has no event-driven rules engine or automation-trigger capability, and defining automated action rules is outside its product category as an authenticator rather than an automation platform.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "automation-scheduled-jobs", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; scheduling recurring jobs/workflows is a software automation/orchestration capability entirely outside a security key's product category — this is a wrong-axis question, not a missing feature.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "automation-versioned-workflows", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; it has no concept of automations to version, review, or roll back. This story applies to workflow/automation platforms, not a security key product.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "backup-key-strategy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no vendor documentation describing a lockout-recovery strategy (e.g., backup key enrollment guidance, what's recoverable vs. not). Community threads instead highlight the opposite experience — users must manually track and re-register every account per lost key with no central mechanism (yubikey-comm-7), and lost/compromised keys require full manual replacement across all enrolled services (yubikey-comm-2, yubikey-comm-6) — indicating this is an unaddressed gap rather than a documented workflow.", "evidenceIds": [ "yubikey-comm-7", "yubikey-comm-2", "yubikey-comm-6" ] }, { "productId": "yubikey", "storyId": "bulk-fleet-provisioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yubico documents ykman for scriptable bulk device configuration (PIN/PIV/OATH/OTP setup) and a live YubiEnterprise 'YubiKey as a Service' REST API covering fleet delivery, inventory, and shipment management, plus PIV attestation to verify keys were hardware-generated — together these map to pre-registration, bulk config, and some lifecycle tracking. Missing for 10: detailed enterprise lifecycle-tracking dashboard docs, independent/customer case studies of at-scale deployment, and clearer documentation tying pre-registration workflows directly to the API rather than inferring from an apidocs page title.", "evidenceIds": [ "yubikey-probe-rt-1", "yubikey-probe-rt-2", "yubikey-docs-11", "yubikey-docs-18", "yubikey-docs-4" ] }, { "productId": "yubikey", "storyId": "certified-hardened-models", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The evidence pack contains no mention of FIPS 140 validation, Common Criteria certification, or documented durability/water/crush resistance testing for any YubiKey model. While this axis clearly applies to a hardware security key product aimed at regulated environments, none of the docs, community, or probe items address certification status or physical durability specs, so there is nothing to credit.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "cli-key-management", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "ykman is Yubico's official CLI for configuring YubiKeys — enabling/disabling applications, setting PINs, managing PIV/OATH/OTP slots, and reading device/firmware state — and is documented and verified installable/scriptable via pip/Homebrew/uvx in runtime probes. Independent community mentions corroborate real-world use of ykman-adjacent workflows (e.g., PIN enrollment via CLI/GUI tools). Missing for 10: no independent hands-on developer review specifically praising ykman's scripting ergonomics beyond install verification.", "evidenceIds": [ "yubikey-docs-4", "yubikey-docs-15", "yubikey-probe-4", "yubikey-probe-rt-1", "yubikey-comm-13" ] }, { "productId": "yubikey", "storyId": "connector-lineup", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no documentation or community confirmation of specific YubiKey form factors (USB-C, USB-A, keychain, nano) — only general docs about protocols/SDKs and community comments about size/bulkiness in vague terms (e.g., yubikey-comm-9 says 'more compact and less bulky' without specifics). Missing for 10: explicit product-line documentation of USB-A/USB-C variants, nano/keychain form factors, and any independent confirmation of the lineup breadth.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "credential-management", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Yubico's ykman CLI/GUI (docs-4, probe-rt-1) provides broad scriptable device management (PIV/OATH/OTP slots, PINs, device info) and firmware/version info tools (docs-15/25), suggesting some credential-management capability exists, but no evidence explicitly confirms listing/deleting FIDO2 passkey credentials or showing passkey storage capacity/limits. Community threads discuss losing track of which accounts a key is enrolled in (yubikey-comm-7) rather than a management UI. Missing for 10: explicit documentation of a 'list/delete FIDO2 credentials' command, and disclosure of the discrete passkey slot capacity/limit warning.", "evidenceIds": [ "yubikey-docs-4", "yubikey-probe-rt-1", "yubikey-docs-15", "yubikey-comm-7" ] }, { "productId": "yubikey", "storyId": "cross-platform-compat", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Docs show broad standards-based compatibility (FIDO2/WebAuthn, PIV, OpenPGP, OTP, SSH) and SDKs for iOS, Android, .NET, and desktop, implying cross-OS/browser support, and community posts confirm real-world use across GPG/PIV/SSH/WebAuthn workflows. However, there is no evidence of a published, browsable compatibility catalog listing specific supported services/websites or a browser support matrix as the story requests. Missing for 10: an explicit 'works with' directory of supported services/sites, and a documented OS/browser compatibility matrix beyond protocol-level claims.", "evidenceIds": [ "yubikey-docs-16", "yubikey-docs-17", "yubikey-docs-19", "yubikey-docs-20", "yubikey-docs-21", "yubikey-comm-14", "yubikey-comm-16" ] }, { "productId": "yubikey", "storyId": "enterprise-delivery-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yubico's YubiEnterprise 'YubiKey as a Service' REST API is documented and live at console.yubico.com/apidocs/, described as the programmatic surface for fleet delivery, inventory, and shipment management — directly matching the API/console-driven distribution story. However, this rests on a single probe citation with no deeper documentation of the shipping workflow itself, no case studies, and no independent corroboration that enterprises use it this way in practice. Missing for 10: detailed docs on shipment/delivery mechanics, customer/independent confirmation of the service in use, and console UI evidence beyond the API doc existing.", "evidenceIds": [ "yubikey-probe-rt-2" ] }, { "productId": "yubikey", "storyId": "fido2-resident-passkeys", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "YubiKey firmware 5+ and CTAP2 support discoverable/resident credentials for passwordless, usernameless passkey sign-in, backed by Yubico's own passkey docs, WebAuthn docs, python-fido2/java-webauthn-server SDKs, and marketing explicitly calling it 'strongest hardware-backed passkey', plus community confirmation of FIDO2/WebAuthn support alongside other smartcard apps. Missing for 10: no independent hands-on test specifically confirming resident-key/discoverable-credential storage limits or usernameless login flow success in the wild.", "evidenceIds": [ "yubikey-docs-3", "yubikey-docs-14", "yubikey-docs-16", "yubikey-docs-17", "yubikey-docs-27", "yubikey-docs-13", "yubikey-docs-12", "yubikey-comm-14" ] }, { "productId": "yubikey", "storyId": "firmware-update-policy", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Docs show only a firmware-version lookup tool (ykman/Authenticator) with no official advisory page, CVE list, or affected-model lookup in the evidence pack, and community reports confirm YubiKey firmware is not field-upgradable — vulnerability response instead relies on ad-hoc device replacement (comm-3, comm-5, comm-8) which posters describe as inconsistent and manual (comm-2, comm-4, comm-6), directly undercutting any 'clear fix pipeline' claim. missing for 10: published security-advisory index, affected-model/serial lookup tool, documented recall/replacement SLA, and any firmware-update delivery mechanism.", "evidenceIds": [ "yubikey-docs-15", "yubikey-docs-25", "yubikey-comm-3", "yubikey-comm-5", "yubikey-comm-8", "yubikey-comm-2", "yubikey-comm-4", "yubikey-comm-6" ] }, { "productId": "yubikey", "storyId": "guided-enrollment", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Yubico ships an official 'Yubico Authenticator' app described as an 'intuitive and easy-to-use GUI interface' and provides technical guides for SSH/PGP/PIV/FIDO setup, but these are protocol-specific developer docs, not an end-to-end enrollment wizard for registering a key with personal accounts. A hands-on community report (yubikey-comm-13) describes exactly the opposite of guided onboarding: a new user enrolled keys without setting a PIN because the right guidance wasn't surfaced, then had to unenroll everywhere, set a PIN, and re-enroll — a concrete documented setup failure for a power user. Missing for 10: a dedicated first-run setup app/wizard walking users through registering with common accounts (Google, GitHub, etc.), and independent corroboration that such guidance works smoothly in practice.", "evidenceIds": [ "yubikey-docs-15", "yubikey-docs-25", "yubikey-comm-13", "yubikey-docs-24" ] }, { "productId": "yubikey", "storyId": "hardware-approval-for-agents", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "YubiKey's FIDO2/WebAuthn and SSH implementations require a physical touch for every cryptographic operation, and SDKs like python-fido2, PKCS#11, and yubikey-manager expose this as a programmable building block that could be wired into an agent approval flow, but there is no evidence of any actual AI-agent or automation-approval integration built on this. missing for 10: any documented agent-framework integration, a sample workflow gating an AI or agent action behind YubiKey touch, or a third-party report of this pattern in use.", "evidenceIds": [ "yubikey-docs-6", "yubikey-docs-23", "yubikey-docs-24", "yubikey-probe-rt-3", "yubikey-comm-10" ] }, { "productId": "yubikey", "storyId": "hardware-backed-ssh", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Yubico documents all three hardware-backed SSH paths: FIDO2 sk-ssh keys generated on-device with OpenSSH (private key never leaves hardware, touch required per operation), PIV smartcard usage via PKCS#11 for sign/encrypt with SSH, and OpenPGP smartcard keys for SSH auth. Community corroboration confirms FIDO2/PIV/OpenPGP smartcard functionality and touch-to-sign is genuinely enforced (not remotely bypassable). Missing for 10: no independent hands-on benchmark of ed25519 sk-ssh key generation end-to-end, and some community friction noted around PIN/touch UX onboarding.", "evidenceIds": [ "yubikey-docs-5", "yubikey-docs-6", "yubikey-docs-8", "yubikey-docs-9", "yubikey-docs-23", "yubikey-docs-24", "yubikey-comm-14", "yubikey-comm-16", "yubikey-comm-10" ] }, { "productId": "yubikey", "storyId": "idp-policy-integration", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers YubiKey's general FIDO2/WebAuthn/passkey protocol support and a fleet-management API (YubiEnterprise) for shipment/inventory, but contains no mention of specific IdP integrations (Okta, Entra ID, Google Workspace) or of admin-configurable policies enforcing hardware-key-only authentication. Since IdP integration and policy enforcement are a fair and expected axis for an enterprise MFA hardware vendor, absence of evidence means 'none' rather than 'na'. Missing for 10: documented Okta/Entra ID/Google Workspace integration guides, admin policy/enforcement console features, and any independent confirmation these integrations work in practice.", "evidenceIds": [ "yubikey-probe-rt-2", "yubikey-docs-16", "yubikey-docs-27" ] }, { "productId": "yubikey", "storyId": "nfc-mobile-tap", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yubico's own SDK docs confirm NFC support for both Android (yubikit-android supports USB and NFC-enabled YubiKeys) and iOS (yubikit-ios provides NFC OTP requests), and YubiKey's core FIDO2/WebAuthn/passkey stack (docs-27, docs-14, docs-16) is the basis for authenticating in mobile browsers/apps, but the evidence is SDK/developer-facing rather than an end-user confirmation that a stock mobile browser/app tap-to-auth flow just works. missing for 10: an explicit first-party or hands-on claim that end-users can tap NFC on a phone in a mobile browser (not just app SDK) to authenticate, and independent/community corroboration of real-world NFC mobile browser use.", "evidenceIds": [ "yubikey-docs-20", "yubikey-docs-21", "yubikey-docs-27", "yubikey-docs-14", "yubikey-docs-16" ] }, { "productId": "yubikey", "storyId": "official-sdks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Yubico provides official desktop SDK (.NET SDK, yubikey-manager), Android (YubiKit) and iOS (yubikit-ios) mobile SDKs, plus python-fido2 and java-webauthn-server libraries, all documented and confirmed live on package registries. missing for 10: independent third-party developer testimonials on ease of SDK integration, and no official cross-platform (e.g. Flutter/React Native) SDK is mentioned.", "evidenceIds": [ "yubikey-docs-2", "yubikey-docs-19", "yubikey-docs-20", "yubikey-docs-21", "yubikey-docs-13", "yubikey-probe-rt-1", "yubikey-probe-rt-3" ] }, { "productId": "yubikey", "storyId": "open-source-firmware", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Yubico documentation and community evidence describe YubiKey firmware as closed and non-upgradable ('proprietary smartcard', 'not being able to flash firmware is a feature'), with no mention of open-sourcing or third-party firmware audits anywhere in the evidence pack; no vendor claim or independent report of open/audited firmware exists to evaluate.", "evidenceIds": [ "yubikey-comm-3", "yubikey-comm-8", "yubikey-comm-9", "yubikey-comm-17" ] }, { "productId": "yubikey", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Yubico's ykman CLI is documented as functionally interchangeable with the Yubico Authenticator GUI for core device configuration (enabling applications, PINs, PIV/OATH/OTP slots, firmware info), and the YubiEnterprise REST API covers fleet-management tasks that would otherwise be done via console UI, giving real API/CLI parity for administrative workflows. However there's no evidence of a unified, fully-documented API surface covering every consumer-facing UI action (e.g., newer Authenticator app credential-management screens), and no llms.txt/MCP endpoint exists for agent discovery of these surfaces. Missing for 10: comprehensive mapping of every UI feature to an API/CLI equivalent, and agent-discoverable API documentation (llms.txt/MCP/OpenAPI all return 404).", "evidenceIds": [ "yubikey-probe-rt-1", "yubikey-probe-rt-2", "yubikey-docs-15", "yubikey-docs-25", "yubikey-probe-rt-4" ] }, { "productId": "yubikey", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "YubiKey's core design explicitly prevents exporting the data it stores — private keys are generated on-device and 'cannot be exported or extracted' (yubikey-docs-23), and SSH/FIDO2 docs stress private keys 'never leave the hardware' (yubikey-docs-5). There is no vendor or community evidence of any open-format bulk data export/portability path; the product's security model is fundamentally opposed to this story.", "evidenceIds": [ "yubikey-docs-23", "yubikey-docs-5", "yubikey-docs-7" ] }, { "productId": "yubikey", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "YubiKey is closed hardware/firmware — community evidence explicitly notes it is 'a proprietary smartcard' and that Yubico 'does not permit firmware flashing,' with no vendor claim or evidence of the core product's source being published under an open license. Some client SDKs/CLIs (python-fido2, ykman) are open-source, but that is tooling around the product, not the product's own source.", "evidenceIds": [ "yubikey-comm-17", "yubikey-comm-9", "yubikey-comm-3" ] }, { "productId": "yubikey", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "openpgp-onkey", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Yubico's own docs describe OpenPGP support with RSA/ECC sign/encrypt operations using a private key stored on the YubiKey smartcard (yubikey-docs-9, yubikey-docs-26), and independent community testimony confirms real-world use of YubiKey's GPG smartcard functionality (contrasted with competitors lacking it) (yubikey-comm-14, yubikey-comm-15). This covers the underlying capability for git commit signing (via GPG) and encrypted email (via OpenPGP), though neither specific workflow (git config, email client integration) is explicitly documented in the pack. Missing for 10: explicit git commit-signing walkthrough/documentation, explicit encrypted-email (e.g., Enigmail/Thunderbird) setup guide, and more first-party depth beyond the general OpenPGP overview.", "evidenceIds": [ "yubikey-docs-9", "yubikey-docs-26", "yubikey-comm-14", "yubikey-comm-15" ] }, { "productId": "yubikey", "storyId": "otp-legacy-slots", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "YubiKey natively supports OATH TOTP/HOTP slots (with secrets stored in the secure element) and Yubico OTP/challenge-response via the OTP application, documented and manageable via ykman/Yubico Authenticator, covering legacy services without WebAuthn. Community evidence corroborates real-world use of these legacy modes alongside FIDO2. Missing for 10: independent hands-on walkthrough of setting up HOTP/TOTP slots or challenge-response specifically, and more detail on slot capacity/limits.", "evidenceIds": [ "yubikey-docs-7", "yubikey-docs-10", "yubikey-docs-21", "yubikey-docs-4", "yubikey-comm-14" ] }, { "productId": "yubikey", "storyId": "pin-biometric-verification", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs explicitly confirm FIDO2 supports optional PIN-based user verification in addition to touch/presence (yubikey-docs-6), and community evidence corroborates PIN enrollment is a real, if sometimes overlooked, setup step (yubikey-comm-13). This directly matches on-device verification (PIN) preventing a stolen key alone from authenticating; biometric variants exist on Bio series keys but aren't explicitly documented here. Missing for 10: explicit mention of built-in biometric/fingerprint verification and independent hands-on confirmation of PIN enforcement blocking a stolen key.", "evidenceIds": [ "yubikey-docs-6", "yubikey-comm-13" ] }, { "productId": "yubikey", "storyId": "piv-smartcard-login", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs confirm PIV smart-card functionality (PKCS#11 sign/encrypt with on-device RSA/ECC keys, non-exportable, with attestation to prove device-generated keys), and community independently corroborates real-world PIV smart-card use (yubikey-comm-16, yubikey-comm-14). This covers certificate-based login and code-signing capability, though the workstation-login and VPN integration flows themselves aren't explicitly documented in this pack. Missing for 10: explicit docs/screenshots of Windows/macOS smart-card workstation sign-in setup, VPN client PIV integration guides, and a dedicated code-signing walkthrough.", "evidenceIds": [ "yubikey-docs-8", "yubikey-docs-11", "yubikey-docs-18", "yubikey-comm-16", "yubikey-comm-14" ] }, { "productId": "yubikey", "storyId": "privacy-data-residency", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device/token, not a data storage or cloud service; data residency/region selection is not a relevant axis for this product category (the evidence pack shows no user data storage service at all, aside from a minor enterprise device-inventory API unrelated to region choice).", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "YubiKey is a hardware authentication device; it has no role in AI model training data pipelines or data-usage opt-out controls, so preventing personal data from being used to train AI models is a category error for this product.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is \"none\", never \"na\". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers YubiKey's hardware authentication, SDKs, and CLI tooling, but contains no mention of telemetry collection or any opt-out/privacy-control setting for Yubico software (ykman, Yubico Authenticator, or the YubiEnterprise console). Since companion software and cloud services could plausibly include telemetry, the axis applies, but there's no evidence of a telemetry opt-out feature.", "evidenceIds": [] }, { "productId": "yubikey", "storyId": "webauthn-second-factor", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "YubiKey's core product design centers on FIDO2/WebAuthn and U2F as documented protocols, and community evidence corroborates that these keys function as WebAuthn/FIDO2 authenticators and PIV/GPG smartcards in real-world use across services. The docs describe passkey/WebAuthn support generically rather than confirming each specific service, but WebAuthn is a standard so this is a reasonable cross-service claim; independent community posts (yubikey-comm-14, yubikey-comm-16) reinforce broad protocol compatibility in practice.\nmissing for 10: explicit named confirmation/citations for Google, GitHub, Microsoft, and specific password manager integrations rather than generic standard-protocol docs.", "evidenceIds": [ "yubikey-docs-16", "yubikey-docs-14", "yubikey-docs-27", "yubikey-comm-14", "yubikey-comm-16", "yubikey-docs-6" ] } ]