> For the complete documentation index, see [llms.txt](https://docs.nfh.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nfh.global/product-documentation/products/vc-on-edge/security.md).

# Security model

The security guarantees OpenCred makes — and their boundaries. Start here before adopting it in production.

If you operate OpenCred in production, or you're auditing it before adoption, start here.

## The single most important rule

> **OpenCred never receives, handles, or stores issuer private keys.**

All signing happens **locally** — on the issuer's Desktop machine, or inside the issuer-operated Docker container. There is no code path — no endpoint, no function, no IPC handler — that accepts an issuer's private key as input. There is no hosted OpenCred service; NFH Trust Labs operates no servers that touch issuer credentials. This rule underpins the entire model.

## At a glance

| Area                 | Guarantee                                                                                                            |
| -------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Issuer keys          | Never received by OpenCred. Loaded locally, held in memory as opaque `KeyObject` instances.                          |
| Key generation       | Always CSPRNG (`crypto.generateKeyPairSync`, `crypto.randomBytes`). `Math.random()` is forbidden.                    |
| Logging              | Key material is stripped by a redaction hook before any log record reaches disk.                                     |
| Error responses      | Use the `OpenCredError` hierarchy — sanitised by design; no internal paths or buffers leak.                          |
| Session data         | Credential payloads, packaged outputs, and batch results are purged within `OPENCRED_SESSION_TTL` (default 4 hours). |
| JSON-LD contexts     | Bundled at build time; never fetched from the network at runtime.                                                    |
| `did:web` resolution | HTTPS only, no redirects, 10-second timeout, DNS-resolved IPs validated as public before fetch (SSRF protection).    |

## The seven invariants

OpenCred's behaviour is governed by seven mandatory invariants, enforced in code (not just documented). The first is the never-touch-issuer-keys rule above; the rest cover CSPRNG-only key generation, log redaction, sanitised errors, session-data expiry, build-time context bundling, and hardened `did:web` resolution. Each invariant names the place it is enforced.

## Deployment hardening

The Docker image follows these invariants by default — non-root user, pinned base digests, no secrets in image layers, read-only filesystem and dropped capabilities in the shipped Compose file, and structured logging with key material redacted. See [Docker → Security defaults](/product-documentation/products/vc-on-edge/docker.md#security-defaults).

## Reporting a vulnerability

**Do not** open a public GitHub issue for a security problem. Use GitHub's private security-advisory flow on the [opencred-releases](https://github.com/nfh-trust-labs/opencred-releases) repository, or the security contact listed in the project's `SECURITY.md` / README.

***

**Related:** [Concepts → Trust chains](/product-documentation/products/vc-on-edge/concepts.md#trust-chains) · [Concepts → DIDs](/product-documentation/products/vc-on-edge/concepts.md#dids-decentralized-identifiers) · [Docker → API](/product-documentation/products/vc-on-edge/docker.md#http-api) · [NFH fabric → Credentialling Edge](/product-documentation/products/vc-on-edge.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.nfh.global/product-documentation/products/vc-on-edge/security.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.