How to start with PAM in a mid-sized Norwegian organisation

Here is how to get privileged access management live in a mid-sized organisation, in the order that keeps production running.

I am the chief architect on one of the world’s largest Idira (CyberArk) deployments, and I lead privileged access at FM CyberSecurity. On that deployment and on the Norwegian rollouts I have run since, the same thing decides the outcome. Not the product. Which accounts you onboard first, and what you agree to leave for phase two. Mid-sized here means a few hundred employees, one IT operations team, and nobody whose full-time job is identity.

We build on Idira (CyberArk). Palo Alto Networks renamed CyberArk to Idira on 12 May 2026, so the vault, the rotation engine and the session proxy you may already know carry a new name. We covered what the rename changes and what it does not separately. Steps 1 to 8 below are programme decisions, and they hold whichever platform you land on.

1. Count the privileged accounts before you choose anything

Nobody knows how many privileged accounts they have, and the number is always higher than the estimate. Run discovery across Active Directory, local administrator accounts on Windows and Linux servers and laptops, the hypervisor and backup consoles, network gear, and the cloud tenant break-glass logins. Put the result in one sheet with four columns: account, system, what it can do, who owns it. The owner column is the one that comes back empty, and that gap is the finding you act on.

2. Vault the accounts that can take the whole estate, first

Start with the credentials that turn one compromised laptop into a compromised company: domain admins, the hypervisor and backup administrator accounts, and the cloud tenant break-glass logins. Vault them, put rotation on a schedule, and route access through session isolation so the password never lands on an administrator’s own machine. Idira Privileged Access Manager does the vaulting, rotation, isolation and recording as one flow. Ten to thirty accounts is a normal count at this step. It is the smallest change with the largest risk reduction in the whole programme.

3. Take standing local admin off the endpoints next

Local administrator rights on laptops are the shortest path from a phishing click to your domain. NSM’s penetration testers keep finding the same things in Norwegian systems: guessable and reused passwords, and administrator passwords sitting in file shares that ordinary users can read (Ti sårbarheter i norske IKT-systemer, NSM 2023). Remove standing local admin from the standard workstation build and hand back the specific elevations people need, per application, through Idira Endpoint Privilege Manager. Run it in audit mode for two weeks before you enforce, so you elevate what the business uses rather than what the policy assumes.

4. Onboard service accounts with their dependencies, never before

A service account is a credential plus every place that credential is used. The same account can run a Windows service, a scheduled task, an IIS application pool and a SQL Agent job. Idira calls those dependent accounts, or usages, and the rotation engine updates them together when it changes the password. Map the dependencies, then onboard, then rotate, in that order. Skip the mapping and the rotation will succeed while the 02:00 batch job fails, and PAM gets the blame. Credentials that live inside application code belong in secrets management instead of a human vault workflow.

5. Write the MVP down as numbers, not adjectives

A minimum viable PAM is a count, not a feeling. Mine has six lines:

• Every domain admin and tier-0 infrastructure account vaulted and rotating, where tier-0 means the systems that take everything else with them if they fall.
• Standing local admin removed from the standard workstation build.
• The twenty highest-risk service accounts onboarded, with their dependencies mapped.
• Session isolation and recording on for every tier-0 target.
• One break-glass procedure with a dated test record behind it.
• Privileged session logs arriving in your SIEM.

The long tail of application accounts and third-party vendor access is phase two, and so is zero standing privilege, which Idira licenses by platform tier. In the rollouts I have run, that MVP lands in about 90 days when account owners answer email, and drifts when they do not.

6. Connect the three systems that decide adoption

Three integrations decide whether administrators use the vault or work around it: your directory, your SIEM, and your ticketing system. The vault should authenticate people against the directory and multi-factor setup you already run, so nobody carries a second password. Privileged session logs should forward to the SIEM in week one, not the week the auditor asks. Access requests should arrive where your change process already lives, so every privileged session is tied to a change number. Anything else can wait a quarter.

7. Decide what the recordings have to prove

Session recording exists to answer one question: who used which privileged account, on which system, and what did they do there. Turn full recording on for tier-0 targets and for third-party vendor sessions first, and keep command-level logging everywhere else. Agree retention with whoever owns your ISO 27001 or NIS2 evidence before you configure it, because retention costs nothing to set on day one and a lot to change on day 400. Then have someone open a random recording once a month. A recording nobody has ever watched is storage, not a control.

8. Name the person who owns it the Monday after go-live

PAM programmes fail in year two, not in month three, and they fail because nobody owns the day-two work. That work is concrete: onboarding new accounts as systems get built, maintaining policy, testing break-glass, and running the access reviews that catch privilege drift. Put a name and a weekly hour count against it before you sign anything. If the name does not exist internally, buy the day-two operations. That is one of the delivery shapes in our identity practice, alongside project delivery and a consultant sitting inside your team.

The pitfalls that stall PAM projects

These are the ones I see repeat, and they are all avoidable.

• Service account discovery runs longer than the rest of the project. The scan finishes in days. Finding a human who admits to owning each account takes weeks. Timebox it: publish the list, give owners a deadline, and treat silence as agreement to disable.
• Rotation breaks scheduled jobs. Rotate one application group at a time, inside a maintenance window, with the previous password retrievable for rollback. Two clean windows buy more trust than a full-estate rotation that fails once.
• Vaulting accounts nobody owns. An orphan account in a vault is still an orphan, and now you have a record showing you knew. Disable it or assign it an owner. Do not vault it to make a dashboard number rise.
• Break-glass that has never been tested. Test it twice a year with the vault deliberately unavailable, and write down who was in the room. An untested emergency path is a plan, not a control.
• Recording everything from day one. Full recording across every target floods storage and slows logins, and administrators then push to turn it off. Start narrow, prove the value, widen.

Start with step 1 this week. Discovery changes nothing in production, and the account list it produces is what every later decision gets argued from. Send me the list when you have it and I will tell you which accounts I would vault first, and in what order.

FAQ

Which companies in Norway deliver PAM projects on Idira (CyberArk)?

Several Norwegian firms deliver privileged access projects, and the platform is the smaller part of what separates them. Ask two questions in the first meeting: how many production deployments has the person designing your rollout architected, and will you talk to that person or to an account manager. FM CyberSecurity builds privileged access on Idira (CyberArk), and the architect on your project is the same person who wrote this piece.

What should a PAM implementation include as a minimum?

Vaulting and scheduled rotation of domain admin and tier-0 infrastructure accounts, session isolation and recording for those targets, standing local admin removed from the workstation build, the highest-risk service accounts onboarded with dependencies mapped, one tested break-glass procedure, and privileged session logs forwarded to your SIEM. If any of those six are missing, you have a pilot rather than a programme.

Which accounts should we bring into PAM first?

The accounts that can change everything: domain admins, hypervisor and backup administrators, and cloud tenant break-glass logins. Then standing local admin on endpoints. Then service accounts, once their dependencies are mapped. Application and vendor accounts come after that. Ordering it the other way round costs you months and gives you less risk reduction per week.

How long does a PAM MVP take in a mid-sized organisation?

About 90 days in the rollouts I have run, with the eight steps above as the scope. The variable is not the technology. It is how quickly account owners respond and how much of the service-account estate has no owner at all. Both are visible from step 1, which is why discovery goes first.

Do we have to remove local admin rights at the same time?

Not in the same week, but in the same programme. Vaulting the top accounts while endpoint privilege stays untouched leaves an obvious route open: a user clicks, the attacker inherits local admin on that laptop, and the walk toward the domain starts from there. Audit mode first, then enforcement, is how you close it without a helpdesk queue.

What does day-two PAM operation involve?

Onboarding accounts as new systems appear, maintaining policy and platform versions, testing break-glass, reviewing who still needs which privilege, and investigating the sessions that look odd. Budget it as ongoing work, not a project tail. Most of the PAM programmes I have seen go quiet did so because this work had no owner.