員工離職時，企業通常都有一套既定流程。HR 更新員工狀態，IT 停用公司 Email、關閉帳號，設備歸還後，Offboarding 看起來就完成了。但如果這名員工在公司任職三年，期間使用過 Google Workspace、Slack、Salesforce、GitHub、AWS、Notion、BI 平台，以及各種 SaaS 與 AI 工具，停用主要帳號真的代表所有權限都已經消失嗎？
他曾經申請的特殊權限呢？加入過的專案群組呢？GitHub Repository、Cloud Role、共用帳號或第三方 SaaS 的存取權呢？如果他曾經授權 AI 工具連接企業資料，或負責某個 AI Agent，這些存取關係又會怎麼處理？
企業真正需要撤銷的，從來都不只是一個帳號
真正要管理的是一個身分在任職期間累積的所有 Access，以及這些權限是否能隨著員工入職、調職與離職同步改變
這也是 Identity Lifecycle Management 真正要解決的問題。
Offboarding 不只是停用帳號，而是撤回所有不再需要的 Access
很多企業的離職流程，仍然以「帳號是否已停用」作為完成標準。但在 SaaS、Cloud 與大量企業應用程式並存的環境裡，一個員工身上往往不只有一個帳號。同一個企業身分可能同時擁有 CRM 使用權、雲端平台 Role、特定資料夾權限、GitHub Repository Access、報表編輯權，以及因專案而臨時取得的特殊權限。
因此：
1 個 Employee Identity，不等於 1 個 Account
更接近現實的情況是：
1 個 Identity → 多個 Application → 多個 Account → 更多 Entitlement 與 Permission
真正的 Offboarding 問題，也就不再只是：「公司 Email 關掉了嗎？」
而是：「這個人現在是否還能透過任何帳號、應用程式或權限接觸企業資源？」
這正是 Okta Lifecycle Management 的核心價值之一。企業可以把 HR 系統或其他權威來源作為員工身分狀態的依據。當員工加入公司、職務異動或離職時，對應的 Lifecycle Event 可以觸發相關帳號與應用程式的 Provisioning、權限調整或 Deprovisioning。
換句話說，Offboarding 不再只是等 HR 寄一封 Email 給 IT，再由 IT 人員逐一關閉帳號，而是讓身分狀態的變化直接驅動後續的 Access Lifecycle。這不只是提升效率，更重要的是減少「有人忘記處理」所留下的資安風險。
真正容易被忽略的，可能不是離職，而是調職
離職帳號必須停用，幾乎所有企業都知道，反而容易被忽略的是：員工還在公司，只是換了一個職務。
假設 Amy 原本在 Marketing。她擁有行銷自動化平台、Campaign 資料夾與 Customer Audience Data 的存取權。一年後，她轉到 Sales。企業很自然會替她新增 Salesforce、Sales Reporting 與 Pricing 資料的權限。
問題是，原本的 Marketing 權限有沒有一起被移除？
很多企業的權限管理在這裡出現一個很常見的模式：新職務需要什麼，就加什麼。舊職務不再需要什麼，卻不一定有人處理
久而久之，員工可能歷經幾次職務或部門異動，每次都增加新的 Access，舊的 Access 卻持續保留。這就是常見的 Privilege Creep，也可以理解成權限逐步累積。最大的 Identity Risk 未必來自某一次明顯的錯誤授權，而可能來自多年來「只加不減」的權限累積。
因此，完整的 Identity Lifecycle 不應該只有：
Joiner → 建立帳號
以及：
Leaver → 關閉帳號
中間的 Mover 同樣重要。
當員工的部門、職務、工作地點或責任範圍改變時，企業應該重新計算他現在需要哪些 Access，而不是只在既有權限上繼續增加。
Okta Lifecycle Management 搭配 Workflows，可以讓這些職務變更觸發自動化流程。企業不只可以新增新職務需要的存取權，也可以同步調整或移除已經不再符合工作需求的權限，讓 Access 更接近 Least Privilege 原則。
SaaS 越多，靠人工管理 Access 就越容易失控
以前企業員工可能只需要 Email、ERP 和檔案伺服器。現在，一個普通知識工作者每天使用十幾個 SaaS 並不罕見。再加上 Cloud Platform、Developer Tools、Collaboration Tools、Data Platform，以及快速增加的 AI 應用，企業需要管理的帳號與權限數量已經完全不同。
每多一個應用程式，都可能多出新的 Account、Group、Role、Entitlement、OAuth Connection 或特殊 Access Approval。如果這些權限主要依賴 Excel、Email、Ticket 或人工通知管理，企業很難長期確保每一次入職、職務異動與離職都被完整執行。
AI 的出現只是讓這個問題再多一層。
員工除了可能使用新的 AI SaaS，也可能負責某個 AI Agent，或讓 AI 與企業應用程式建立新的存取關係。
因此，員工離職時，未來企業除了問：
「他的 SaaS Account 關了嗎？」
還可能需要問：
「他負責的 AI Agent 怎麼辦？」
「相關的 Linked Access 是否還需要保留？」
但本質沒有改變。無論是 SaaS、Cloud 還是 AI，企業最終都在面對同一個問題：當人的工作關係改變時，相關 Access 能不能一起改變？
Okta 如何把 Joiner、Mover、Leaver 變成持續的 Identity Governance？
如果企業只是把 Lifecycle Management 理解成「新員工自動開帳號、離職員工自動關帳號」，其實只看到其中一部分。真正完整的 Identity Lifecycle，應該讓 Access 跟著 Business Need 改變。
Joiner 的重點，是讓新員工在加入公司的第一天，就取得工作真正需要的應用程式與權限。企業可以根據部門、職務、工作地點或其他條件，自動建立帳號與 Provision Access，而不是完全依賴主管逐項提出申請。這樣做的價值不只是讓員工更快開始工作，而是讓每項 Access 都有一致的來源與規則。
Mover 的重點，則是當員工職務改變時重新檢視 Access。除了針對新的工作增加所需權限外，也要同時檢視原本擁有的工作權限，有哪些是已經不需要的。這讓權限管理從「一直往上疊加」改成根據當前職務重新調整。
到了 Leaver，理想狀態則是讓 HR 系統中的離職狀態直接觸發後續 Deprovisioning，而不是依賴人工通知與 IT Checklist。但 Lifecycle Management 仍然不能處理所有權限問題，因為有些 Access 並不是根據職務自動取得。
例如 Amy 因為一個六個月的專案，額外申請 Finance Dashboard 的存取權。主管核准後，她取得權限。
六個月後專案結束，但 Amy 仍然留在公司。她沒有離職，也沒有換部門，因此單純依賴 Joiner、Mover、Leaver 的 Lifecycle Rule，未必會知道這項 Access 已經沒有業務需求。
這就是 Okta Identity Governance（OIG）進一步發揮作用的地方。
透過 Access Requests，企業可以建立正式的權限申請與核准流程；透過 Entitlement Management，可以更精細地管理應用程式內不同層級的權限；透過 Access Certifications，則可以定期要求 Manager 或 Application Owner 重新確認：這個人現在還需要這項 Access 嗎？
Okta Identity Governance 再搭配 Lifecycle Management 與 Workflows，讓企業管理的不只是「帳號存在或不存在」，而是整個 Access Lifecycle。
可以把兩者簡單理解成：Lifecycle Management 管理人的狀態改變
而：Identity Governance 管理這個人擁有的 Access 是否仍然合理
這個差異，在 SaaS 與企業應用持續增加的環境裡會越來越重要。
成熟的 Identity Lifecycle，不是「入職開帳號、離職關帳號」
Identity Lifecycle Management 的最終目標，不應該只是縮短建立或停用帳號的時間。
真正成熟的模式應該是：
當 Business Need 出現，Access 出現。
當 Role 改變，Access 跟著調整。
當 Project 結束，額外權限被重新檢視。
當 Employee 離職，相關 Access 被撤銷。
因此，企業真正值得問的是：
「當一個人的工作關係改變時，他所有相關 Access 可以多快、又多完整地跟著改變？」
Okta Lifecycle Management、Workflows 與 Identity Governance 的價值，就是把原本散落在 HR、IT、Application Owner 與 Manager 之間的人工流程，轉換成由 Identity 驅動、可以持續執行並留下治理紀錄的 Access Lifecycle。
Identity Lifecycle 管理的終點不是把帳號關掉，而是確保每一項 Access 都只存在於真正需要它的時間內。
如果您的企業仍然大量依賴 Email、Excel 或人工 Ticket 來處理員工入職、調職與離職，真正值得檢視的可能不是單一帳號，而是整套 Identity 與 Access Lifecycle 是否仍然跟得上現在的 SaaS 環境。
歡迎聯絡思想科技 Master Concept 專業顧問一起評估現有 Identity Lifecycle 與 Access Governance 流程，找出 Provisioning、權限累積、Offboarding 與 Access Review 中可能存在的治理缺口。
FAQ
什麼是 Identity Lifecycle Management？
Identity Lifecycle Management 是根據員工入職、調職與離職，自動建立、調整或撤銷帳號與企業存取權限。
Joiner、Mover、Leaver 是什麼？
Joiner 是員工加入企業、Mover 是職務或部門異動、Leaver 是員工離職。三種狀態都應該觸發相對應的 Access 變更。
員工離職後，只停用 Email 帳號就夠了嗎？
不夠。企業還需要確認 SaaS、Cloud、應用程式 Role、特殊權限與其他企業資源的存取權是否一併撤銷。
為什麼員工調職也可能造成資安風險？
如果新權限持續增加、舊權限沒有移除，就可能形成 Privilege Creep，讓員工逐漸累積超出工作需求的 Access。
Okta 如何協助員工 Offboarding？
Okta 可透過 Lifecycle Management、Workflows 與 Identity Governance，將 HR 狀態變更連結到帳號停用、Deprovisioning、Access Review 與權限撤銷流程。
