Security & data protection for IT teams

This page is for the people who have to sign off on CalDAVconnect: IT administrators, security teams and data protection officers. It describes what the service stores, how that data is protected, and what it does not do. The legal documents - Privacy Policy, Terms of Service and Data Processing Agreement (Art. 28 GDPR) - are available in English and German.

In one paragraph: CalDAVconnect synchronises calendars between a CalDAV server and Google Calendar or Microsoft 365. It stores the credentials needed to reach both sides and, for every synced event, an encrypted copy of its last known state so that changes and conflicts can be detected. Everything sensitive is encrypted with AES-256-GCM using keys that are kept on a separate server. The service is hosted exclusively at Hetzner in Germany. Your calendars remain the system of record - CalDAVconnect holds a mapping, not the original data.

What is stored - and what is not

For each user account: name, e-mail address and a bcrypt-hashed password. Two-factor authentication (TOTP) is available.

For each connection:

The CalDAV server URL, username and password (encrypted). We recommend an app-specific password where your server supports it.
For Google or Microsoft: the OAuth access and refresh tokens (encrypted) and the e-mail address of the connected account.
The list of calendars on both sides, with their names, URLs or IDs and change tokens.

For each synced event:

The identifiers of the event on both sides (CalDAV UID and URL, Google or Microsoft event ID).
An encrypted copy of the event's last synced state - title, times, description, location, attendees - the shadow. It is what makes bidirectional change detection and three-way conflict resolution possible.
A SHA-256 hash of the cleaned event data for fast change detection. The hash is not reversible and contains no plaintext.

A sync log records the action (created, updated, deleted), the direction and technical identifiers, with a timestamp.

Not stored, not accessed: e-mail, contacts, files, or any calendar that has not been paired. There is no analytics on event content. Event data is processed only to write it to the other side of a pair.

Encryption

In transit. All connections use TLS: the web application, the CalDAV server, the Google and Microsoft APIs. Certificate verification is on by default; it can be disabled per connection only for self-signed certificates on private servers such as a NAS.

At rest. CalDAV passwords, OAuth tokens and the event shadows are encrypted with AES-256-GCM. The key is separate from the framework's application key, so a compromise of session or cookie encryption does not expose credentials.

Key management. The data encryption key itself is stored only in wrapped form: it is encrypted with a key encryption key that lives on a separate server in a private network, reachable only from the application server. The application fetches it at start-up and keeps it in memory. A copy of the database - or of a backup - is useless without access to that second system.

Access to your calendars

CalDAVconnect asks for the minimum scopes needed to read and write calendar events.

Google Calendar: https://www.googleapis.com/auth/calendar (read and write calendars) plus openid email, used only to show which account is connected. No Gmail, Drive or contacts scopes.

Microsoft 365 / Outlook.com: Calendars.ReadWrite, User.Read (display name and address of the connected account), MailboxSettings.Read (the mailbox time zone, needed to write recurring events correctly) and offline_access (refresh token). No mail, files or contacts scopes.

CalDAV: your credentials are used only for the calendar collections you pair. The client validates redirect targets and refuses to connect to private network addresses.

Push notifications from Google and Microsoft are verified with a secret token per channel. The notifications themselves carry no event content - they only signal that something changed; the data is then fetched through the API.

Privacy modes limit what leaves the source calendar. Per pair you can choose to sync full details, to replace the title with "Busy" (or a label of your choice) while keeping the organiser visible, or Strict: free/busy blocks only, no title, no details, no organiser. For sensitive calendars the cloud side then never sees more than the time slot.

Signing in: single sign-on and two-factor authentication

Single sign-on (OpenID Connect 1.0). Users can sign in with their Google Workspace account. CalDAVconnect matches the account by the e-mail address the identity provider has verified, pins it to the provider's subject identifier so a later e-mail change cannot be used to take over an account, and provisions accounts that do not exist yet on first sign-in - after they have accepted the terms. For SSO users, multi-factor authentication is enforced by your identity provider, not by CalDAVconnect; the local second factor is not asked for. CalDAVconnect requests only the openid email profile scopes for sign-in; this is separate from the calendar authorisation described above. SAML 2.0 is not supported. Organisations can restrict sign-in and provisioning to their own domains (the Google Workspace hd claim is checked, not only the e-mail address) and require single sign-on, which refuses password login and password resets for their members - see Teams below.

Password login. Passwords have at least 12 characters and are checked against known data breaches when they are set (Have I Been Pwned, k-anonymity: only the first five characters of the SHA-1 hash leave the server, never the password itself). They are stored as bcrypt hashes. Login is rate-limited per account and per IP address, and an optional second factor (TOTP, with recovery codes) can be enabled by every user. Sessions are cookie-based, Secure, HttpOnly and SameSite=Lax.

Teams: members, roles and automated provisioning

Organisation and roles. Every account belongs to an organisation with one owner (the billing contact, who cannot be removed or demoted), admins and members. Owners and admins see all members with their sign-in method, last login and the health of their connections, change roles, and remove members centrally. Removing a member deprovisions the account: its connections stop, cloud webhooks are unregistered, OAuth tokens are revoked and the stored credentials are erased. Members only see and manage their own connections; every access to a connection is checked by an authorisation policy on the server, not only hidden in the interface.

Invitation links. Admins create invitation links (open links with a maximum number of uses, or personal links bound to one address), each with an expiry date. Only a hash of the link token is stored. Whoever opens a link signs in with their organisation's Google account and lands in the organisation directly; an account of its own is never created for members.

Login domains and enforced SSO. An organisation can list its login domains. Then only identities of these domains may join or sign in, password sign-up with such an address is redirected to the invitation link, and with require single sign-on password login and password resets are refused for all members. Leavers lose access through your identity provider; removing them in CalDAVconnect additionally erases their data.

Guided setup. Members of an organisation with a pre-configured calendar server get a two-step setup instead of the wizard: the server is pre-filled, the primary calendars are paired automatically in both directions and the first sync starts right away.

Nextcloud without app passwords. For Nextcloud, the guided setup uses Nextcloud's Login Flow v2: the member signs in to Nextcloud in a new tab (including your SSO, e.g. SURFconext) and Nextcloud issues an app password to CalDAVconnect. Nobody types or copies a password; the app password appears in the member's Nextcloud security settings as "CalDAVconnect" and can be revoked there at any time. The flow is only started against public host names, and login and polling endpoints must be on the same host as the configured server.

Google Workspace without consent screens (domain-wide delegation). Instead of every member authorising CalDAVconnect on Google's consent screen, an organisation can store a Google service account (the key file is stored encrypted with the credential key, like passwords, and never shown again). Your Workspace admin authorises the service account's client ID for the single scope https://www.googleapis.com/auth/calendar in the Admin console. CalDAVconnect then mints a short-lived access token per member, signed with the service account key and limited to that member's calendar; no refresh tokens are stored for these accounts. Members who already connected Google themselves keep their own authorisation. Removing the service account disables the delegation for everyone at once.

Hosting and sub-processors

CalDAVconnect runs at Hetzner Online GmbH, Nuremberg, Germany - the application server and the separate key server. Daily PostgreSQL backups are encrypted with AES-256 on the server before they are transferred to Hetzner Object Storage in Germany, with a 14-day retention. Inside the backup, the sensitive fields remain encrypted as they are in the database; the keys needed for those are not part of any backup.

Sub-processors, as listed in the Data Processing Agreement:

Hetzner Online GmbH (Germany) - hosting and infrastructure.
Lettermint (Netherlands, EU) - transactional e-mail such as registration and invitations.
Plausible Analytics (EU) - cookieless website analytics on the public pages only, no personal data.
ntfy.sh (Germany) - operational alerts to the operator; the messages contain no personal data.
Google LLC and Microsoft Corporation (USA, standard contractual clauses) - only when you connect a Google or Microsoft account, and only via their calendar APIs.

Changes to this list are announced at least 30 days in advance.

Operations, access control and availability

Administrative access to production is limited to the operator and runs exclusively over a VPN with SSH key authentication; the cloud firewall allows no public SSH access. The operator deploys releases over that VPN; no external deployment or server-management service has access to the servers. The key server accepts requests only from the application server; every request to it is logged.

Monitoring covers errors, queue health and push-notification channels in real time, and users are informed by e-mail when a connection repeatedly fails or needs re-authorisation.

Patch management. CalDAVconnect monitors its dependencies for published vulnerabilities automatically (GitHub Dependabot alerts and security-update pull requests, plus a daily composer audit / npm audit run that alerts the operator on high or critical findings) and installs operating-system security updates daily via Ubuntu unattended-upgrades on both the application and the key server. Vulnerabilities are assessed within one working day and fixed within 48 hours (critical or directly exposed), 7 days (high) or in the monthly update cycle (medium/low, at most 30 days). Security patches are kept minimal (affected packages only), pass the full automated test suite (~1,670 tests) and are deployed without a maintenance window through an atomic release switch. Kernel and libc updates are activated by a reboot no later than 14 days after they become available; a weekly check alerts on pending reboots. Exceptions are documented with reason, compensating control and target date. Last full review of the dependency baseline: 15 September 2026, zero open advisories. The written policy is available on request.

Incident response. Incidents are detected through real-time push alerts (SSH logins, critical application errors, queue health, key-server authentication failures), application monitoring, dependency vulnerability alerts and customer reports. Every incident is recorded in an internal register with detection time, severity (S1–S4), scope, root cause, remediation and who was informed. Containment options include pausing individual connections, rolling back a release, revoking OAuth tokens, rotating the key-server token (which immediately stops all decryption) and isolating servers. Affected customers are informed by e-mail; a personal data breach is reported to the customer without undue delay and within 72 hours of becoming aware, with the content required by Art. 33(3) GDPR, and to the competent supervisory authority where CalDAVconnect is the controller. S1/S2 incidents receive a written post-mortem within 7 days. The procedure is available on request.

Availability, stated plainly: CalDAVconnect runs on a single application server with daily backups; there is no hot standby. What makes this manageable is that CalDAVconnect is not a system of record. Your events live in your CalDAV server and in Google or Microsoft. If the service is unavailable, synchronisation pauses and, once it is back, catches up incrementally using change tokens - nothing is lost and nothing has to be redone.

Deleting data

Deleting a connection stops the push-notification channels at Google or Microsoft and removes its credentials, tokens, calendar list, event mappings, shadows and sync log immediately.
Deleting an account removes everything above for all connections, plus the user and organisation records. Invitation records are anonymised.
Backups expire after 14 days.
Tokens at the provider: deleted tokens can no longer be used by CalDAVconnect. As belt and braces, you can also revoke the app's access in your Google account or Microsoft account.
Exit and export: because your calendars are the system of record, leaving requires no data migration - the calendars remain complete on both sides and synchronisation simply stops. On request we provide a machine-readable JSON export of your organisation's configuration and sync history (users and roles, connections, calendar lists, calendar pairs and their settings, event mappings, sync log) before deletion. The export deliberately contains no credentials, tokens or encrypted event copies.

Questions

Security questionnaires, vendor assessments or specific questions from your data protection officer: write to support@caldavconnect.de. You will get a reply from the person who runs the system.