Canadian privacy law got teeth. Quebec’s Law 25 finished phasing in with real penalties, PIPEDA still governs everything federally, and suddenly the question “where exactly does our user data live” stopped being a footnote in the security questionnaire and became the thing that stalls the deal.
If you run Keycloak, most of what these laws ask for is already in the product. You just have to know which switches matter.
What do Quebec Law 25 and PIPEDA require from an identity system?
Both laws require you to know what personal information you hold, keep it only as long as you need it, delete it on request, report breaches, and be able to hand a person their own data. Law 25 adds explicit consent rules, mandatory privacy impact assessments before moving personal information outside Quebec, and a right to data portability. For an identity provider like Keycloak, that translates into retention limits, audit logging, deletion workflows, export capability, and a clear answer about where the database physically sits.
Key Takeaways
- Law 25 and PIPEDA are mostly about process and provability, not exotic technology. Keycloak covers the technical side already.
- The hardest requirement is not deletion, it is knowing where your data lives and being able to prove it. That is an infrastructure decision, not a Keycloak setting.
- Law 25 requires a privacy impact assessment before transferring personal information outside Quebec, which is what makes US-hosted identity providers awkward for Quebec organizations.
- Keycloak’s event logging is off by default. If you have not enabled it, you cannot demonstrate anything.
A note on what this article is: it is a practical engineering guide written by people who run Keycloak for a living. It is not legal advice, and Law 25 in particular has nuances that depend on your sector and how you collect consent. Talk to a privacy lawyer about your obligations. Come back here for how to implement them.
Where does your identity data actually live?
Start here, because everything else is downstream of it.
Law 25 does not ban sending personal information outside Quebec. It requires you to conduct a privacy impact assessment first, and to confirm the receiving jurisdiction provides adequate protection.
Read that carefully: the trigger is communication outside Quebec, not outside Canada. Hosting in Toronto still triggers the assessment. It is usually trivial to satisfy for another Canadian province, but it is triggered, and teams routinely miss this because they assume “in Canada” is the finish line.
This is where the identity layer gets awkward. If your authentication runs on a US-headquartered SaaS, your user table, your session data, your audit log and your password hashes are all subject to that provider’s jurisdiction, regardless of which region you picked in their console. Self-hosted or Canadian-hosted Keycloak removes that entire conversation.
For a broader look at the trade-offs between running it yourself and having someone run it for you, see our guide on whether self-hosting Keycloak is worth it and the comparison of managed Keycloak providers.
Practical checklist:
- Know the physical region of your Keycloak database, not just the application.
- Know where backups go. Backups crossing a border is the detail that gets missed most often.
- Know where your logs go. Shipping audit events to a US observability vendor re-exports the data you just localized.
- Write it down. Both laws reward organizations that can show their work.
How do you handle deletion and retention in Keycloak?
Keycloak deletes users cleanly through the Admin REST API, and that is the easy part. Retention is where teams get caught.
User deletion. DELETE /admin/realms/{realm}/users/{id} removes the user, their credentials, their consents and their federated identity links. If you also need the audit trail of that person’s logins gone, that is a separate cleanup, and you should decide deliberately whether it should be, because deleting the evidence that you deleted someone is rarely what auditors want.
Event retention. Keycloak stores login and admin events in the database with a configurable expiry. Set it to something defensible rather than leaving it unbounded:
# Enable event storage and cap LOGIN event retention at 180 days
kcadm.sh update events/config -r myrealm
-s eventsEnabled=true
-s adminEventsEnabled=true
-s adminEventsDetailsEnabled=true
-s 'eventsExpiration=15552000'eventsExpiration is in seconds. 15552000 is 180 days.
Watch this one carefully: eventsExpiration only governs login events. Admin event retention is a separate realm attribute, adminEventsExpiration, and it is not part of the events/config representation. If you never set it, your admin events never expire, which is the opposite of what most retention policies claim. Set it explicitly:
# Admin events expire separately. Set the realm attribute directly.
kcadm.sh update realms/myrealm
-s 'attributes.adminEventsExpiration=31536000'Pick numbers you can justify in a questionnaire, and make sure they match what your privacy policy claims.
Offline sessions and tokens. Offline sessions persist across restarts and can quietly hold identity data far longer than you intended. Review Offline Session Idle and Offline Session Max in realm settings alongside your retention policy.
We covered the deletion mechanics in more depth for GDPR, and the technical requirements overlap almost entirely, in Keycloak GDPR data erasure and retention.
What do you need for the audit trail?
Keycloak’s event logging is disabled by default. This is the single most common gap we see. A realm that has been running for two years with events off cannot demonstrate who accessed what, and no amount of policy documentation fixes that retroactively.
Turn on both event types:
- Login events capture authentication, failures, token grants, and password changes.
- Admin events capture configuration changes, which is what tells you whether someone quietly disabled a security setting.
Enable adminEventsDetailsEnabled too. Without it you know a change happened but not what it changed to, which is close to useless in an investigation.
For anything beyond short-term retention, forward events out of the database to your SIEM. Keycloak’s database is not designed as a long-term log store, and querying two years of login events will hurt. Our documentation covers the event configuration options in detail.
Can you give a user their own data?
Both laws grant a right of access, and Law 25 adds portability, meaning the data has to come back in a structured, commonly used technical format.
Keycloak’s Admin REST API gets you most of the way. GET /admin/realms/{realm}/users/{id} returns the profile, and companion endpoints return group memberships, role mappings, consents and federated identities. The output is JSON, which satisfies “structured and commonly used.”
The gap is usually that nobody has built the workflow. The API exists, but if fulfilling a request means an engineer manually assembling four API calls under a statutory deadline, you do not really have a process. Script it before you need it.
Consent and Keycloak’s client scopes
Law 25 tightened consent significantly: it must be clear, specific, and separate from other terms. Keycloak’s consent screen handles the mechanics for OAuth clients, recording which scopes a user approved and when.
Two things worth knowing:
- Consent is per client, and
Consent Requiredis off by default on new clients. If you rely on Keycloak for the consent record, you have to enable it deliberately. - Revoked consent is recorded, and the user can withdraw it from the account console. That withdrawal path is itself a Law 25 requirement, and getting it for free is one of the better arguments for using a real identity provider rather than rolling your own.
What about breach notification?
Both laws require notifying the regulator and affected individuals, but the thresholds are worded differently and are not interchangeable. PIPEDA uses “real risk of significant harm”. Law 25 uses “risk of serious injury”. Both also require keeping a register of incidents, including the ones you decide are not notifiable, so the record-keeping obligation is not unique to Quebec.
The identity system’s job here is detection and evidence. That means:
- Login event logging on, so you can establish scope and timeline.
- Brute force detection enabled, so credential stuffing is caught and recorded rather than discovered later.
- Admin events on, so you can tell whether an attacker changed configuration.
If you cannot reconstruct what happened, you cannot assess risk, and if you cannot assess risk you end up over-notifying or under-notifying. Both are bad outcomes.
A configuration checklist
Run through this on every realm holding Canadian personal information:
| Setting | Why it matters |
|---|---|
eventsEnabled = true |
Login audit trail. Off by default |
adminEventsEnabled = true |
Configuration change trail |
adminEventsDetailsEnabled = true |
Records what changed, not just that it did |
eventsExpiration set |
Defensible retention, matches your policy |
| Brute force detection on | Breach detection and evidence |
| Offline session limits reviewed | Stops indefinite data retention by accident |
Consent Required per client |
Only if you rely on Keycloak for consent records |
| Database region documented | The question every questionnaire asks |
| Backup region documented | The one teams forget |
| Log destination documented | Do not re-export what you localized |
Talk it through with a Keycloak engineer
If you are working through a Law 25 or PIPEDA review and want a second opinion on your realm configuration, book a call with a Keycloak engineer. Skycloak is a Canadian company and we offer Canadian data residency, so if keeping identity data in Canada is the requirement driving your project, that conversation is a short one. Either way you will leave with a clearer picture of what your current setup can and cannot demonstrate.
Frequently Asked Questions
Does Quebec Law 25 require data to stay in Quebec?
No. Law 25 requires a privacy impact assessment before transferring personal information outside Quebec, and confirmation that the destination provides adequate protection. Note that the trigger is leaving Quebec, so hosting in another Canadian province still requires the assessment, even though it is usually easy to satisfy.
Is Keycloak compliant with PIPEDA out of the box?
No product is compliant on its own, because compliance depends on how you configure and operate it. Keycloak provides the technical capabilities PIPEDA expects, including deletion, access, audit logging and consent records, but several of them are disabled by default. Event logging in particular has to be turned on.
How long should I keep Keycloak login events?
There is no fixed statutory number. Pick a retention period you can justify against your security needs and state it in your privacy policy, then set eventsExpiration for login events and the adminEventsExpiration realm attribute for admin events. They are separate settings. Many organizations land between 90 and 365 days, and keep admin events longer than login events.
Does using a US cloud region break Law 25?
Not automatically, but it triggers the privacy impact assessment requirement for transfers outside Quebec, and it means your data may be subject to foreign legal process. That is the risk organizations are weighing when they ask for Canadian residency.
Can Keycloak export a user’s data for a portability request?
Yes. The Admin REST API returns the user profile, group memberships, role mappings, consents and federated identity links as JSON, which meets the “structured, commonly used technical format” standard. You will want to script the assembly of those calls into a single export before a request arrives.
The short version
Quebec Law 25 and PIPEDA ask your identity system for five things: know what you hold, keep it only as long as needed, delete it on request, prove what happened, and be clear about where it lives. Keycloak can do all five, but event logging is off by default and retention is unbounded until you set it, so an untouched realm fails the provability test even when the technology is capable.
The part Keycloak cannot solve for you is jurisdiction. That is decided by where you run it, and remember the Law 25 assessment triggers on leaving Quebec, not on leaving Canada. Hosting inside Quebec is the only configuration that avoids the transfer question entirely, and when you evaluate any provider, ask the two questions this article told you to ask: where do the backups go, and where do the logs go.
See managed Keycloak hosting for how we handle residency, or talk to a Keycloak engineer about your specific setup.
Cet article est aussi disponible en francais : Loi 25 et PIPEDA : ce que la conformite exige de votre systeme d’identite.
Sources
- Commission d’acces a l’information du Quebec, Law 25 (Loi 25) guidance, retrieved 2026-08-21, https://www.cai.gouv.qc.ca/
- Office of the Privacy Commissioner of Canada, PIPEDA in brief, retrieved 2026-08-21, https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/
- Keycloak, Server Administration Guide, events configuration, retrieved 2026-08-21, https://www.keycloak.org/docs/latest/server_admin/
