This lesson covers the Getting Started module of the ZIMRA Self-Service Portal — the gateway every other lesson in this course passes through. The login flow at https://mytaxselfservice.zimra.co.zw is short: enter username (or registered email) and password, complete browser verification with a code sent to your phone or email where requested, and land on the 16-module welcome dashboard. Around that simple flow sit the mechanics this lesson treats in depth: password reset via the Forgot Password link, account locking after repeated failed attempts, changing a password from inside the portal, maintaining the SSP user profile (username, phone, email — distinct from the taxpayer profile), the automatic inactivity logout, and the deliberate act of shifting from User mode into Taxpayer mode for the taxpayer whose affairs you intend to manage.

The legal frame is access discipline rather than a charging provision. Section 5 of the Income Tax Act [Chapter 23:06] imposes the preservation of secrecy over taxpayer information, with criminal consequences for breach (Section 5(5)/(5a)) — the statutory reason the portal is built on one person, one login, role-based access through Assignee Management, and verification challenges, rather than shared departmental passwords. Access to a taxpayer's affairs by anyone other than the taxpayer is legitimised through the portal's own grants (assignees, tax agents), which later lessons cover; logging in under someone else's credentials short-circuits that legitimisation and destroys the audit trail that protects both the taxpayer and the user.

There is no case law on portal login mechanics — this lesson says so honestly. The practical payload is the procedure, the error states (wrong credentials, locked account, dormant email, expired verification codes), and the security housekeeping ZIMRA itself prescribes: strong rotated passwords, deliberate logout on shared devices, scepticism toward emails claiming to be ZIMRA, and prompt removal of departed staff from assignee lists.

Sourcing note: the SSP online help (https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm) could not be fetched this run; procedure below is grounded in ZIMRA's Comprehensive Guide to the ZIMRA Self-Service Portal (External Guide, compiled from that help). Screen-level specifics are flagged for verification where appropriate.

Every statutory duty this course gives effect to — registration within 30 days (Section 25B), the four-month self-assessment (Section 37A), the monthly P2 and VAT 7 — begins with a successful login. That sounds trivial until the morning of a deadline, when a locked account, a forgotten password tied to an ex-employee's email, or a verification code sent to a dormant phone number stands between the taxpayer and a return that is due that day. Filing deadlines are met by submission, and submission requires access; "I could not log in" is not a statutory defence to late filing.

The previous lesson (Introduction to TaRMS and the SSP) established the foundational distinction between the SSP user (the human with the login) and the taxpayer (the legal person with the TIN), and the two session states — User mode and Taxpayer mode. This lesson operationalises that distinction: how access is actually obtained, kept, recovered and exercised safely. Subsequent lessons assume you can get in; this one makes sure of it.

Login mechanics are portal design, not statute — but the design choices implement statutory duties:

• Section 5, Income Tax Act [Chapter 23:06] — preservation of secrecy. Taxpayer information may be disclosed only through the statutory gateways (e.g. to the Minister under Section 5(3), to the Financial Intelligence Unit under Section 5(3a)); unauthorised disclosure is an offence (Section 5(5)/(5a)). A portal where each human has an individual, verified login and each grant of access to a taxpayer's affairs is recorded (Assignee Management, Tax Agent Assignment) is the system-level expression of this duty. Shared logins create exactly the untraceable access Section 5 is designed to prevent.
• Representation provisions. The Income Tax Act recognises representative taxpayers (Sections 53–56) and the public officer of a company (Section 61) — the named human answerable for the company's tax affairs. In portal terms, the public officer or representative obtains access as a user granted rights over the taxpayer, not by impersonating the taxpayer. Tax agents are accommodated through the portal's agent-assignment machinery (a later lesson).
• Self-assessment integrity. Because a submitted Section 37A return constitutes the assessment (Section 37A(10)–(11)), the question "who submitted this return?" has legal weight. Individual logins give every submission an attributable author; this is protective for the professional as much as for ZIMRA.

Case-law note for this section: none exists on portal access itself; the authorities on representative capacity (Afritrade 21-SC-003 on the public officer's position) sit behind the representation concepts and are treated in the Income Tax Course.

C.1 What you need before first login

1. A completed SSP user registration (Sign Up — covered in the SSP Registration lesson): your identity details verified by ZIMRA and a password-creation link emailed to your registered address.
2. The password you set via that link.
3. Ongoing access to the email address and phone number registered on your user profile — the portal's verification codes go there. This is the single most neglected dependency: registrations done years ago against an address no one reads anymore.

C.2 The standard login procedure

1. Browse to https://mytaxselfservice.zimra.co.zw. Type the address directly or use your own bookmark — never follow a login link from an email (see F below on phishing).
2. Enter your username or registered email and your password; click Log In.
3. Browser verification: where the portal does not recognise the browser/device, it challenges you for a verification code sent to your registered phone or email. Retrieve the code, enter it, click Verify.
4. The welcome page opens, presenting the 16-module dashboard in User mode.

C.3 Shifting to a taxpayer

You arrive in User mode — no taxpayer selected, limited modules, and any notifications shown are yours as a user. To do real work:

1. Use the taxpayer selection ("shift") control to choose the taxpayer you represent — yourself, your employer, or a client for whom you hold assignee/agent rights.
2. The portal enters Taxpayer mode: the full module set appears (subject to your role's permissions), and balances, returns, certificates and notifications now relate to that taxpayer.
3. To work on a different taxpayer, shift again. Make the shift consciously — acting in the wrong taxpayer is a real and recurring error (section F).

C.4 Password reset (forgotten password)

1. On the login page click Forgot Password.
2. Enter your username or registered email.
3. A password-reset link is emailed to the registered address. Follow it and set a new password.
4. Log in with the new password.

If the reset email does not arrive: check spam; confirm you entered the identifier the account was registered under; and consider whether the registered email is one you still control — if not, the recovery route is ZIMRA support, with proof of identity, since the portal cannot send secrets to an address you no longer hold.

C.5 Locked accounts

Repeated incorrect login attempts can temporarily lock the account as a brute-force defence. The options are to wait out the prescribed lock period or to contact ZIMRA support. Practical rule: after two failures, stop and use Forgot Password rather than guessing onward into a lock — especially on a filing-deadline day.

C.6 Changing a known password

Distinct from reset: with a valid session, go to Getting Started → Changing the Password, enter the current password once and the new password twice, and confirm. ZIMRA's own guidance is to use a strong password and rotate it at least annually.

C.7 The SSP user profile

Getting Started → SSP User Profile maintains your details: username, phone number, email address. Two disciplines:

• Update phone/email before they change in real life — verification codes and reset links go to what is on file, so a stale contact point can lock you out of your own recovery path.
• Do not confuse this with the taxpayer profile under Taxpayer Information; changing your user email does nothing to the taxpayer's registered particulars (and vice versa).

C.8 Inactivity logout and ending a session

The SSP automatically logs out an idle session after a period of inactivity. Do not rely on it: click Log Out deliberately at the end of every session, particularly on shared or public devices. An abandoned authenticated session on a shared computer is open access to every taxpayer you represent — a direct Section 5 secrecy exposure.

C.9 Access summary — who can act for whom

Access situation	How it is legitimately obtained	Where it is managed
Individual managing own affairs	Own user account + shift to self as taxpayer	Getting Started / Taxpayer Registration
Employee managing the employer's affairs	Own user account + assignee rights granted by the taxpayer	Assignee Management (Roles, Assignees)
Tax agent managing a client	Own user account + tax agent assignment	Assignee Management → Tax Agent Assignment
Public officer / representative taxpayer	Own user account + appropriate grant; answerability under Sections 53–61	Assignee Management + ZIMRA records
Anyone using another person's login	Never legitimate	—

D.1 Individuals

Rudo (employee) logs in a handful of times a year. Her risks are atrophy risks: a password set once and forgotten, a verification phone number changed since registration. Her routine: keep the user profile current the day her number changes; use Forgot Password without shame; log out on the family laptop.

Tendai (sole trader) logs in monthly at minimum (QPDs, clearance checks). For him the discipline is bookmarking the real URL and never entering credentials from an emailed link — sole traders are prime phishing targets because a harvested SSP credential exposes both his identity data and his tax affairs.

D.2 SMEs

Mbare Hardware (Pvt) Ltd has an accountant, an assistant, and an external tax adviser. Correct setup: three separate user accounts, each granted appropriate roles over the company through Assignee Management (e.g. assistant = return preparer; accountant = return submitter and payment authoriser; adviser = read-only plus preparation as agreed). When the assistant resigns, her assignee access is removed the same week — nobody changes any shared password, because there is none. The wrong (and still common) setup — one "company login" on a sticky note — fails Section 5 discipline, defeats attribution of submissions, and turns every staff departure into a security incident.

D.3 Large corporates and groups

The group tax manager maintains an access matrix: per entity (TIN), per user, per role, reviewed quarterly alongside the Assignee Management list. Login hygiene scales into governance: leavers and movers are processed on HR's trigger, not at year-end; the e-banking payment-authoriser role is held by fewer people than the preparer role; and the matrix is evidence of control for internal and external audit. Verification challenges (new device codes) are anticipated for staff who travel or hot-desk, by keeping registered emails corporate rather than personal.

D.4 Deadline-day failure drill (worked, no figures — a procedure)

It is the 25th; the VAT 7 is due today; the accountant's login fails twice.

1. Stop — do not burn remaining attempts toward a lock.
2. Forgot Password → reset via registered email (2 minutes if the email is current).
3. If the reset email is inaccessible (the address was the ex-accountant's): immediately escalate to a second authorised user — this is why the SME setup above insists on at least two users with submission rights — who files the return on time.
4. In parallel, contact ZIMRA support to recover the orphaned account with identity proof.
5. After filing: post-mortem — update profiles, add a second submitter if there wasn't one.

The lesson of the drill: redundancy of people with access is part of compliance, because the law judges the submission time, not the effort.

There is no reported Zimbabwean case on SSP login or access mechanics, and this lesson will not pretend otherwise. The adjacent authorities, treated fully in the Income Tax Course, are: Afritrade International Network v ZIMRA (2021, SC) on the position and liability of the public officer — the human whose answerability makes attributable portal access matter for companies; and the secrecy obligation in Section 5, which has been enforced administratively rather than generating reported portal-era litigation. Should a dispute ever turn on who submitted a return or whether a notification was received, the portal's per-user audit trail — preserved by the very disciplines in this lesson — is what each side would reach for.

1. Sharing one login across a team. Breaks Section 5 discipline, destroys attribution, and converts staff turnover into lockouts. One person, one account; access via Assignee Management.
2. Stale recovery contacts. Verification codes and reset links go to the phone/email on the user profile. Update the profile the day your contacts change, not when you next need a code.
3. Guessing a password into a lock on deadline day. Two failures, then Forgot Password. A lock plus a support queue can cost the filing day.
4. Entering credentials from an emailed link. Phishing campaigns mimic ZIMRA. ZIMRA's substantive communications arrive in the portal's Notifications; type the URL or use your bookmark, and treat unsolicited "ZIMRA" emails with attachments or login links as hostile until proven otherwise.
5. Working in the wrong mode or wrong taxpayer. Filing or reading in User mode, or in the wrong client after a careless shift. Verify the active taxpayer name before any submission or payment.
6. Confusing the user profile with the taxpayer profile. Changing your own email does not update the taxpayer's registered particulars; ITF 263 checks run against the taxpayer profile (Taxpayer Information), not yours.
7. Walking away from a live session. The inactivity timeout is a backstop, not a habit. Log out deliberately on shared devices.
8. No second authorised user. A single point of human failure before every deadline. Maintain at least two users with submission rights per taxpayer.

Work through the questions one at a time. Choose an answer and it is graded immediately, with an explanation and the provision it comes from. Your progress is saved, so you can stop and resume.

• Access is the gateway obligation: deadlines are met by submission, and submission presupposes a working login. Treat login health (current contacts, known passwords, second authorised user) as part of compliance.
• Login flow: direct URL → username/email + password → browser verification code where challenged → welcome dashboard in User mode → shift deliberately to the right taxpayer.
• Recovery: Forgot Password → emailed reset link; locked accounts wait or go to ZIMRA support; everything depends on the SSP user profile (Getting Started) holding current phone and email — which is distinct from the taxpayer profile.
• One person, one login — the portal-level expression of Section 5 secrecy and of attributable answerability under Sections 53–61; multi-user access is granted and revoked through Assignee Management, never by password-sharing.
• Security housekeeping per ZIMRA's own guide: strong passwords rotated at least annually; deliberate logout (the inactivity timeout is a backstop); quarterly assignee reviews; and treat emailed "ZIMRA" links as phishing — real correspondence lands in Notifications.
• No case law exists on login mechanics — the legal weight sits in the secrecy and representation provisions the design implements, and in the attribution of submissions under Section 37A.

Access events and their resolution paths

Event	Where resolved	Key dependency
Forgotten password	Login page → Forgot Password → emailed link	Registered email current and accessible
Known password, due for rotation	Getting Started → Changing the Password	Valid session
Account locked (failed attempts)	Wait prescribed period / ZIMRA support	Patience or identity proof
New device/browser challenge	Verification code to phone or email → Verify	Registered contacts current
Registered email/phone lost	ZIMRA support with identity proof	Cannot self-serve — prevention is the cure
Staff member leaves	Assignee Management → remove/deactivate assignee	Individual logins (no shared password to rotate)
Idle session	Automatic inactivity logout (backstop)	Deliberate Log Out as the habit

Login and access decision tree

flowchart TD
 A[Go directly to mytaxselfservice.zimra.co.zw] --> B[Enter username or email + password]
 B --> C{Login accepted?}
 C -->|Yes| D{Browser verification requested?}
 D -->|Yes| E[Enter code from phone or email - Verify]
 D -->|No| F[Welcome dashboard - User mode]
 E --> F
 F --> G[Shift to the correct taxpayer - Taxpayer mode]
 G --> H[Confirm active taxpayer name, then work]
 C -->|No - 1st or 2nd failure| I[Re-check credentials carefully]
 I --> B
 C -->|No - repeated failures| J[STOP - use Forgot Password]
 J --> K{Reset email accessible?}
 K -->|Yes| L[Set new password - log in]
 K -->|No| M[ZIMRA support with identity proof / use second authorised user]
 L --> B

Statutes & sections

• Income Tax Act [Chapter 23:06] — Section 5 (preservation of secrecy; gateways Section 5(3)/(3a); offences Section 5(5)/(5a)); Sections 53–56 (representative taxpayers); Section 61 (public officer); Section 37A(10)–(11) (submitted self-assessment return constitutes the assessment — why submission authorship matters); Section 25B and Section 37A deadlines as the obligations access serves.

Case law

• None on SSP login/access mechanics — stated honestly. Context: Afritrade International Network v ZIMRA (2021, SC) on the public officer's answerability (treated in the Income Tax Course).

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal — ZIMRA External Guide, Getting Started module (login, password reset, profile, changing password, inactivity logout) and Security Housekeeping Section (primary procedural source).
• ZIMRA SSP online help — https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm (authoritative per-screen reference; unreachable this run — see VERIFY flags on lock thresholds, timeout length and verification cadence).