Sometimes an attacker does not steal credentials. The organisation creates a valid account for them.
On 1 October 2026, New Zealand's National Cyber Security Centre and New Zealand Police published a joint advisory about DPRK IT workers seeking employment with New Zealand organisations. The agencies describe deceptive recruitment practices and recommend stronger identity checks, controlled onboarding and limits on access.
For an Australian business commissioning website work, that raises an ordinary but important question: what happens between accepting a developer's proposal and giving them administrator access?
The account came with the job
NCSC's Cyber Threat Report 2026, released on 24 September, had already described a North Korean IT worker clandestinely obtaining remote employment with a New Zealand business.
In the published case study, NCSC says the worker used a false identity, forged documents and a New Zealand contact address. A recruited New Zealand citizen received and operated the company's laptop. The business became suspicious, contacted NCSC and Police, and an investigation identified the worker as North Korean.
After the business terminated the employment and refused payment, the worker claimed to hold commercially sensitive information and threatened to release it. That is a reported claim and threat, not confirmation of precisely what information was taken. NCSC does not name the business in the case study.
The access followed an employment arrangement. The public account does not establish that the worker exploited a software vulnerability to get inside, or that the business was negligent.
Apply checks to the role, then constrain the access
The joint advisory's practical guidance includes independently checking application details, completing identity verification before granting access, and limiting permissions. It identifies inconsistent identity information, unexplained hardware delivery arrangements and unusual payment requests as matters for further scrutiny. The agencies explicitly caution that indicators do not establish illicit activity by themselves.
Those are reasons to clarify discrepancies through a consistent process. Remote work is a normal way to deliver technical services. Nationality, an accent or a different time zone does not tell you whether someone should have access to your database. The useful controls concern verified identity, agreed responsibilities and permissions appropriate to the job.
For a website engagement, I would record who is doing the work, which business is responsible and whether anyone else will receive access. If an agency changes the person assigned to the project, that should trigger an account change rather than another person inheriting a shared password.
Verification and access design perform different jobs. Even an honest, capable developer can have an account compromised. Limiting what that account can do remains useful after the hiring checks are complete.
A website project can reach surprisingly far
“Website access” may mean WordPress administrator rights, hosting, DNS, the domain registrar, SFTP or SSH, a database, Cloudflare, a Git repository, backup systems and API keys. Each permission should have an explanation tied to the work.
A content update might need an editor account. Troubleshooting a plugin might require temporary administrator access. Moving the website could require hosting and DNS changes. None of those tasks automatically justifies permanent access to every connected service.
DNS deserves particular attention because website and email records may share the same zone. Backups deserve it because they can contain information absent from the current public site. A hosting login may also reach several websites, including ones unrelated to the project.
Before onboarding, write down the systems involved and decide which permissions are needed now. My article on least privilege and appropriate access explains why a successful login alone does not establish that every available action is appropriate.
Where practical, let development happen in staging with suitable test data. Agree who approves production changes. A developer may need to build a feature without needing unrestricted access to live customer records throughout the project.
Make the account belong to a person
Create individual accounts, enable MFA where supported and keep ownership and recovery details under the business's control. An agency should not need the owner's everyday password simply because it manages the site.
Individual accounts make access easier to withdraw and activity easier to investigate. Logs can help establish which account changed a setting or published a file. They still need interpretation; an account record is not conclusive proof of who was sitting at the keyboard.
Agree how temporary access will be approved and when it expires. For an emergency repair, write the removal date into the job rather than relying on somebody remembering after the website is working again. Temporary support accounts have a habit of becoming long-term residents.
Keep a short access record alongside the project documentation: person, system, purpose and review date. The useful version reflects the permissions actually configured, including automated integrations and deployment credentials.
Finish the access work when the project finishes
Handover should cover permissions as well as files and invoices. For a typical website project:
- Remove old WordPress administrator accounts and temporary support users that no longer have a role.
- Revoke individual SSH keys, API tokens and deployment credentials that are no longer required.
- Remove former agency users from hosting, Cloudflare, repositories and backup services.
- Rotate shared credentials the departing provider knew, updating dependent services carefully.
- Review registrar and DNS permissions, recovery contacts and any continuing maintenance access.
Confirm the owner or replacement provider can still publish, restore a backup and recover the relevant accounts. Removing the only working administrator before arranging handover creates a different problem.
If ongoing maintenance is agreed, retain the permissions it needs and set a review date. If there is a suspected incident, preserve relevant records while arranging containment. Deleting an account does not retrieve information already copied or remove every token it may have created.
Simpler software can mean fewer permanent permissions
My recent WordPress Core vulnerability article examines software exposed by the running application. Developer accounts add the human and privileged-access side of the same security discussion.
For a suitable brochure website, a WordPress-to-static conversion can reduce both. Once the old installation is properly retired, the public site may no longer need a live CMS administration panel, production database, PHP runtime or plugin and theme administration. Permanent WordPress developer accounts can disappear with those components.
Static delivery still relies on hosting, DNS, Git, any CI/CD pipeline and deployment credentials. Someone able to change the build or deployment can potentially change what visitors receive. Keeping WordPress as a publishing backend also means keeping its maintenance and access responsibilities.
The benefit is fewer necessary components and privileges, provided the migration actually removes them. The editing workflow and business functionality must still fit. Solway Web Consulting's WordPress migration and static conversion service covers assessing that decision and planning the move.
The same access question applies at home
Private clients may rely on assistants, advisers, accountants, property managers, household IT providers and smart-home installers. Their accounts should be specific, reviewable and removable, with personal and business information separated where practical. A person engaged to maintain the home network does not automatically need continuing access to family documents or an executive's work accounts.
For a useful first step, open your website's administrator list with whoever maintains it. Identify the person and current purpose behind each account, then follow the connections into hosting, DNS and deployment.
Where the explanation ends with “they built the site a few years ago”, decide whether the access still belongs there.
Tags: wordpress, security, small-business, static-sites, australia