Two Identity Providers After an Acquisition
Cobalt Systems acquires Lumen Robotics. Cobalt uses Okta with SAML for 1,400 employees; Lumen uses AD FS with 900 contractors and 300 employees. Contractor accounts are sponsored by any manager and have no recertification for two years. Forty-seven service accounts have passwords stored in code repositories, and 12 have interactive logon rights. Cobalt helpdesk resets MFA by phone after verifying employee ID; push notifications are enabled for all users. The acquisition closes in 60 days, and the CIO wants a single identity provider within 12 months. A recent tabletop found that a terminated contractor retained access for 11 days. Lumen's HR data is incomplete for 120 contractors, and 40% of applications still use local accounts. Cobalt's SOC has seen repeated MFA push prompts for one finance user.
1. What is the safest sequence for consolidating the two identity providers?
Read the worked answer
Do not start with a big-bang migration. First inventory applications, accounts, and owners across both environments, and clean up orphaned and contractor accounts. Establish identity governance before migration, because consolidation without governance simply moves the mess into one system. Then configure federation or coexistence between Okta and AD FS, pilot a small user group, and migrate applications in waves based on risk and dependency. Keep break-glass accounts separate, excluded from sync, and tested. The 12-month single-provider goal is credible only if application inventory and cleanup come first. The 11-day termination gap shows that joiner-mover-leaver integration must be fixed in parallel, not after consolidation. Communicate a freeze on new local accounts during migration.
2. How should contractor recertification be designed?
Read the worked answer
Use risk-based, sponsor-attested recertification. Each contractor should have a named sponsor who confirms business need, and a manager who confirms the role is still required. Privileged contractors should recertify every 30 to 60 days; standard contractors every 90 days. Automate disablement when certification is not completed or when the contract end date passes. Use last logon, ticket activity, and badge data to challenge inactive accounts. Track completion rates, revocations, orphaned accounts, and time-to-disable. The 11-day termination gap means the process must integrate with HR and procurement, not rely on managers remembering to notify IT. Sample-audit sponsor decisions to prevent rubber-stamping.
3. How should the service-account and MFA/helpdesk weaknesses be addressed?
Read the worked answer
Inventory all 47 service accounts, vault their credentials, rotate them, and replace them with group-managed service accounts or workload identities where possible. Remove interactive logon rights from service accounts and scan repositories for embedded secrets. Do not apply MFA to non-interactive service accounts as a checkbox; instead restrict them by network and conditional access. For humans, move from simple push to number matching or phishing-resistant authentication, and strengthen helpdesk identity proofing. Restrict who can reset MFA and log every reset. The repeated push prompts for one finance user suggest MFA fatigue and should trigger a targeted investigation and user re-enrollment. Break-glass accounts should use hardware keys and sealed procedures.