ITSG-33 and mobile device management: what Canadian government operations leaders need to know

ITSG-33 requires every mobile device touching Government of Canada data to meet a defined set of security controls—and for most departments, that means Protected B, Medium Integrity, Medium Availability (PBMM) compliance across the entire device lifecycle. This isn’t optional and it isn’t abstract. If your frontline workers carry ruggedised handhelds, tablets, or any device that processes Protected B information, those devices fall under ITSG-33. This post walks through the specific controls that affect mobile device fleets and explains what compliance actually looks like on the ground.

ITSG-33 applies to every device your frontline workers carry

A federal inspector loses a ruggedised handheld containing Protected B case data at a remote site. Within hours, the department’s IT security team is asking whether the device was encrypted, whether remote wipe was enabled, whether the MDM platform logs can prove the device’s last known state.

Every one of those questions traces back to a specific ITSG-33 security control.

Operations leaders often assume ITSG-33 is a server-room concern—something the IT security team handles in isolation. It isn’t. The framework’s reach extends to the handheld scanner in a field inspector’s truck and the tablet on a public safety officer’s belt.

The Canadian Centre for Cyber Security publishes ITSG-33 as the mandatory security control framework for all Government of Canada IT systems. Within that framework, control AC-19 explicitly requires organisations to establish usage restrictions, configuration requirements, and connection requirements for all organisation-controlled mobile devices. The companion publication ITSM.80.001 (Securing the Enterprise for Mobility) extends these baseline controls into specific enterprise mobility guidance.

Here’s what actually happens: most government operations teams discover ITSG-33’s mobile device requirements only when a procurement gets flagged during Security Assessment and Authorization. By then, the device selection is already made, the deployment timeline is set, and the operations team is scrambling to retrofit compliance onto a fleet that wasn’t designed for it.

The departments that avoid this scenario are the ones that bring ITSG-33 requirements into the conversation before the RFP is written.

What Protected B, Medium Integrity, Medium Availability (PBMM) means for mobile devices

PBMM is the baseline security profile for most Government of Canada departmental workloads. If you’re unsure whether it applies to your operation, it almost certainly does.

The ITSG-33 Annex 4A defines the PBMM security control profile, specifying which controls from the catalogue must be implemented at minimum. For operations leaders, this translates into concrete device requirements: encryption at rest and in transit, multi-factor authentication, remote wipe capability, application whitelisting, and audit logging.

The critical word is “minimum.” PBMM isn’t a ceiling—it’s a floor. Every mobile device in a typical federal department must meet this profile’s full set of security controls, not a subset. And those controls don’t just apply at deployment; they apply throughout the device’s operational life, through break/fix events, and all the way to decommissioning.

The ITSG-33 security controls that directly affect government mobile device fleets

ITSG-33’s security control catalogue contains hundreds of controls across management, technical, and operational classes. You don’t need to memorise all of them. For mobile device fleets, roughly a dozen control families carry the most operational weight.

What follows is a practical translation—not the catalogue language, but what these controls mean for your device fleet and your conversations with IT security.

Access control and mobile device configuration (AC-19)

AC-19 is the anchor control for mobile device management under ITSG-33. It requires documented usage restrictions, configuration requirements, and authorisation before any device connects to government systems.

In plain terms: every device must be enrolled in an MDM platform before it touches government data.

That sounds straightforward until you’re staging 300 ruggedised handhelds for a seasonal field inspection programme. MDM enrollment needs to happen before the devices leave the staging facility—not after they arrive at remote depots where connectivity may be spotty or non-existent. The control doesn’t care about your logistics constraints; it cares that no unenrolled device ever connects to Protected B systems.

AC-19 also requires that connection requirements be enforced technically, not just documented in policy. An MDM platform that can’t prove it blocked an unenrolled device from connecting won’t satisfy an assessor.

Encryption, remote wipe, and device authentication

Three controls work together here, and assessors will ask about all of them.

AC-19(5) requires full-device or container encryption for any mobile device processing Protected B information. The encryption must be active at rest—meaning when the device is powered off or locked—and in transit when data moves between the device and government systems.

AC-7(2) addresses what happens when authentication fails. After a defined number of unsuccessful login attempts, the device must purge or wipe itself. This isn’t a “nice to have” for lost devices; it’s a required control that your MDM policy must enforce.

IA-2 requires multi-factor authentication for access to government systems from mobile devices. A simple PIN isn’t sufficient. The MDM platform must enforce MFA, and it must be able to demonstrate that enforcement during assessment.

These three controls are non-negotiable. A device fleet that can’t demonstrate encryption, remote wipe, and MFA enforcement will not pass Security Assessment and Authorization.

Audit logging and continuous monitoring (AU-2, CA-7)

ITSG-33 requires auditable events to be defined, captured, and reviewed. For mobile devices, this means your MDM platform must produce logs that can survive a Security Assessment and Authorization review.

AU-2 specifies that organisations must determine which events require auditing. For mobile device fleets, this typically includes enrollment and unenrollment events, policy compliance status changes, authentication successes and failures, remote wipe commands, and application installations.

CA-7 extends this into continuous monitoring—the MDM platform must not only log events but provide ongoing visibility into the security state of every enrolled device.

Here’s what actually happens during SA&A: assessors will ask to see audit logs from the MDM platform showing who accessed what, when devices were last checked in, and whether any policy violations occurred. If the logs don’t exist, or if they lack the granularity ITSG-33 requires, the assessment stalls.

And if your MDM is hosted outside Canada, the assessor’s next question is about data residency. That question alone can delay an authorisation for months—which brings us to what may be the most consequential gate in any government mobile deployment.

Security Assessment and Authorization—the gate every MDM deployment must pass

Every new technology deployed in a federal environment must undergo Security Assessment and Authorization before it goes live. This includes MDM platforms and managed device programmes. There are no exceptions.

SA&A evaluates your deployment against ITSG-33 security controls. The process is mandated by the Treasury Board Policy on Government Security and operationalised through the ITSG-33 lifecycle approach. The Government of Canada’s Security Playbook references ITSG-33 as the foundational guidance for all IT security projects.

The timeline is what catches most operations teams off guard. SA&A routinely takes 6 to 18 months, depending on the complexity of the deployment and the completeness of vendor documentation.

Here’s the scenario we see repeatedly: a department planning a fleet refresh of 500 ruggedised handhelds for a new inspection programme discovers that their selected MDM platform hasn’t been assessed. The 6-to-18-month SA&A window means their field workers may be carrying outdated, unsupported devices well past the planned cutover date. Budget cycles move on, the project loses momentum, and the operations team is stuck explaining why the deployment slipped by a year.

The departments that navigate this successfully are the ones whose mobility partners arrive with pre-built ITSG-33 control mapping documentation. That documentation doesn’t eliminate the assessment, but it accelerates it dramatically. An assessor working with a vendor who has already mapped their capabilities to specific ITSG-33 controls can move through the evaluation in months rather than quarters.

If your vendor can’t produce that documentation, you’re building it together during the assessment—and you’re paying for that time in deployment delays.

Why Canadian data residency is an ITSG-33 compliance requirement, not a preference

Protected B workloads must be hosted in Canadian data centres. This is not a soft guideline or a procurement preference. It is a condition of authorisation.

Any MDM platform used in a federal environment must confirm Canadian data residency. During SA&A, assessors will ask where the MDM platform is hosted, where device telemetry is stored, where audit logs reside, and who has access to that data.

Operations leaders often assume that because a vendor operates a Canadian data centre, the data residency requirement is satisfied. That assumption can stall an authorisation.

If the vendor’s parent company is headquartered in the US, the data may still be accessible to foreign government agencies under foreign legislation. For a federal department processing Protected B information, that distinction matters during SA&A. Assessors will ask about it. And it matters even more if a breach occurs and the department must demonstrate that its data handling met ITSG-33 requirements throughout the incident response.

The practical implication: when you evaluate MDM platforms and managed mobility providers, “Canadian data centre” is not sufficient. You need to understand corporate jurisdiction, not just server location.

Personnel security screening for vendor staff

ITSG-33 control PS-3 requires that individuals with access to government information or systems undergo appropriate security screening.

For managed mobility providers, this means vendor personnel who may access federal data—whether through MDM administration, break/fix device handling, or staging activities—must hold appropriate security clearances. The minimum is typically Reliability Status, with many contracts requiring Secret clearance.

The vendor organisation itself typically needs a Designated Organisation Screening (DOS) or Facility Security Clearance (FSC) through PSPC’s Contract Security Program. Without these clearances, the vendor cannot participate in federal procurement, regardless of their technical capabilities.

This is an automatic filter. When you’re evaluating potential managed mobility partners, ask about personnel security screening early. If they can’t demonstrate cleared personnel and organisational security status, they cannot serve your requirements—full stop.

How ITSG-33 compliance shapes the entire mobile device lifecycle

ITSG-33 compliance isn’t something you achieve at deployment and then maintain passively. It’s a lifecycle obligation that covers how devices are sourced, how they’re configured, how they’re repaired, and how they’re destroyed.

The most common mistake we see is treating compliance as a deployment-time event. A device that met ITSG-33 requirements when it was enrolled doesn’t automatically stay compliant. Every operational phase introduces compliance touchpoints.

Secure staging and deployment under ITSG-33

Configuration management controls CM-2 and CM-6 require that baseline configurations be established and enforced for all information systems—including mobile devices.

In practice, this means devices must arrive at field locations pre-configured to ITSG-33 standards. You cannot ship blank devices to remote government depots and expect frontline workers to configure them on-site. The controls don’t allow for it, and the operational reality doesn’t support it. Connectivity at remote sites is often unreliable, and expecting field inspectors to execute MDM enrollment and policy configuration is a recipe for compliance gaps.

Staging must happen at a controlled facility—devices enrolled in MDM, policies pushed, applications installed, and compliance verified—before the device ever leaves for the field. The device should arrive ready to scan, ready to connect, ready to work.

Secure decommissioning and data destruction standards

When a device reaches end-of-life, ITSG-33 doesn’t release its grip. Federal secure decommissioning must produce auditable evidence compliant with RCMP TSSIT or NIST 800-88 (Guidelines for Media Sanitization).

For mobile devices, this means every single device must produce an individual certified erasure record—not a batch certification covering multiple devices. Chain-of-custody documentation must trace each device from operational deployment through certified data destruction.

Here’s a scenario that creates audit findings: a department decommissions 200 ruggedised handhelds after a programme ends. The devices are collected, boxed, and sent to a disposal vendor. Three months later, a security audit asks for data erasure records. The disposal vendor provided a single batch certificate covering all 200 devices—but the assessor wants individual device records. Without per-device documentation, the department cannot demonstrate ITSG-33 compliance at end-of-life.

That gap becomes a finding. And findings create remediation requirements that cost more than doing it correctly would have.

ITSG-33 control families that affect mobile device fleets

Choosing a managed mobility partner that meets ITSG-33 requirements

When operations leaders evaluate these requirements against their current or prospective managed mobility providers, the field narrows quickly.

Canadian data residency, bilingual service delivery, personnel security screening, and certified data destruction are not independent checkboxes. They’re interconnected requirements that collectively filter out most providers—particularly those headquartered outside Canada or those that treat government as a secondary market.

The federal Buy Canadian Procurement Policy Framework, effective December 2025, adds another dimension. Canadian ownership and in-country operations are now scored procurement advantages. A provider that previously competed on price or features now faces a structural disadvantage if they can’t demonstrate Canadian operational sovereignty.

When your department issues an RFP for managed mobility services, vendors that arrive with pre-built ITSG-33 security control mapping documentation, Canadian facility security clearances, and auditable chain-of-custody processes for decommissioning score materially higher. They also accelerate the SA&A process that every other vendor’s deployment must still navigate.

PiiComm operates as Canada’s largest pure-play managed mobility services provider—built specifically for Canadian regulatory requirements. Every device touches Canadian staging facilities staffed by personnel with appropriate security clearances. MDM administration happens through a 24/7 bilingual (English/French) service desk staffed entirely in Canada. Secure decommissioning produces individual device chain-of-custody documentation with NIST 800-88-compliant certified data erasure records.

These aren’t features listed on a capabilities slide. They’re direct answers to the ITSG-33 requirements your assessors will ask about.

For operations leaders managing field inspection programmes, public safety deployments, or any mobile fleet handling Protected B information, the questions to ask a prospective provider are straightforward:

• Where is your MDM platform hosted, and what is your corporate jurisdiction?
• Can you provide ITSG-33 control mapping documentation for your services?
• Do your personnel hold Government of Canada security clearances?
• Does your organisation hold a Facility Security Clearance through PSPC?
• Can you provide individual device data erasure certificates with chain-of-custody documentation?
• Do you deliver staging, service desk, and decommissioning from Canadian facilities with Canadian staff?

The answers will separate providers who can actually serve your compliance requirements from those who will create SA&A delays and audit findings.

Talk to a PiiComm mobility strategist about ITSG-33 compliance for your device fleet →

Frequently asked questions

What is ITSG-33 and why does it matter for mobile devices?

ITSG-33 is Canada’s mandatory IT security risk management framework, published by the Canadian Centre for Cyber Security. It governs all Government of Canada IT systems, including mobile devices that process, store, or transmit government information—requiring encryption, access controls, audit logging, and remote wipe capabilities at minimum for Protected B workloads.

What ITSG-33 security controls apply specifically to mobile devices?

The primary control is AC-19 (Access Control for Mobile Devices), requiring documented usage restrictions and configuration requirements. Supporting controls include AC-7(2) for device purge/wipe after failed logins, IA-2 for multi-factor authentication, AU-2 for auditable events, and SC-13 for cryptographic protection of data at rest and in transit.

What is the PBMM security profile under ITSG-33?

PBMM (Protected B, Medium Integrity, Medium Availability) is the baseline security control profile for most Government of Canada departmental workloads. It defines the minimum set of ITSG-33 controls that must be implemented on any system—including mobile devices—that handles Protected B information.

How long does Security Assessment and Authorization take for MDM deployments?

Security Assessment and Authorization for MDM platforms and managed device programmes typically takes 6 to 18 months. The timeline depends on the complexity of the deployment and the completeness of the vendor’s ITSG-33 security control mapping documentation. Operations teams should factor SA&A into deployment planning from the outset.

Does ITSG-33 require Canadian data residency for mobile device management?

Yes. Protected B workloads must reside in Canadian data centres. Any MDM platform managing government mobile devices must confirm Canadian data residency. Using a platform hosted outside Canada—or operated by a foreign-headquartered company—creates additional compliance burden during Security Assessment and Authorization.

What data destruction standards does ITSG-33 require for mobile devices?

Federal secure decommissioning requires auditable data destruction compliant with RCMP TSSIT or NIST 800-88 standards. For mobile devices, each device must produce an individual certified erasure record with chain-of-custody documentation—not a batch certification covering multiple devices.

Do managed mobility vendors need security clearances to serve government clients?

Yes. Vendor personnel who may access federal data or systems must hold appropriate security clearances—minimum Reliability Status, with many contracts requiring Secret clearance. The vendor organisation typically needs a Designated Organisation Screening or Facility Security Clearance through PSPC’s Contract Security Program.

The compliance conversation starts before the RFP

ITSG-33 compliance for mobile devices isn’t a mystery—it’s a documented set of requirements with clear operational implications. The framework tells you what encryption standards to meet, what audit logs to produce, what happens when a device is lost, and what documentation you need when a device is destroyed.

The challenge for operations leaders isn’t understanding the requirements. It’s ensuring those requirements are built into the procurement conversation from the beginning—not discovered during SA&A when the deployment timeline is already committed.

If you’re planning a device refresh, launching a new field programme, or re-evaluating your current managed mobility provider, the questions in this post give you a starting point. Bring them to your IT security team. Bring them to prospective vendors. The answers will tell you who can actually meet your requirements and who will create compliance gaps you’ll spend the next audit cycle remediating.

Explore PiiComm’s managed mobility services for government and public safety →