Our company acquired a business about one-third our size last quarter, and the technical integration is moving slowly. We have a NIS2 audit scheduled for October, so I need a clear, defensible access-control process by then.
We currently use Passwork and would like to make it the single password-management platform. It has worked well during previous audits, particularly its per-user audit logs and access controls. The acquired company uses a mixture of shared departmental vaults and spreadsheets, with no reliable record of who can access which credentials.
The goal is to migrate their credentials into our vault structure, retire the old tools, and establish one access model. I can import users through LDAP and potentially migrate data from exports, but I do not want to bring stale, duplicated, over-shared, compromised, or retired credentials into the system we will rely on and present to the auditor.
What migration order and cleanup process would work best under a tight deadline? I would prefer to clean the data during migration without requiring a manual review of every credential. I also need to onboard the acquired company's administrators and give them the access they legitimately need without granting broad temporary permissions that never get removed. Would structured training and a supervised onboarding period be a sensible approach?
4 Answers
The acquired administrators should be treated as colleagues who need to learn the new operating model, not as a problem to work around. Explain the target access model, provide role-based training, and let them request access through the same process as everyone else. Keep their existing permissions only long enough to maintain continuity, review them with their managers, and set a firm date for removing anything that is not justified.
Freeze changes in the legacy tools first, then inventory everything by owner, department, last-used date, privilege level, and whether it is still needed. Credentials that have not been used for 90 days can go into a quarantine area for review instead of being imported immediately.
Migrate department by department rather than credential by credential. Have each department lead confirm ownership and required access before the data is moved. Anything with unclear ownership should generally be rotated, reassigned, or retired instead of being copied into the new system. Use a documented approval checklist so you can show the auditor how decisions were made.
For the acquired administrators, use least-privilege accounts, time-limited elevated access where supported, and a pairing period with administrators from your company. Training is useful, but it should be combined with supervised access reviews and an explicit removal date for temporary permissions.
A user-driven migration can work when the legacy system is reasonably organized: give people clear instructions, set a short deadline, and have them move the credentials they still own into the new platform. In this case, though, the shared vaults and spreadsheets mean you probably need an administrative inventory first. Otherwise users may unknowingly carry over duplicates, stale accounts, or credentials that should have been rotated.
Treat the migration as a credential-reset project, not just a data import. As each application moves into the new vault, verify its owner, remove unnecessary sharing, create named accounts where possible, and rotate the password or token. Old vault entries should be disabled or retired only after the new credentials are tested, with the change recorded for the audit trail. Pay particular attention to service accounts, hardcoded secrets, and accounts with administrator privileges.
I would avoid a plaintext CSV migration if possible. Passwords written to disk create another exposure point and may remain in backups or endpoint history. Use a supported direct migration or an encrypted transfer process, and securely remove any temporary files afterward.