diff --git a/docs/_sidebar.md b/docs/_sidebar.md index fcac50c..708d3e3 100644 --- a/docs/_sidebar.md +++ b/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) diff --git a/docs/access-removal.md b/docs/access-removal.md new file mode 100644 index 0000000..bbacde6 --- /dev/null +++ b/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. diff --git a/docs/account-access-lifecycle-overview b/docs/account-access-lifecycle-overview new file mode 100644 index 0000000..3a39b28 --- /dev/null +++ b/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) diff --git a/docs/account-llifecycle.md b/docs/account-llifecycle.md new file mode 100644 index 0000000..9e8d240 --- /dev/null +++ b/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. | + diff --git a/docs/account-types-classification.md b/docs/account-types-classification.md new file mode 100644 index 0000000..c966208 --- /dev/null +++ b/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 diff --git a/docs/assets/images/acc-lifecyle.png b/docs/assets/images/acc-lifecyle.png new file mode 100644 index 0000000..4db5d7c Binary files /dev/null and b/docs/assets/images/acc-lifecyle.png differ diff --git a/docs/device-registration-access.md b/docs/device-registration-access.md new file mode 100644 index 0000000..c5a22e2 --- /dev/null +++ b/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 diff --git a/docs/securing-account.md b/docs/securing-account.md new file mode 100644 index 0000000..f627edf --- /dev/null +++ b/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). diff --git a/docs/securing-your-account.md b/docs/securing-your-account.md new file mode 100644 index 0000000..72de145 --- /dev/null +++ b/docs/securing-your-account.md @@ -0,0 +1,100 @@ +# Securing your account + +Multiple layers of security are applied across TechPass and its connected systems to protect user accounts and control access to government digital services. These controls span authentication, authorisation, monitoring, and automated risk detection. + +Account security is a shared responsibility across users, agencies, services, and the identity platform. + +## Shared responsibility + +Account security is maintained through the combined efforts of different groups: + +| Group | Responsibility | +| --- | --- | +| End user | Use multifactor authentication (MFA), avoid approving unknown sign-in requests, report suspicious behaviour | +| Agency (HR, managers) | Manage onboarding, deactivation, and internal movement of users | +| Services | Define access through roles, assign permissions, and conduct regular access reviews | +| Identity platform | Detect suspicious activity, enforce conditional access policies, and prompt reauthentication when needed | + +## Authentication and authorisation + +- **Authentication** is the process of confirming identity during sign-in (for example, using a password and MFA). +- **Authorisation** determines what access is granted to the user based on assigned roles (for example, a project admin may have more access than a viewer). + +Both are essential for secure system access. + +## Security controls in place + +### Single sign-on (SSO) + +TechPass uses single sign-on to provide access to multiple services through a single identity. + +- Managed via Microsoft Entra ID +- Requires MFA at sign-in +- Allows centralised monitoring of sign-in behaviour + +### Multifactor authentication (MFA) + +MFA is required for all users. It protects against unauthorised access even if credentials are compromised. + +- Review each prompt before approving +- Reject any unexpected MFA request +- Report suspicious activity to TechPass support +- MFA will be prompted again if a risky sign-in is detected + +### Device registration + +Access to some services, such as SEED, is restricted to registered devices. + +- Devices must meet compliance checks before registration +- Helps prevent unauthorised access from unmanaged endpoints + +### Role-based access + +Access permissions are based on user roles, aligned with the principle of least privilege. + +- Services such as GCC2 use roles to define what users can view or manage +- Roles should reflect the user’s actual responsibilities + +### Access reviews + +Regular access reviews ensure users retain only the access required for their roles. + +- Services are responsible for conducting reviews +- Users may be prompted to confirm continued access +- Unused or outdated access may be revoked + +### Identity protection and risky sign-ins + +The identity platform monitors sign-ins for risky patterns, including: + +- Sign-ins from unfamiliar locations or devices +- Unusual session activity or behavioural anomalies +- Multiple failed attempts or rapid account switching + +When risky behaviour is detected: + +- Access may be temporarily blocked +- The user may be asked to reauthenticate and complete MFA +- Conditional access policies are automatically enforced to reduce risk + +> To learn more, see [Microsoft identity protection](https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection). + +### Future enhancements: Privileged identity management + +Future updates may include tighter controls for sensitive roles, such as: + +- Just-in-time role elevation +- Time-based access expiry +- Access approvals before assignment + +These enhancements will support higher-risk functions and roles across agencies. + +## Security practices in integrated services + +- **GCC2** applies role-based access controls and conducts regular access reviews. +- **SEED** requires devices to be registered before granting access. +- Credentials used for TechPass sign-in follow security policies aligned with public sector infrastructure. + +--- + +This guide is part of the broader **account and access lifecycle**. To learn what happens when an account is deactivated or removed, see [Account lifecycle after leaving your organisation](account-lifecycle.md). diff --git a/docs/support/techpass-status.md b/docs/support/techpass-status.md index 37c7224..1570438 100644 --- a/docs/support/techpass-status.md +++ b/docs/support/techpass-status.md @@ -10,11 +10,16 @@ No scheduled maintenance! ## Ongoing incidents -No ongoing incident +No ongoing incident! + ## Previous incidents +| **Date** | 4 June 2025 | +|------|--------------| +| **Issue summary** | The Intune issue affecting new user onboarding to SEED has been **resolved as of 6:57 PM SGT**.

**Impact**: New users onboarding to SEED via TechPass may have experienced access issues earlier today.

The issue has been fixed, and onboarding is now functioning normally.

**For more assistance**: Create an [incident support request](https://go.gov.sg/seed-techpass-support). | + | **Date** | 22 January 2025 | |---|---| | **Incident summary** | At **11:58 AM (SGT)** today, TechPass users reported being unable to log in to the TechPass portal.

**Impact**
- Users were unable to access the TechPass portal during the incident.
- Access to downstream services was unaffected.

**Resolution**
- The issue has been resolved, and users can now log in successfully.

*Posted on: 22 January 2025, 12:30 SGT* |