Control mapping
Tessera is not certified against ISO/IEC 27001 or SOC 2, and running it does not make your organisation compliant. Compliance is a property of your organisation, tested against your scope.
What a tool can do is produce the artefacts an auditor tests a handful of access controls against. This page says which ones, what to export for each, and — in the last section — what Tessera does not answer, so that nobody discovers it during fieldwork.
Access control
Section titled “Access control”| Control | What Tessera does | What to export |
|---|---|---|
| A.5.15 Access control CC6.1, CC6.3 | Access is granted per person against a target, project, group or target kind, in read-write, read-only or view-only mode. Nobody receives the credential itself: it is injected at connect time. | Access → Access review (CSV): every effective access, resolved per person and per target. |
| A.5.18 Access rights CC6.2 | Grants are added and removed in one place, and just-in-time grants expire on their own. Producing the review is itself recorded, which is what shows the review happened at intervals. | The same export, plus the access.grant, access.revoke and access.approved entries for the period under review. |
| A.8.2 Privileged access rights | Management authority is four separate permissions rather than one administrator flag, and a delegate can neither grant nor take over authority it does not hold itself. | Table 2 of the access review: every account holding authority over Tessera itself. |
| A.5.3 Segregation of duties | Reading the audit log is its own permission, so an auditor can read the record without being able to grant access, and whoever grants access cannot quietly read the record of it. | Table 2 of the access review. See Administrators. |
| A.5.17 Authentication information CC6.1 | Session lifetime is configuration, not a constant: twelve hours by default, thirty days with “remember me”, and an optional idle timeout. Any session can be ended at once — changing or resetting a password invalidates every token that account holds. | TESSERA_LOGIN_TTL, TESSERA_REMEMBER_TTL, TESSERA_IDLE_TIMEOUT in Configuration. |
| A.5.16 Identity management A.5.17 Authentication information | Accounts arrive from your IdP through OIDC or SCIM, and password sign-in can be switched off entirely once SSO is configured. Stored target credentials are encrypted and never shown to anyone. | OIDC, SCIM, and the auth methods setting. |
Logging and monitoring
Section titled “Logging and monitoring”| Control | What Tessera does | What to export |
|---|---|---|
| A.8.15 Logging CC7.2 | Every sign-in, grant, session, command and refusal is recorded with severity, outcome, subsystem and source address. Entries are sealed into a hash chain and, with a signing key configured, signed. | Audit → Export (CSV) for the period, and Verify integrity for the chain’s state. See Audit log. |
| A.8.16 Monitoring activities | The chain verifies itself once a day and reports through Prometheus. The alert rules worth having are written out rather than left to be invented. Separately, a short list of security events is announced into a chat as it happens, so that detection does not depend on somebody opening a dashboard. | The chain.verified and chain.problem entries, the alert rules, and the alert list. |
| A.8.17 Clock synchronisation | Entries are timestamped by the database, and the requirement that the host runs NTP is stated rather than assumed: a log from a machine whose clock drifted is a guess. | See Configuration. |
| CC7.3 Evaluating security events | Audit events stream to your SIEM as they happen, carrying the fields a pipeline filters on, each with a sequence number so a gap is visible. The events that need a person rather than a pipeline, a run of failed sign-ins, authority being granted, a policy or an audit setting being changed, a failed chain verification, are sent to a chat as well. | SIEM export and Notifications. |
Cryptography and records
Section titled “Cryptography and records”| Control | What Tessera does | What to export |
|---|---|---|
| A.8.24 Use of cryptography | Stored credentials are encrypted with AES-256-GCM, and the key can be rotated with the controller stopped, in one transaction that verifies every secret before it commits. | The procedure in Backups & upgrades. |
| A.8.10 Information deletion A.5.33 Protection of records | Retention windows are configured for the audit log and for session replays and enforced by a daily job. Every purge records the range it removed, so deletion is itself evidenced. | TESSERA_AUDIT_RETENTION_DAYS, TESSERA_RECORDING_RETENTION_DAYS, and the chain.pruned entries. |
| CC7.1 | Session recording captures the full terminal stream for replay, switched on per target. | Audit → Sessions, with playback. |
What Tessera does not answer
Section titled “What Tessera does not answer”An auditor will ask about these too, and Tessera is not the thing that answers them. Better to know now than during fieldwork.
- Multi-factor authentication. There is no second factor in the controller itself. The supported answer is your IdP: configure OIDC and switch password sign-in off, and MFA is enforced where your organisation already manages it, along with device policy and recovery. On an installation with no IdP, sign-in is a password.
- Password policy. Beyond a minimum length there are no complexity or history rules. Again, that belongs to the IdP.
- Step-up authentication. There is no re-prompt before a privileged action such as editing a grant, a credential or a policy. A session that is already open can do everything its holder may do.
- Rotating the credentials Tessera stores. The encryption key can be rotated; the target passwords and keys it protects are rotated wherever you manage them, not here.
- Self-approval of a just-in-time request is not prevented in code. If your policy requires four eyes, it is enforced by who holds the approval permission.
- Session replays carry no signature. The audit entries about a session are covered by the chain; the replay file itself is a file on disk.
- Availability. There is no stated RTO or RPO, and the Kubernetes chart runs a single replica.
- The vendor. Tessera holds no ISO 27001 certificate and no SOC 2 report, so a supplier review under A.5.19–A.5.22 has nothing from us to test. Self-hosting changes the shape of that question, because session content, credentials and the audit log never reach us, but it does not remove it.
Related
Section titled “Related”- Audit log — what the chain covers, and the four things it does not.
- Administrators — the delegated roles and the rules between them.
- Access control — granting, revoking, and the access review export.
We would like to count visits with Google Analytics, which needs a cookie. Nothing is loaded and nothing is stored unless you accept. What this sets.