Standards and compliance
Which specifications Cardinal implements, what has been tested, and the claims it deliberately does not make.
Vendors in this space claim compliance with things software cannot be compliant with. This page is the opposite: what is implemented, what was tested by somebody other than the project, and what is not claimed and why.
Where it is built
Cardinal is developed in Belgium, in the European Union, by Londer.
That is a statement about where the code is written and who holds the copyright. It is not a statement about where your data lives: Cardinal is software you run, so residency is decided by where you deploy it and by nobody else.
It makes no outbound connection you did not configure
There is no telemetry, no usage reporting, no licence check and no update check. The server has no hardcoded third-party service to call. The only outbound connections it makes are to things you configured: your SMTP relay, the Shared Signals receivers you registered, and the ACME clients that come to it.
The same applies to this website: no analytics, no consent banner, no cookies, and a Content-Security-Policy that permits no request to any other origin.
Specifications implemented
Each of these is in the source, and the RFC number appears next to the code that implements it.
| Area | Specification |
|---|---|
| Authentication | WebAuthn / FIDO2 passkeys, via go-webauthn |
| Single sign-on | OpenID Connect and OAuth 2.0, via zitadel/oidc |
| Token revocation | RFC 7009 |
| Bearer tokens | RFC 6750 |
| Native app flows | RFC 8252 |
| Authentication method reference | RFC 8176 |
| Provisioning | SCIM 2.0: RFC 7643, RFC 7644 |
| Security events | Security Event Tokens, RFC 8417 |
| Event delivery | SSF push (RFC 8935) and poll (RFC 8936), carrying CAEP event types |
| Subject identifiers | RFC 9493 |
| Certificate issuance | ACME, RFC 8555 |
| Authorization policy | Cedar, via cedar-go |
What has been tested by somebody else
The OpenID Foundation conformance suite has been run against Cardinal. It
found two real bugs on its first runs (a discovery document that advertised
the wrong thing, and prompt=login and max_age not being honoured), both
fixed, and both recorded as
ADR 0016
and
ADR 0017.
Two tests end at REVIEW rather than passing outright, because the final step
is a human uploading a screenshot and cannot be automated.
Running the suite is not certification. Certification is a separate, paid process that Cardinal has not been through.
What is not claimed
Not "GDPR compliant". Compliance is a property of an organisation and its
processing, not of a piece of software: no product can confer it on you. What
Cardinal does is make the obligations easier to meet: personal data never enters
the append-only audit journal, so erasure never has to break it
(ADR 0010);
cardinal redact performs an Article 17 erasure that removes the personal
columns, the credentials, the sessions and the account's ability to sign in,
while leaving the shape of history intact; and free-text fields that attract
personal data are enumerated rather than assumed.
Not certified to anything. No ISO 27001, no SOC 2, no FIDO certification, no OpenID certification, no assessment under NIS2 or the Cyber Resilience Act. Some of those apply to organisations rather than products; none of them have been done here.
Not audited. Nobody outside the project has reviewed the cryptography, the session handling or the policy evaluation. This is listed as a requirement before 1.0 and it has not happened.
If any of that changes, this page changes with it. Until then, treating a list of implemented RFCs as evidence of security would be a mistake: it says the protocols are the right ones, not that they were implemented without error.