cra-assistent

← Curriculum /E-services and digital channels /Level 1

Account security and verifying who you are speaking to

Draft — unverified

Work through these first

This is the one topic in the line where the cost of getting it wrong is not inconvenience. Everything else here is about helping someone reach their information; this is about not handing it to someone else. Two mechanisms do that work: verification, which establishes who is on the call before anything is disclosed, and multi-factor authentication, which does the equivalent job online. Both are routinely experienced as friction by legitimate callers, and both exist because the alternative has victims. An agent who understands what each step is testing can hold the line without sounding obstructive — and, more importantly, can recognise the small number of calls where the person on the phone should not be given anything at all.

How to work through this tutorial

This runs from the principle to the specific situations: 1. Establish the rule: verify before disclosing, every time. 2. Learn what verification is actually testing, and why it cannot be waived. 3. Learn how multi-factor authentication protects the online channel. 4. Understand verifying a representative — identity and authority are two checks. 5. Learn the signs that a call should not be answered normally. 6. Work through an example of a sympathetic caller who cannot be helped. 7. Check your work against the common errors. 8. Verify every specific against CRA's published guidance before relying on it.

The rule, and why it has no exceptions

Nothing about a taxpayer's account is disclosed until the person asking has been confirmed as entitled to it. Not a balance, not whether a return was received, not whether a benefit was paid, not whether an account exists. That last one surprises people. Confirming that a person is a CRA client, or that a particular SIN is associated with a name, is itself a disclosure. "I can't find anyone by that name" and "yes, I have them here" are both answers to a question that should not have been answered. The rule has no exceptions because exceptions are exactly what a social-engineering attempt is designed to produce. A caller who is distressed, in a hurry, calling about a sick relative, or claiming to be a professional, is presenting a reason to skip a step. Every one of those framings is also what a genuine caller sounds like, which is precisely why the step cannot turn on how the call feels.

What verification tests

Verification asks for information that the taxpayer holds and an impersonator generally does not — identifying details together with something drawn from CRA's own records about them. The design principle is worth understanding rather than memorising: publicly discoverable facts are weak, and things that require access to the taxpayer's own documents or CRA's records are strong. A name and address are weak. An amount from an assessed return is strong. Two consequences follow. First, an agent must never supply, hint at, or confirm any part of the answer — reading half the figure and asking the caller to confirm the rest converts a test into a giveaway. Second, a caller who fails verification has not been accused of anything. They have failed a test that honest people fail regularly, for the same reason honest people fail registration: CRA's records may be stale, or they may simply not have their papers. Say what they can do next, and do not disclose in the meantime.

Multi-factor authentication online

The online equivalent of verification is multi-factor authentication: after the password, a second proof that the person holds something the account owner holds. CRA has used more than one form of second factor, including a one-time passcode sent to a registered telephone number and a passcode generated by an authenticator application. The forms available change; the principle does not. The practical points for a call are these. A person who has lost access to their second factor cannot simply be waved through — that would recreate the hole the second factor exists to close. A person who receives a passcode they did not request has just been told that someone else has their password, and that is an urgent signal, not a nuisance. And a passcode is never to be requested, repeated or collected by an agent; anyone asking a taxpayer to read out a code is, by that fact alone, doing something CRA does not do.

Representatives: two separate checks

When the caller is not the taxpayer, there are two questions, and passing one does not answer the other. **Identity**: is this person who they say they are? This is the same test as for a taxpayer, applied to the representative. **Authority**: has the taxpayer authorised this person, for this account, at a level that covers what is being asked? Authorisation carries a scope. A representative may be entitled to view information and not to change it, or entitled on one program account and not another. Both checks apply every time. An authorisation on file does not remove the identity check, and a confidently identified accountant with no authorisation gets nothing. The failure mode to watch for is the representative who is well known, plainly professional, obviously legitimate — and not authorised on this particular account. The rules in Foundations govern here; the portal only reflects them.

When the call should not proceed normally

A few patterns should change how a call is handled rather than merely slowing it down. A caller who cannot answer basic verification but presses for small confirmations — just whether the account exists, just whether a payment went out — is describing the shape of an attempt. A taxpayer reporting that their information has changed without their doing it, that they received a passcode they did not request, or that they have been locked out of an account they never touched, is reporting a possible compromise. That is a different call, handled through CRA's process for suspected unauthorised access, and it is covered in the level 3 tutorial in this line. A taxpayer describing contact they received that demanded immediate payment, threatened arrest, or asked for payment in an unusual form is describing a scam, not CRA. Knowing how CRA does and does not make contact is part of this topic, and it is worth being able to state plainly.

A worked example: sympathetic, genuine, and still refused

Teaching example. The figures below are invented to show the method. They are not CRA figures, and no amount here should be used for a real taxpayer.

The details in this example are invented for teaching. Nothing here should be quoted as CRA's position or as a script. Joanne calls about her father, Gerald, who is in hospital. She is worried his benefit payment has not arrived and he cannot manage the call himself. She has his SIN, his date of birth and his address, and she is plainly sincere. She cannot be given anything. Not whether the payment issued, not whether Gerald has an account, not whether the SIN she has read out matches the name she has given. Everything Joanne has supplied is discoverable by anyone with access to Gerald's mail. None of it establishes that Gerald has authorised her, and authority is the missing piece — not sincerity, which cannot be tested, and not identity, which she may well have. What an agent can do is explain the routes: how Gerald can authorise her, that authorisation can be arranged even in his circumstances, and where the relevant guidance is. That is a genuinely helpful call in which nothing was disclosed. The reason to rehearse this case is that it is the one where the rule feels worst to apply. If the rule only held when the caller seemed suspicious, it would protect nobody — because a competent impersonator will not seem suspicious. It holds because it holds for Joanne.

Common errors

Confirming that an account exists, or that a name matches a SIN, before verification. That is already a disclosure. Supplying part of a verification answer for the caller to confirm. Relaxing a step because the caller is distressed, professional, or in a hurry. Those are the conditions the rule exists for. Treating a failed verification as an accusation. Honest callers fail regularly. Asking a taxpayer to read out a one-time passcode. CRA does not do this, and asking teaches them it is normal. Checking a representative's authority and skipping their identity, or the reverse. Both, every time. Assuming an authorisation covers everything. Authority has a scope and a level. Treating an unrequested passcode as a glitch. It means someone else has the password. Quoting the available second-factor methods from memory. They change. Describing what CRA "would never do" without checking. The published guidance on recognising genuine CRA contact is specific, and it is the thing to quote.

What to verify this tutorial against

This was drafted without a source document. The principles here are stable but the mechanisms change, and the procedural detail an agent actually follows is set by CRA's own operational guidance rather than by any public page. CRA's pages on multi-factor authentication set out the second-factor options currently offered and how a person who has lost access recovers. CRA's guidance on protecting against and reporting suspected unauthorised access to an account is the reference for the compromise signals in this tutorial. CRA's published guidance on how to recognise genuine CRA contact — what CRA will and will not ask for, and how it makes contact — is what to quote to a taxpayer describing a suspicious approach. Quote it rather than paraphrasing. CRA's pages on authorising a representative set out the levels of access an authorisation can carry, which is what makes authority a separate question from identity. The Privacy Act and CRA's confidentiality obligations under the Income Tax Act are the legal basis for the disclosure rule. Confirm which provision governs before citing one. Note for the reviewer: the verification questions an agent actually asks are operational, not public, so this tutorial deliberately describes what verification tests rather than listing questions. Keep it that way — DEC-001 limits this platform to public sources.

Your progress

This is your own record of what you have worked through. It says nothing about whether the content has been verified.

Quiz not attempted. 6 questions available — marking this complete does not require taking it, but the quiz is the only thing here that distinguishes having read the page from having learned it. Take the quiz

Claims to confirm

These are the checkable specifics from this tutorial — the details most likely to be wrong in a drafted page. Confirm each against CRA guidance. 0 of 12 confirmed.

Verify this tutorial

12 claim(s) still unconfirmed. Confirm them above first — verifying the page while its specifics are outstanding would defeat the purpose of listing them.