A firefighter separates from the department but still can open mutual-aid apps through federation. What lifecycle control is missing?
Select an answer to reveal the explanation.
Short Explanation
When the firefighter turns in the gear, federated app access has to end the same day—not linger as a courtesy or wait for them to tidy up partner accounts. Hook revocation into the HR/identity lifecycle. Shared generic logins after exit just rename the orphan problem.
Full Explanation
Federated access must follow the identity lifecycle. When a firefighter separates from the department, termination of the home identity must promptly revoke assertions, active sessions, and partner entitlements so mutual-aid applications stop accepting that person. Tie federation to joiner–mover–leaver processes—typically HR or identity events driving IdP disablement, forced logout, and relying-party entitlement removal—so cross-org access does not outlive employment. Residual federated access after separation is a classic lifecycle control gap.
Keeping federated access active for ninety days as a courtesy after separation creates a known, policy-approved residual-access window that adversaries and disgruntled leavers can use. Relying on former staff to manually delete their partner accounts when convenient is unverifiable and frequently never completed. Converting the leaver’s account into a shared generic mutual-aid login for the station destroys accountability, complicates future investigations, and merely renames the orphan-access problem.
Exam caveat: federation does not suspend deprovisioning duties; lifecycle alignment must propagate to every relying party. Operational check: wire termination events to IdP account disablement, revoke sessions and partner entitlements automatically, ban courtesy post-employment federated access windows, prohibit converting individual accounts into shared generics, and test a leaver scenario end to end against mutual-aid apps.