What a static PQC-readiness scan sees in jjwt 0.13.0, and what it cannot see

[Arpan0995]

I maintain a static auditor that estimates what a post-quantum migration would touch in a Java codebase and how expensive each site is (https://github.com/Arpan0995/pqc-migration-readiness, Apache-2.0). jjwt 0.13.0 is one of the four pinned public codebases I use as case studies, and it is the one where the result needs the most interpretation, so I would rather put it in front of the people who wrote the code than let it stand on its own.

What the scan says (408 files, 193 findings, all in impl and api):

#	Step	Sites	Where	Effort
1	Set up a PQC provider and an agility seam	n/a	n/a	~3–5 days
2	Decouple concrete key types from APIs	181	impl, api	~10–19 weeks
3	Test and roll out	n/a	n/a	~5–19 weeks

Two things stand out, one about jjwt and one about the tool.

About jjwt: every one of the 193 findings is the same pattern, code written against RSAPublicKey, RSAPrivateKey, RSAKey, ECKey and friends. They cluster in the JWK factories (RsaPrivateJwkFactory and its EC counterpart), DynamicJwkBuilder and the legacy SignatureAlgorithm enum. In most codebases that pattern is accidental coupling. In jjwt it is deliberate: JWA defines keys per kty, and a JWK layer has to know which concrete key it is holding. So I read the 181 sites as the surface a new key type has to be threaded through, rather than as defects.

About the tool: it reports zero vulnerable call sites in jjwt, and that is wrong. Signing is obviously there. The algorithm name flows through Jwts.SIG and the registries instead of appearing as a literal at Signature.getInstance, and the scanner follows literals and static finals but not registries. I have that on record as Arpan0995/pqc-migration-readiness#5, and jjwt is the test case I intend to use for it.

The question I would value an answer to: when you think about ML-DSA as a first-class Jwts.SIG algorithm, is the JWK layer really the expensive part, as the scan suggests, or is the cost elsewhere, for example in the builder and parser validation paths, the key-length checks in KeysBridge, or documentation and compatibility policy? A rough ranking from you would be worth more than the numbers above.