If you build or maintain websites for a living, you have already done identity work without calling it that. Creating editor accounts, resetting a client’s login, deciding whether a freelancer gets admin rights, cleaning out the user table after a project ends: all of it counts. A newer label, IdentityOps, bundles this routine work into a discipline, and hiring managers are starting to ask for people who can handle it. This article lays out the skills, the order in which to learn them and the proof that makes a portfolio credible.
Why a CMS professional should care
Content management systems are account factories. Every WordPress site, every Moodle install, every headless setup with a hosted editor creates user records that outlive the projects that spawned them. Agencies in particular accumulate orphaned logins: the former designer who still has editor rights on a dozen client sites, the plugin vendor’s support account nobody removed.
The Ops Atlas, an online encyclopedia of operations practices, frames IdentityOps as maintaining an accurate picture of every account holder and the evidence each one offers. The entry concedes the term is still emerging and that vendors draw the scope differently, which is useful to know before you put the word on a CV. You can read the Atlas definition and scope notes and decide which parts match the work you do.
The skill stack, from basics upward
1. Lifecycle thinking
The foundation is the joiner, mover, leaver cycle. A person arrives, changes roles and leaves, and the account state should follow each event. Learn to sketch that flow for a client: where the trigger comes from, which systems must react, who confirms the result. In an agency this is often a spreadsheet and a Slack reminder. That is fine. What matters is that it exists and has an owner.
2. Directories and single sign-on
Next, understand how a central login service hands out proof of identity to separate applications. The Atlas names two protocols that cover most cases, SAML and OpenID Connect, and a provisioning standard called SCIM that pushes account creation and removal into applications. You do not need to implement them from scratch. You do need to read a vendor’s documentation, spot which plan tier unlocks the feature, and explain trade-offs to a client. The Atlas notes that many software-as-a-service products keep provisioning behind higher-priced plans, which is exactly the sort of thing that derails a project estimate.
3. Strong sign-in methods
Know the difference between a second step that attackers can bypass and one that resists phishing. Under the Atlas’s strict reading, just physical security keys and PKI smart cards make the grade; text codes and approve prompts fall short. A practitioner who can roll that out sensibly, starting with administrators and then widening to everyone, is genuinely useful.
4. Recovery design
It is a rare skill and an excellent differentiator. When a client’s editor loses their phone, what is the process? The Atlas describes graduated paths from self-service to supervised proofing, and warns that a help desk resetting credentials on a phone call is how several famous intrusions began. Writing a clear recovery script for a client is a deliverable you can show.
5. Machine identities
Websites run on API keys, deploy tokens, database passwords and webhook secrets. The Atlas calls these non-human identities and suggests keeping a register that records owner, purpose, expiry and review rhythm, preferring short-lived credentials, and retiring them by disabling, waiting and then deleting. If you can produce that register for a real project, you have evidence of competence that most developers cannot match.
Building evidence you can show
Careers are built on artefacts, not adjectives. Here is a practical set of portfolio items, each doable on a small project.
- A one-page leaver checklist for a CMS-based site, covering the CMS, hosting panel, domain registrar, analytics and email accounts.
- A before-and-after account audit on a staging copy, showing accounts removed and why.
- A recovery script written for non-technical editors.
- A machine-credential register for one project, with owners and expiry dates.
- A short write-up explaining a metric, such as the proportion of departures fully completed in the applications rather than only in the central login.
On that last item, the Atlas gives a clean example worth borrowing in an interview: out of forty departures, thirty-six were switched off on schedule, yet three in that group retained an account in a lower-tier application, which dragged the honest result down to 82.5 percent from the 90 the directory alone would suggest. Being able to explain why the measured number changed is the kind of detail that persuades an interviewer.
Learn it on the platforms you already use
You do not have to learn on enterprise tooling. Content platforms are a fine practice ground. Our walkthrough on setting up and managing WordPress user accounts and their roles covers the account side, and the guide to configuring access control and permissions on a WordPress site covers the next layer. Notice which questions in those guides belong to identity (who has an account, how do they authenticate) and which belong to permissions (what can each role do). The Atlas draws precisely that line, treating permission design and access approval as neighbouring practices rather than part of its own scope.
A learning plan you can follow in twelve weeks
- Weeks one to two: inventory every account you personally hold on client systems and mark which ones you no longer need. Do the same for yourself as a leaver.
- Weeks three to four: set up single sign-on between a test directory and one CMS, using a free tier.
- Weeks five to six: enrol hardware keys for your own admin accounts and document the recovery path.
- Weeks seven to eight: write the machine-credential register for a live project.
- Weeks nine to ten: run a full departure drill on a staging environment and time each step.
- Weeks eleven to twelve: write up what you found and what you changed.
What employers actually look for
Agencies and in-house teams rarely advertise for an IdentityOps engineer. They advertise for developers who can set up secure editorial workflows, for site reliability people who handle credentials, for consultants who clean up after migrations. Showing that you can do the identity part of those jobs makes you more employable.
A few signals stand out. First, you can state the difference between disabled and fully removed. Second, you measure rather than assume. Third, you know the licence questions to ask a vendor before promising a client a feature. Fourth, you can describe failure honestly: the Atlas surveys several public breaches, including a forgotten test tenant that lacked any second factor and service credentials kept in a private storage folder, and notes that each defeated a process, not the cryptography. Being able to discuss those without drama shows maturity.
A note on certifications and titles
People often ask whether a certificate settles the question. For now, no credential carries the IdentityOps name, which fits with the Atlas observation that the term has no founding document and no standard definition. The Atlas points readers toward a professional body of knowledge for identity practitioners and toward public frameworks from government security agencies, such as a zero-trust maturity model. Reading those gives you vocabulary that interviewers recognise, and they cost nothing. Pair that with the hands-on artefacts above and you have a stronger story than a badge alone.
Pitfalls to avoid on the way
Do not call yourself an identity specialist after one tutorial. Do not claim universal coverage of a second step when you really mean text codes. Do not buy an expensive governance product before the HR or client contact data is clean; the Atlas states plainly that automation on top of messy data just spreads the mess faster. And do not overlook the boring cadence. Its suggested rhythm: reconcile every day, sample recoveries every week, review lapsing credentials each month, rehearse a departure every quarter. Even a freelancer can run a lightweight version of that on a calendar.
Start small, document everything and let the artefacts speak. The discipline is young enough that a clear portfolio piece still stands out.
