IMMICASEMulti-factor authentication is being made mandatory for GCKey, affecting a reported 1.2 million+ active files. On paper this is a routine security upgrade. In a working immigration practice it is an operational change, because it quietly converts a habit most firms rely on — a shared login that whoever is at the desk can use — into something that no longer functions.
Why this hits immigration practices harder than most
A typical consultant does not manage one account. Depending on how the practice is set up, there may be a representative account, an authorized-representative portal login, accounts created on behalf of clients during intake, and legacy credentials for programs that have not migrated yet. Add a phone-based second factor to each and the arithmetic gets uncomfortable fast.
The failure mode is predictable: the code goes to a phone that belongs to one person, that person is in a hearing, on leave, or no longer with the firm, and a filing that had a deadline does not happen.
The rule that fixes most of this
One person, one identity, always. It sounds obvious and it is the thing most small practices have not done, because a shared login was faster in the years when nothing forced the issue. Two-factor authentication forces the issue.
- Never share credentials across staff. Beyond the operational breakage, a shared login destroys attribution: you cannot tell a regulator, an insurer, or a client who did what.
- Never use a personal device as the only factor. If the second factor lives on one phone, the firm's access to IRCC lives on one phone.
- Never let a departing employee's device remain the recovery path. Offboarding must include the second factor, not just the password.
A workable account structure
| Account type | Who holds it | Second factor |
|---|---|---|
| Representative account | The named representative personally | Their own device, with a documented backup method |
| Staff portal access | Each consultant or coordinator individually | Their own device |
| Client-owned accounts | The client — always | The client's device |
| Firm-level administrative access | Owner or practice manager, with a named deputy | Two enrolled devices, both documented |
The client row deserves emphasis. Where a client holds their own IRCC account, the credentials and the second factor stay with them. Taking custody of a client's login is a professional and privacy risk that is not worth the convenience, and it becomes actively unworkable once every sign-in needs their phone anyway.
Build a recovery plan before you need one
Recovery is where firms discover their structure was theoretical. Work through these four questions and write down the answers:
- Which accounts exist and who owns each one? Not “the office” — a person, by name.
- What device receives the second factor for each? Including the model and who physically carries it.
- Where are recovery codes stored? A firm password manager with per-person access, not a sticky note or a shared spreadsheet.
- Who is the documented backup for each account, and have they tested access? Untested recovery is not recovery.
Then test it. Pick an account, have the backup person get in, and time it. If it takes more than a few minutes or requires a phone call to someone on vacation, you have found the gap that will cost you a deadline.
Offboarding checklist
The day someone leaves the firm, the following should already be routine rather than improvised:
- Their case management access is deactivated, not shared onward
- Their enrolled device is removed as a second factor from every account it covers
- Any account where they were the sole owner is transitioned to a named successor
- Recovery codes for anything they held are regenerated
- Their files are reassigned inside your system, with the reassignment recorded in the audit trail
What this has to do with your case management software
Mandatory 2FA at IRCC is a good moment to fix the same problem on your own side. If your practice management tool also runs on a shared login, you have the identical attribution gap — and unlike IRCC, nobody is going to force you to fix it.
Immicase gives every team member their own account across five roles — Owner, Admin, Consultant, Assistant/Coordinator, and Auditor — with eighteen granular permissions, so an assistant can upload documents without seeing billing and an auditor can read the record without changing it. Every action is written to an immutable audit trail attributed to a person.
Per-person access, not a shared password
Five roles, eighteen granular permissions, and an immutable audit trail that attributes every action to a named person — so offboarding is a checkbox, not an archaeology project.