Final Ranking, Scoring, and Analysis of Solo 2, Nitrokey Passkey, Token2 PIN+, Aegis, and Stratum

Executive Summary

The final ranking divides the field into two threat tiers. Tier H consists of hardware FIDO2/WebAuthn devices that provide phishing-resistant public-key authentication; Tier S consists of software HOTP/TOTP authenticators that remain valuable for legacy compatibility but are still structurally phishable. That distinction is not cosmetic. It follows from the difference between modern WebAuthn/FIDO2 authentication WebAuthn and shared-secret OTP schemes such as TOTP RFC 6238.

Scoring Framework

The final framework separates cryptographic/hardware strength from sovereign auditability. That split is essential. A closed secure-element device can dominate on tamper resistance while still losing points on transparency, inspectability, and independence from certification-heavy institutional trust regimes. The five scoring axes, all expressed on a 0–100 basis and then weighted, are shown below.

Final Score Matrix

Weights: A 30%, B 30%, C 15%, D 10%, E 15%. Composite = A×0.30 + B×0.30 + C×0.15 + D×0.10 + E×0.15.

Role: primary sovereign hardware root. Solo 2 lands first because it best reconciles strong modern phishing-resistant authentication with open hardware, open firmware, operator-controlled tooling, and minimal gravitational pull toward enterprise/cloud identity management. The official SoloKeys site presents Solo 2 as an open-source FIDO2 security key built with Trussed SoloKeys, while the public firmware repository and CLI expose the implementation surface directly firmware CLI.

A — Crypto & Hardware Assurance

Solo 2 is a real FIDO2/WebAuthn device, which places it in the phishing-resistant class. It supports modern public-key login flows rather than shared-secret OTP codes WebAuthn. It also ships with signed update support and USB/NFC interfaces, and the Solo 2 release metadata explicitly lists a complete FIDO2 implementation plus partial PIV support releases. The score stops short of the 90s here because Solo 2 is MCU-based rather than anchored in a discrete Common Criteria secure element.

B — Openness & Sovereign Auditability

This is the axis that pushes Solo 2 to the top. The device is built around public firmware, public tooling, and a clear developer-facing culture. The public repository notes that many components were contributed to the broader Trussed ecosystem README, and the CLI exposes regular and maintenance modes with explicit update tooling solo2-cli. That kind of inspectability matters more in this framework than conventional certification theater.

C — Privacy & Linkability

Solo 2 behaves like a plain security key without bundled telemetry, cloud dependencies, or vendor account binding. The main residual privacy surface comes from standard WebAuthn attestation behavior and whatever the relying party elects to log. Unlike enterprise inventory-focused products, Solo’s public-facing materials do not emphasize serial-number-based asset management or centralized fleet control product page.

D — Operational Robustness & Failure Modes

Signed firmware updates and open tooling increase resilience because the maintenance path is visible rather than hidden. At the same time, Solo 2’s more developer-leaning posture and partial PIV functionality add complexity. More power means more ways to misconfigure. That is why D is strong but not elite.

E — Ecosystem & Deployability

Solo 2 works in standard FIDO2 environments and also reaches into higher-leverage operator use cases via the partial PIV path PIV note. The main uncertainty is resident credential capacity: public official documentation is less explicit than Token2’s published 300-passkey claim. For scoring purposes, capacity was treated conservatively as being in the “dozens” class rather than the “hundreds” class.

Role: sovereign FIDO key from a broader open-hardware ecosystem. Nitrokey Passkey finishes second because it is extremely close to Solo 2 on openness, privacy posture, and anti-capture alignment, but trails slightly on deployability and role breadth. Nitrokey’s own documentation describes the Passkey as a FIDO2/WebAuthn device built on the Nitrokey 3 technology stack overview and notes explicitly that the Nitrokey App does not manage this device getting started.

A — Crypto & Hardware Assurance

Nitrokey Passkey is a true FIDO2/WebAuthn token and therefore belongs in the phishing-resistant hardware tier FIDO2/WebAuthn. The score does not inherit the full aura of Nitrokey 3, because Nitrokey’s Passkey line is deliberately stripped down. Nitrokey’s own FAQ states that the Passkey holds passkeys/FIDO2 keys and does not support OpenPGP FAQ. It is strong, modern, and focused, but it is not the secure-element-rich Nitrokey 3.

B — Openness & Sovereign Auditability

Nitrokey remains one of the cleanest vendors in the field for open hardware/security culture. The public docs, public firmware ecosystem, and broader Nitrokey product line create a strong environment for independent scrutiny docs index Nitrokey. The score lands just below Solo 2 because the Passkey is more productized and less developer-explicit than Solo’s tooling and hacker-oriented positioning.

C — Privacy & Linkability

Nitrokey Passkey is quiet by default: no Nitrokey account, no always-on management service, no obvious enterprise inventory framing. The device’s privacy surface is mostly the ordinary WebAuthn attestation layer and service-side logging rather than vendor-level telemetry.

D — Operational Robustness & Failure Modes

Nitrokey’s documentation includes management paths for Windows and other operating systems, which strengthens the operational story management. Nitrokey’s maintained documentation and public support ecosystem also reduce failure risk compared with obscure one-off products support.

E — Ecosystem & Deployability

This is where Nitrokey Passkey gives up ground. The current FAQ says the Passkey can hold over 100 passkeys capacity FAQ, which is stronger than older early-public comments that mentioned much lower counts during initial rollout. Even with that improvement, the device remains a focused FIDO artifact: no OpenPGP, no OTP, no PIV. That simplicity is clean, but it limits role consolidation.

Role: cryptographic tank and bridge device. Token2 PIN+ finishes third not because it is weak, but because the framework refuses to let opaque secure-element trust roots outrank more inspectable sovereign hardware by default. In conventional security terms, this is the strongest object in the set. Token2’s own materials advertise FIDO2.1, up to 300 passkeys, PIV and OpenPGP on selected models, and strong local PIN complexity enforcement PIN+ series PIN rules.

A — Crypto & Hardware Assurance

Token2 dominates this axis. The FAQ states that Token2 uses Common Criteria certified secure elements and highlights chips such as THD89 with EAL5+ status Token2 FAQ. The PIN+ line also advertises up to 300 passkeys in the Release 3 series 300 passkeys, and Token2’s complexity checker documents the enforced minimum 10-character alphanumeric PIN policy PIN complexity. On raw local assurance, this is the strongest artifact in the comparison.

B — Openness & Sovereign Auditability

Token2 deserves credit because it has published open-source FIDO firmware for the PIN+ line and references third-party review of that firmware open firmware note. The penalty enters because the critical security island is still an opaque secure element governed by certification bodies and vendor silicon, not by independently auditable hardware. This framework treats that as a real cost, not a footnote.

C — Privacy & Linkability

Token2 devices are quiet in the narrow sense that they do not require a vendor cloud account. The privacy discount comes from a different place: the product line is overtly optimized for enterprise deployment, inventorying, and compatibility with institutional identity stacks. Printed serials, formal model differentiation, and stronger attestation/compliance posture make these keys easier to organize as trackable assets store listing.

D — Operational Robustness & Failure Modes

Token2 is extremely capable, but capability creates operational surface. A device that can act as FIDO2, U2F, PIV, HOTP/TOTP, and OpenPGP on certain variants is inherently more complex to configure and govern than a focused passkey-only token Release 3. That complexity does not make it bad; it simply means a sovereign operator must actively constrain it rather than assume simplicity.

E — Ecosystem & Deployability

This is Token2’s strongest non-crypto category. Wide platform compatibility, very high credential capacity, NFC/USB variants, and multi-applet breadth make it the most deployable artifact in the group for mixed environments example product. If the comparison were weighted toward conventional enterprise capability rather than sovereign inspectability, Token2 could easily rank first.

Role: primary OTP vault for legacy and migration paths. Aegis finishes fourth overall and first in the software authenticator class. The official site describes it as a free, secure, open-source Android authenticator Aegis site, while the GitHub repository and vault documentation make the security model unusually explicit for an OTP app GitHub vault design.

A — Crypto & Hardware Assurance

Aegis is strong within the OTP class. The vault design document describes authenticated encryption and file format behavior, and the app supports encrypted local storage with clear backup behavior vault spec. The score remains below all hardware FIDO keys because TOTP itself is a phishable shared-secret scheme. That limitation is protocol-level, not an Aegis flaw TOTP standard.

B — Openness & Sovereign Auditability

This is where Aegis shines. The code is public, the security model is documented, and the project is actively maintained releases. It is one of the clearest examples in the comparison of a project that behaves like a proper FOSS security tool rather than a convenience wrapper around opaque cloud infrastructure.

C — Privacy & Linkability

Aegis’s privacy policy states that it does not collect data and uses camera access only for QR scanning privacy policy. The app is also available on F-Droid via the project site, which avoids mandatory Play Store dependence downloads. The remaining privacy penalty comes from the fact that it still lives on Android, which is a larger and often noisier substrate than a dedicated hardware key.

D — Operational Robustness & Failure Modes

Aegis scores strongly here because it offers encrypted backups, imports, exports, and explicit recovery paths FAQ. The main operational risk is external: loss of device plus poor backup discipline, not opacity in the tool itself.

E — Ecosystem & Deployability

Because so many services still expose TOTP but not security-key support, Aegis remains extremely deployable in the real world. It works cleanly as the OTP layer for legacy services while hardware keys carry the high-value authentication boundary.

Role: alternative OTP vault with strong privacy defaults, solid import/export behavior, and Wear OS reach. Stratum’s official site describes it as a free, open-source 2FA app with encrypted backups, categories, customization, and a Wear OS companion Stratum site, while the GitHub project and wiki expose backup, migration, and recovery documentation GitHub wiki.

A — Crypto & Hardware Assurance

Stratum supports TOTP/HOTP plus several niche variants, including Steam and Yandex-style flows repo overview. The score lands slightly below Aegis because the public cryptographic design is less foregrounded and less formalized in presentation, even though the project is clearly serious. As with Aegis, the deeper limitation is not coding quality but OTP’s shared-secret/phishable nature.

B — Openness & Sovereign Auditability

Stratum is fully open-source and active. The repository, releases, and wiki all remain publicly available and current releases FAQ. That gives it a very strong score for a software authenticator.

C — Privacy & Linkability

The product is offline-friendly and does not lean on a cloud backend. Its backup strategy can be kept local or pushed to self-controlled storage such as WebDAV backup docs. The small privacy discount versus Aegis reflects slightly broader ecosystem features and less explicit privacy framing, not a major weakness.

D — Operational Robustness & Failure Modes

Stratum scores well because the project documents migration and restoration clearly, including recovery from backups and import from other tools restore FAQ. Operationally, it is one of the stronger software authenticators.

E — Ecosystem & Deployability

Wear OS support, broad OTP compatibility, and customization keep Stratum highly deployable for legacy services and mobile workflows site. It remains slightly behind Aegis because Aegis pairs similar functionality with stronger public documentation around the vault/security model.

Stack Interpretation

The ranking is easiest to understand when converted into roles rather than brand worship. The analysis resolves into three operational classes.

Methodological Caveats and Remaining Uncertainties

The analysis is intentionally hard-edged, but not falsely omniscient. Several details remain moving targets or are only partially documented in public sources. Those uncertainties were handled conservatively in the final scores.

• Solo 2 resident credential capacity: official public documentation is less explicit than Token2’s published 300-passkey claim. Scoring therefore treated Solo 2 as a “dozens” device rather than assigning an unverified precise number.
• Nitrokey Passkey capacity changed over time: early public comments referenced much lower passkey counts, while the current FAQ says the device can hold over 100 passkeys FAQ. The final page uses the current documentation while still acknowledging earlier rollout constraints.
• Attestation/linkability details: device-level attestation behavior can materially affect privacy, but vendors do not always document every nuance in a clean public matrix. Privacy scores therefore reflect the conservative, ordinary case rather than optimistic assumptions.
• Secure element opacity: Token2’s secure-element strength is real, but public certification and vendor FAQs do not convert a closed silicon trust root into an open one. That asymmetry is a central reason the framework penalizes B despite the device’s excellent A score.
• OTP versus FIDO category gap: no amount of polish in Aegis or Stratum erases the structural difference between shared-secret OTP and phishing-resistant WebAuthn. The tier distinction remains part of the final interpretation, not a side note.