Security
Security settings apply to your whole organization. There is no per-workspace variation: tightening a policy tightens it everywhere, including sandbox.
Two-factor authentication
Two-factor can be required organization-wide. Turning it on affects everyone, including people who are mid-session, so plan the moment rather than discovering it.
Individuals can enrol before it is mandatory. Doing that first, then switching on the requirement, is the sequence that avoids locking your own team out on a Monday morning.
The requirement is part of the sign-in policy, a set of
organization settings you change with
PUT /v1/organization/settings:
| Key | Holds |
|---|---|
security.sign_in.require_mfa | Whether every member must prove a second factor ("true" / "false") |
security.sign_in.allowed_idps | The identity providers members may sign in through; empty allows every one |
security.sign_in.allowed_email_domains | The email domains a member's address may be at; empty allows every one |
security.sign_in.jit_enabled | Whether somebody who signs in through one of your identity providers without an invitation becomes a member |
security.sign_in.jit_default_role | The role such a person receives (no_access by default) |
Require two-factor
These settings live at the organization and cannot be set from a sandbox. The
first three bind organizations below yours: they may make the policy stricter,
never looser. A narrowed allow-list that would leave an organization below
allowing nothing is refused with SETTING_ALLOWS_NOTHING_BELOW unless you send
"confirm_empty_descendants": true.
Sessions
Session policy decides how long somebody stays signed in and when they must re-authenticate. Shorter sessions are safer and more annoying; the right answer depends on whether your team works from shared machines.
What is recorded
Kontier keeps an audit trail of what changed, when, and who did it. It is what answers "why does this invoice say that" months later, and it is the reason a finalised invoice is immutable rather than editable.
Read the audit trail with GET /v1/audit-events (filter by entity, event type,
actor, trigger and time), follow one request, job or webhook through everything
it caused with GET /v1/audit-events/operations/{operation_id}, and read the customer-facing feed
of one customer with GET /v1/customers/{id}/audit-events.
Audit retention is an organization setting, set per retention group in days:
audit.retention.evidence (at least 3650), audit.retention.security (at least
365) and audit.retention.operational (at least 90). 0, the default, keeps
events forever. An organization above yours can set or lock it for you. Set it
with PUT /v1/organization/settings. Previewing what a retention change would
delete, and redacting audit entries, are done in the dashboard; there is no API
for them.
Data export and erasure are operator-assisted
GDPR export and erasure exist, but there is no API or dashboard screen for them. If you need to satisfy a data request, email engineering@kontier.eu.
Practical advice
Three things worth doing before you are busy:
- Enrol in two-factor before requiring it, so the switch is uneventful.
- Give API keys an expiry. A key with no expiry outlives the integration it was made for.
- Use
allowed_ipsfor machine-to-machine keys. A leaked key is useless from an address you did not list.
Reference
| Topic | When you need it |
|---|---|
| Team and roles | Who can do what |
| API keys | Scopes, rotation, IP restrictions |
| Organization settings | Where security settings live |