Cookie Policy (archived 12 August 2026)
This document has not been reviewed by a lawyer. Questions? Email [email protected].
This is an archived version from 12 August 2026, kept for reference. It is not the version that applies now. Read the current version
It was in force from 12 August 2026 until 14 September 2026.
This page lists every cookie SwiftGuard's own website and dashboard ask your browser to keep, what each one is for, and how long it stays. Two other companies set cookies we do not control - Stripe inside the billing screens, and Cloudflare in front of the site - and section 3 covers both. It is the detail behind section 6 of our Privacy Policy.
There are no analytics cookies, no advertising cookies and nothing of ours that tracks you - which is why you are never asked to accept anything. One script on our pages is not ours and does examine your browser: Cloudflare's security check, described in section 3.
In short
- We ourselves set six cookies, and each one is doing a job you asked for: keeping you signed in, getting you through sign-in, remembering your language, or connecting your calendar.
- Nothing follows you. No analytics, no advertising, no tracking pixels, and nothing of ours that fingerprints your browser to build a picture of you. One script does examine your browser: Cloudflare's security check, which tells a real visitor from automated traffic and which we cannot switch off. Section 3 explains it.
- Two other companies set cookies of their own: Stripe, only inside the billing screens when you pay or change a card, and Cloudflare, which sits in front of our site to keep it online and runs a security check on every page.
- We put nothing else on your device ourselves - nothing in your browser's local storage, nothing kept behind your back. The only things there that are not ours are what Stripe and Cloudflare set, and section 3 covers both.
- No cookie banner, because every cookie below is needed to run the service you asked for. European law requires no consent for those, and a consent box we would ignore is worse than none.
- You can delete or block cookies in your browser at any time. Section 5 says exactly what stops working if you do.
- Questions: [email protected].
1. What a cookie is
A cookie is a small file a website asks your browser to keep, and that your browser hands back on your next visit. It is how a site recognises the same browser twice - which is what makes staying signed in possible at all. Cookies can be used to follow people from site to site and build a profile of them. Ours are not, and none of what follows does that.
2. The cookies we set
Every cookie in this table is set by us, on our own address, so your browser does not send it to any other website.
| Cookie | What it is for | How long it lasts |
|---|---|---|
sg_lang | Remembers which language you are reading the site in, so the next page opens in the same one. It holds nothing but a language code, such as en or nl. | Until you close your browser - or one year, if you picked the language yourself with the language switcher |
__Secure-better-auth.session_token | Keeps you signed in to your dashboard. Without it, every page would ask for your password again. It holds no personal details - only a random key that points at your session on our server, which we can end at any time. | Seven days from your last visit, or until you sign out - so it keeps working for as long as you keep coming back |
__Secure-better-auth.two_factor | Carries a half-finished sign-in between the moment you type your password and the moment you type the six-digit code we email you. | Ten minutes |
__Secure-better-auth.trust_device | Set only if you tick "Don't ask for a code on this device again" while signing in. It lets that one browser sign in with your password alone, without the emailed code. It never waives the password, and you can undo it from your account page. | Fourteen days |
__Secure-better-auth.state | Set only while you are signing in with your Google account, and only during those few clicks. It proves the sign-in was finished by the same browser that started it, so nobody can finish it somewhere else. | Five minutes |
gcal_oauth | Set only while you are connecting your Google Calendar, and only during those few clicks. It proves the connection was finished by the same browser that started it, so nobody can attach their calendar to your account. | Ten minutes |
The five sign-in and calendar cookies are HttpOnly: your browser sends them back only to our own site, and no script on the page can read them. On the live site they are also Secure, so they only ever travel over an encrypted connection - and the __Secure- at the front of the four sign-in names is simply how a browser is told to insist on that.
3. Cookies other companies set
Stripe takes the payments and, through Link, is the seller of record for your subscription (section 9 of the Terms of Service). Its cookies appear when you open the billing screens in your dashboard - never on the public website. They are there to run the payment form and to spot card fraud. Stripe may store some of what it sets under our own web address rather than its own; where it does, blocking third-party cookies will not reach those. The payment form itself is Stripe's own page shown inside ours, so whatever it stores while it is open is Stripe's, under Stripe's address - and blocking third-party cookies may stop that form from opening at all. Your card details go straight to Stripe and never reach our servers. What Stripe sets, and for how long, is in Stripe's own cookie notice.
Cloudflare sits in front of swiftguard.ai and blog.swiftguard.ai. It serves the site quickly and absorbs attacks, and to do that it adds a small script of its own to every page you open, which checks whether a request is coming from a real browser or from automated traffic. That check is part of Cloudflare's service rather than something we add on top of it, and on the plan we use it cannot be switched off. It may also set a security cookie of its own. Cloudflare describes these as security cookies, set to keep the site up rather than to advertise to you; what it sets, and for how long, is in its cookie policy.
Google, if you sign in with your Google account or connect your calendar. The permission screen you land on is Google's own website, and Google sets cookies there as it does on any of its pages - under Google's policy, not ours. On our side these are two different steps and each sets one short-lived cookie of ours, both listed in section 2: connecting a calendar sets the ten-minute gcal_oauth cookie, and signing in with Google sets the five-minute __Secure-better-auth.state cookie.
Where the data these three companies handle can end up, and what protects it when it leaves Europe, is in section 8 of our Privacy Policy.
4. Why there is no cookie banner
European law says a website must ask before storing anything on your device unless it is needed to provide the service you asked for. Every cookie in section 2 is exactly that: five of them exist so you can sign in, stay signed in and connect your calendar, and the sixth remembers the language you are reading. The Cloudflare security check in section 3 sits under the same heading: keeping the site reachable, and telling a real visitor from automated traffic, is part of delivering the site you asked for rather than something that measures you or follows you around. There is nothing here to consent to, so we do not put a box in front of you pretending there is.
If that ever changes, we will ask first. The day we add anything that measures, advertises or follows you, consent will be requested before it is set, and this page will be updated to describe it.
5. Turning cookies off, and what it costs you
Every browser can show, delete and block cookies - usually under Settings, then Privacy. You are free to do that at any time, for us or for anyone; we do not read a "do not track" signal or work around a browser setting. What you lose:
- Blocking our sign-in cookie means you cannot use the dashboard. The public website, the pricing page and the blog stay perfectly readable with cookies blocked - the only difference is that the site will not remember your language. Signing in is different: it will simply hand you back to the sign-in screen.
- Blocking the two-factor cookie stops sign-in halfway: your password will be accepted and the six-digit code will then have nothing to attach itself to.
- Deleting the trusted-device cookie costs nothing - your next sign-in emails you a code again, exactly as it would the first time.
- Deleting the language cookie costs nothing either - the site falls back to your browser's own language setting.
- Blocking third-party cookies only leaves all six of ours working, since every one of them is set by our own site, and it will not reach any Stripe cookie kept under our own address. The payment form is a different matter: it is Stripe's own page shown inside ours, so blocking third-party cookies - or blocking scripts from Stripe - may stop it opening. Section 3 explains which is which.
Deleting cookies does not delete anything at our end. To ask what we hold about you, or to have it deleted, see section 9 of the Privacy Policy.
6. Changes and contact
If the cookies we use change, we publish a new version of this page under our usual revision process, and the date at the top tells you which version you are reading. Questions about anything here: [email protected].