Cookie Policy
This document has not been reviewed by a lawyer. Questions? Email [email protected].
Last updated: 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. Three other companies set cookies we do not control - Stripe inside the billing screens, Cloudflare in front of the site, and Google if you sign in with a Google account or connect your calendar - and section 3 covers all three. 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 seven cookies, and each one is doing a job you asked for: keeping you signed in, getting you through sign-in, remembering your language, showing you the way back to your own dashboard, 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.
- Three other companies set cookies of their own: Stripe, only inside the billing screens when you pay or change a card, Cloudflare, which sits in front of our site to keep it online and runs a security check on every page, and Google, on Google's own permission screen if you sign in with a Google account or connect your calendar - under Google's policy, not ours.
- We put nothing on your device that describes you or follows you - no profile, nothing kept behind your back. Apart from the cookies above, the sign-in code we run in your browser may leave one small note in your browser's own storage, so that signing out in one tab signs you out in the others and a change to your account details is picked up by them too; it holds no personal details. The only other things on your device are what Stripe, Cloudflare and Google set, and section 3 covers all three.
- 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. | One year, from the moment you pick a language yourself - with the language switcher, or by closing the note offering you the other one |
__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 |
sg_signed_in | Lets the page you are reading tell whether you are signed in, so the menu offers you your dashboard instead of the sign-in screen. It holds nothing but the digit 1 - no name, no email address, no account number. It is deliberately readable by the page, which is the whole reason it exists, and it opens nothing: it is not a key to your account, and every screen that shows your data checks the sign-in cookie above instead. | Seven days from your last visit, or until you sign out |
__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. The other two - sg_lang and sg_signed_in - are deliberately readable by the page, because being read is exactly what they are for: one decides which language you see, the other which link the menu shows you. Neither holds anything that identifies you, and neither opens an account.
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, the sixth remembers the language you are reading, and the seventh lets the page put the right link in the menu - your dashboard when you are signed in, the sign-in screen when you are not. The sign-in note described in the summary above sits under the same heading: it exists so that signing out actually signs you out everywhere you are signed in, and so that your other tabs keep in step with the account you are signed in to - both part of the sign-in you asked for. The Cloudflare security check in section 3 sits there too: 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.
- Deleting the signed-in marker costs nothing at all - the menu simply offers you the sign-in screen, and clicking it takes you straight through to your dashboard if you are still signed in.
- Blocking third-party cookies only leaves all seven 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].