CPCSC Level 1 Control
03.05.01Identification and authentication

CPCSC 03.05.01: User identification, authentication, and re-authentication

Use unique identities and authentication rules so every in-scope action can be tied back to the right person or process. This guide separates the formal control language from practical implementation, evidence, auditor questions, and related controls.

Open Level 1 Self-Assessment Browse Control Library

Formal Control Language

Official CPCSC Level 1 wording for 03.05.01. Use the Government of Canada page as the source of truth for certification or procurement submissions.

  • Circumstances requiring re-authentication are defined.
  • Users are uniquely identified and authenticated.
  • Processes acting on behalf of users are associated with the unique and authenticated users.
  • Users are re-authenticated when organization-defined circumstances or situations requiring re-authentication occur.

Contains information sourced from Government of Canada material used under the Open Government Licence - Canada.

What This Means In Plain English

Every user should have their own account. Shared logins make it hard to know who did what and make offboarding messy.

Re-authentication means users may need to prove who they are again when risk changes, such as after inactivity, privilege elevation, password reset, or sensitive system access.

For CPCSC Level 1, the useful test is not whether a policy mentions the control. The useful test is whether an owner can show the system setting, record, ticket, review output, or operating routine that proves the answer is true today and can be repeated when the next contract, customer, or assessment request arrives.

How To Implement It

1

Use a central identity provider where possible, such as Microsoft Entra ID, Google Workspace, Okta, or another managed identity platform.

2

Require unique named accounts for staff, contractors, admins, and service users. Avoid shared accounts unless the exception is documented and controlled.

3

Define password, SSO, session timeout, lock screen, and re-authentication requirements for in-scope systems.

4

Associate service accounts, automation accounts, scripts, and API tokens with an owner and purpose.

5

Use logs from the identity provider and key applications to support user activity and access investigations.

Evidence Normally Gathered

Identity provider user export.

Authentication policy or SSO configuration.

Password and session settings screenshots.

Service account inventory with owners.

Login and authentication logs.

Shared-account exception records.

Common Auditor Questions

Can every user action be tied to a unique identity?

Do any shared accounts exist, and how are they controlled?

When does the system require users to authenticate again?

Who owns service accounts and API tokens?

How do you investigate suspicious logins or account activity?