User lifecycle

docs/_sidebar.md

@@ -12,7 +12,14 @@
   - [Request for SEED provisioning](request-for-seed-provisioning)
   - [Register Intune Device ID](register-intune-device-id)
   - [Edit TechPass profile](edit-profile)
-  - [User life cycle](user-lifecycle)
+- **Account and access lifecycle**
+  - [Overview](account-access-lifecycle-overview)
+  - [Securing your account](securing-account.md)
+  - [Account types and classification](account-types-classification.md)
+  - [Device registration and access](device-registration-access.md)
+  - [Access removal scenarios](access-removal.md)
+  - [Account lifecycle after departure](account-access-lifecycle/account-lifecycle-after-departure.md)
+  - [FAQs](account-access-lifecycle/faqs.md)
 - **Reset MFA**
   - [WOG account](reset-security-verification-for-wog-account)
   - [TechPass account](reset-techpass-mfa-for-new-device)  

docs/access-removal.md

@@ -0,0 +1,40 @@
+# Access removal scenarios
+
+Access to services through TechPass may be removed due to various reasons. This page outlines common scenarios and what happens in each case.
+
+---
+
+## Common scenarios
+
+| Scenario | Trigger | What happens | User action |
+| --- | --- | --- | --- |
+| **User leaves the organisation** | Notified via HR system, TIVO, or manual request | TechPass account may be disabled or deleted. Access to SEED, GCC, and SHIP-HATS will be revoked. | No action needed unless access persists. |
+| **Internal department transfer** | Not automatically detected | TechPass account remains unchanged. Access to previous projects may remain. | Notify project teams to update access. |
+| **Device no longer compliant** | MDM reports non-compliance | Access to SEED and other device-bound services blocked. | Re-register device or contact IT support. |
+| **Temporary project assignment ends** | TIVO system triggers expiry | TechPass access is revoked. | Inform project team if assignment continues. |
+| **Manual removal by admin** | Tenant admin removes user | Access removed immediately from linked services. | No action needed unless removal is incorrect. |
+
+---
+
+## What users should do
+
+- If you notice you still have access after departure, notify your former team.
+- If you are unable to access a service unexpectedly, contact your project team or [raise a service request](../raise-a-service-request.md).
+
+---
+
+## System limitations
+
+- **Delayed sync**: Some systems, such as SHIP-HATS and GitLab, only remove access weekly.
+- **Lack of signals**: Internal transfers are not automatically flagged to TechPass.
+- **Manual clean-up required**: Project teams must regularly review user access in tools like GitLab, SHIP-HATS, and CMP.
+
+> **Note:** Access reviews and user removal are part of each team’s ongoing responsibilities. TechPass helps enforce access policies but does not control project-specific tools.
+
+---
+
+## Recommendations for project teams
+
+- Perform periodic access reviews, especially for SHIP-HATS and GitLab.
+- Remove users manually when they depart or change roles.
+- Use service request webhooks where available (e.g. CMP) to automate workflows.

docs/account-access-lifecycle-overview

@@ -0,0 +1,37 @@
+# Account and access lifecycle: Overview
+
+Understanding how user accounts are created, used, and removed is key to managing access securely across Whole-of-Government systems. TechPass acts as a central identity provider, but different stakeholders play important roles at each stage of the account lifecycle.
+
+This section explains how accounts are provisioned, secured, updated, and eventually offboarded — and what actions may be required from users, agency admins, service teams, and TechPass.
+
+---
+
+## Lifecycle stages
+
+| Stage | Description |
+| --- | --- |
+| **Provisioning** | Accounts are created either through self-sign-up or by invitation, based on the user's role. Access is granted to necessary services and systems. |
+| **Usage** | Users authenticate via TechPass to access connected platforms (e.g. SEED, SHIP-HATS, GCC). Identity and device checks may apply. |
+| **Change of status** | If a user moves departments or roles, account access may need to be reviewed or adjusted. Internal transfers are not automatically detected. |
+| **Deprovisioning** | When a user leaves, their account may be disabled or removed. This affects downstream services like SEED and GCC. |
+
+---
+
+## Stakeholders involved
+
+| Role | Responsibilities |
+| --- | --- |
+| **End user** | Protect your login credentials, approve MFA prompts carefully, and report any anomalies. |
+| **Agency (HR, project teams)** | Create or invite users, keep assignments updated, and ensure timely removal upon staff departure. |
+| **Service teams** | Define access policies, integrate with TechPass for identity checks, and support access reviews. |
+| **IAM provider (TechPass)** | Enforce authentication, device compliance, and lifecycle signals through Entra ID and backend integrations. |
+
+---
+
+## Related topics
+
+- [Securing your account](securing-your-account.md)
+- [Account lifecycle after departure](account-lifecycle.md)
+- [User lifecycle rules](user-lifecycle.md)
+- [Device registration and access](device-registration.md)
+- [Access removal scenarios](access-removal.md)

docs/account-llifecycle.md

@@ -0,0 +1,49 @@
+# Account lifecycle after leaving your organisation
+
+When you leave your organisation, your TechPass account may be disabled or terminated. This affects your access to connected services such as SEED, GCC, and SHIP-HATS. This guide explains what you can expect and what you might need to do.
+
+## Lifecycle flow overview
+
+The diagram below shows how account removal is triggered and processed across systems:
+
+![Account Lifecycle flow](/assets/images/acc-lifecycle.png)
+
+## How account removal is triggered
+
+TechPass is notified by your organisation when a user leaves. These notifications come from official systems or manual requests from project teams.
+
+| Source | Applies to | Description |
+| --- | --- | --- |
+| HR systems | Public officers | Exit events are detected by central identity systems. |
+| TIVO system (temporary, intern, vendor officers) | Vendors, interns, temporary staff | Access removal is triggered when an assignment ends. |
+| Service request | All user types | A manual request to remove a user can be submitted by project teams. |
+
+> Note: If you move to another department within the same agency, your TechPass account will not be updated automatically. There is no signal to detect internal transfers, so your access remains unless your project team updates it manually.
+
+## How this affects your access
+
+Once your account is removed from TechPass, your access to other services may be affected in the following ways:
+
+- **SEED**  
+  You will be signed out and unable to log back in.
+
+- **GCC**  
+  Access is usually removed by project administrators. In some cases, this may take a few days, especially if GitLab group clean-up runs on a weekly schedule.
+
+- **SHIP-HATS**  
+  Access removal follows a weekly sync. If your access still works temporarily, your project team is expected to remove it during their regular reviews.
+
+## What you might need to do
+
+Most users do not need to take any action. However:
+
+- If you still have access to a service you should no longer use, notify your project team.
+- You may be logged out from services without warning once the removal process completes.
+
+## For project teams and administrators
+
+| Role | Action |
+| --- | --- |
+| Tenant admin | Remove user access after receiving the email notification from TechPass. |
+| Project team | Review and clean up user access in tools such as SHIP-HATS or GitLab groups. |
+

docs/account-types-classification.md

@@ -0,0 +1,32 @@
+# Account types and classification
+
+Each user in TechPass is assigned an account type. This classification determines how access is provisioned and managed across systems, including SEED, GCC, and SHIP-HATS.
+
+Account type is automatically assigned when the user is onboarded or invited.
+
+---
+
+## Account types
+
+| Account type             | Description |
+| ---                      | --- |
+| `account:public_officer` | User is a public officer. These users can either sign up or be invited. |
+| `account:vendor`         | User is a vendor (e.g. working in an ODC or on a contract). Must be invited by a project team. |
+| `account:temp`           | User is a temporary staff member (e.g. interns, short-term hires). Must be invited by a project team. |
+
+---
+
+## How account type is determined
+
+| Scenario | Assigned type |
+| --- | --- |
+| User signs up with a valid gov.sg email domain | `public_officer` |
+| User is invited by a project team as a vendor or temporary staff | `vendor` or `temp` based on the invitation details |
+| User account is provisioned via onboarding service with metadata | Automatically assigned based on metadata rules |
+
+---
+
+## Why this matters
+
+- Account type affects approval flows and access provisioning.
+- Certain

docs/device-registration-access.md

@@ -0,0 +1,45 @@
+# Device registration and access
+
+To enhance security, some services require users to register their device before access is granted. This ensures that only compliant and managed devices can access sensitive government systems.
+
+---
+
+## What is device registration?
+
+Device registration links a user’s identity to a specific device that meets organisational policies (e.g. antivirus, encryption, OS version). This is commonly managed through Intune or other mobile device management (MDM) solutions.
+
+---
+
+## When is it required?
+
+| Service | Device registration required? | Notes |
+| --- | --- | --- |
+| SEED | ✅ Yes | Users must register their device via Intune before accessing SEED. |
+| GCC | ❌ No | Access is based on identity and role, not device. |
+| SHIP-HATS | ❌ No | No device requirement as of now. |
+
+> **Note:** Other services may impose their own device registration requirements in future.
+
+---
+
+## How to register your device
+
+Follow the instructions provided by your agency. If you are accessing SEED, refer to the [Register Intune Device ID](../register-intune-device-id.md) guide.
+
+---
+
+## Common issues
+
+| Issue | Explanation | Suggested fix |
+| --- | --- | --- |
+| "Blocked device" error | Device not recognised as compliant | Register via MDM and wait for sync |
+| Unable to access SEED after new phone setup | New device not registered | Submit new Device ID |
+| Device shows as compliant but access still blocked | Sync issue or delay | Contact your agency's IT support or [raise a service request](../raise-a-service-request.md) |
+
+---
+
+## Shared responsibility
+
+- **User**: Must ensure their device is compliant and registered.
+- **Agency**: Provides device management and ensures onboarding instructions are followed.
+- **TechPass**: Enforces access policies bas

docs/securing-account.md

@@ -0,0 +1,88 @@
+# Securing your account
+
+TechPass is built with multiple layers of security to help protect your identity and access to Whole-of-Government (WOG) services. However, security is a shared responsibility between you, your agency, connected services, and the identity provider.
+
+This page outlines key security measures in place and your role in keeping your account secure.
+
+---
+
+## Shared responsibility model
+
+| Party | Responsibilities |
+| --- | --- |
+| **You (end user)** | Use secure devices, approve sign-ins carefully, and report suspicious activity. |
+| **Your agency** | Provision and deprovision accounts appropriately, manage staff movements, and ensure user access is up to date. |
+| **Services** | Enforce access reviews and role-based access control. |
+| **Identity provider (Microsoft Entra ID)** | Provide SSO, MFA, identity protection, and enforce conditional access policies. |
+
+---
+
+## Security controls in place
+
+### 1. Single sign-on (SSO)
+TechPass provides SSO across supported services, so you only need to authenticate once. This reduces password fatigue and lowers the risk of password reuse.
+
+### 2. Multifactor authentication (MFA)
+You must approve sign-ins using MFA via Microsoft Authenticator.
+
+**What you should do:**
+- Only approve sign-ins you initiated.
+- Always check the location and app name in the MFA prompt.
+- If unsure, reject the request and inform your TechPass administrator.
+
+### 3. Conditional Access Policies (CAP)
+Microsoft Entra monitors for risky sign-ins. If detected, CAPs are triggered to prompt reauthentication and reapproval of MFA.
+
+**What happens:**
+- You may be forced to log in again or verify identity.
+- Risky sign-ins are automatically blocked or challenged.
+
+### 4. Device registration
+Some services like SEED require device registration. This ensures that only authorised and compliant devices can access sensitive data.
+
+- Devices may need to be registered with Intune or MDM.
+- Users may be blocked from signing in on unregistered devices.
+
+### 5. Role-based access control (RBAC)
+Services such as GCC and StackOps use role-based access to limit what users can see or do. This is enforced via Azure RBAC.
+
+- Roles are tied to least privilege principles.
+- Admins must assign access deliberately.
+
+### 6. Access reviews
+Access reviews help ensure only the right users retain access.
+
+- Services may regularly prompt you to confirm whether you still require access.
+- Project administrators are expected to review user access lists periodically.
+
+### 7. Identity protection
+Microsoft Entra's Identity Protection uses machine learning to detect:
+
+- Atypical sign-in locations
+- Impossible travel scenarios
+- Use of anonymising tools
+
+If detected, actions include:
+
+- Blocking access
+- Prompting for MFA
+- Notifying admins
+
+---
+
+## Coming soon
+
+### Privileged Identity Management (PIM)
+This feature will help agencies control elevated privileges by:
+
+- Granting time-bound access to sensitive roles
+- Requiring approval before activation
+- Enforcing just-in-time access
+
+---
+
+## Summary
+
+Security is a shared effort. While TechPass and connected services enforce robust protections, you also play an essential role. Stay vigilant, review your access, and flag any suspicious activity.
+
+> **Need help?** [Raise a service request](raise-a-service-request).