eudi-dev is a development and testing tool. Never use it with real credentials or real identity data.

• Unencrypted storage: Credentials and private keys are stored without encryption on every backend. File storage uses ~/.eudi-dev/wallet/ by default.
• Seeded keys: Anyone who knows or guesses --seed or EUDI_DEV_SEED can derive the generated keys. The Docker image uses the public seed eudi-dev. Set a different seed, or an empty value for random keys.
• Shared CA: File storage keeps the CA key at ~/.eudi-dev/wallet-ca-key.pem. Postgres keeps it in the shared database. Wallets under the same parent directory share this CA. Anyone who can read the key can issue credentials accepted by verifiers that trust it.
• Open HTTP API: The wallet, decoder and proxy have no authentication. They bind 127.0.0.1 by default. --listen (or EUDI_DEV_LISTEN) opens them to a network, and --docker binds every interface too. Keep them on localhost or an isolated network. The Docker image binds every interface inside the container, so only publish its ports where you want them reachable. For public hosting, use --demo. It disables process and filesystem controls, blocks requests to private networks and resets state periodically. All data and operations that remain are public. See public demo hosting.
• Browser access: Web pages can send requests to localhost. The API rejects requests whose Origin belongs to another site. /api/dc-api is exempt because verifiers call it from their own pages. Protocol endpoints accept browser navigation. Requests without an Origin header (from CLI clients) are accepted.
• Registrar: Anyone with access to the wallet API can register relying parties and get access and registration certificates for them. The relying party access CA signs access certificates. These certificates don't chain to the wallet CA, so they can't pass as credential issuers. The registrar issues access certificates for CSRs and never sees the private key. The demo verifier is an exception. In Own certificates mode the browser sends the key to the demo verifier with each request, because the verifier signs the request. On a --demo instance anyone can register, revoke and delete relying parties. A reset deletes the registrations and their revocations, so a certificate revoked before the reset is valid again afterwards. Under --arf the wallet trusts the relying party access CA for access certificates only, through its access-ca list. Registration certificates and the registrar's status list must chain to a CA on a registrar list. That list holds the separate registrar CA. So an access certificate can't sign a registration certificate. See registrar.
• Added trust: Anyone with access to the wallet API can put a CA on its trusted lists or add an external list. With --arf that CA or list anchors the checks for everyone who uses the wallet. On a --demo instance all visitors share these additions until the next reset.
• Proxy logs: The proxy records complete requests and responses, including tokens and credentials.
• Supported trust mechanisms: The wallet reports unsupported mechanisms (such as DID keys and OpenID Federation client identifiers) and does not resolve them. See ADR-0013.
• Signature checks: Request objects and signed issuer metadata are checked for valid signatures and consistent certificate chains. The wallet has no configured issuer or verifier trust anchors. A party with its own certificate and a matching x509_hash or sub passes these checks. A valid signature does not prove who the signer is. --arf is the exception. It anchors access certificates, registration certificates, the status lists of registration certificates and received credentials to the CAs on the wallet's trusted lists. It anchors fetched trusted lists to the wallet CA and the CAs from --trusted-list-ca (ADR-0021, ADR-0023).
• Outbound HTTPS: Strict mode verifies server certificates, including local endpoints and redirects. Debug mode skips verification by default. --tls-verify=true|false overrides either default for every destination. --tls-ca adds CA certificates to system trust. Credential and request object signatures are checked separately.
• Test key attestations: By default, key attestations claim the storage and authentication levels requested by the issuer, including iso_18045_high. With --arf they claim iso_18045_high when the issuer requests nothing, as CIR (EU) 2024/2979 Annex Ib C_KA-1 does for a WSCD. The wallet does not provide those protections, and neither the wallet nor its key storage is certified. The certification claims of its attestations link here. Use --key-attestation-level none to omit the claims, or set a level to test that level. The activity log records the claims.
• Revocation: The wallet can present revoked credentials. Its status display is for information only. The demo verifier checks status and rejects revoked credentials.

Report security issues at github.com/eudi-dev/eudi-dev/issues.