Your Website Security Depends on Everyone Who Can Log In

Sometimes an attacker does not steal credentials. The organisation creates a valid account for them.

New Zealand's National Cyber Security Centre describes an uncomfortable example in its Cyber Threat Report 2026, released on 24 September. According to NCSC, a North Korean IT worker clandestinely obtained remote work with a New Zealand business to generate foreign currency for the North Korean state. The agency warns that this activity brings espionage, extortion and sanctions risks.

The published case study says the contractor used a false identity, forged documents and a New Zealand contact address. A locally recruited person operated the company's laptop. After the business became suspicious and contacted authorities, an investigation identified the worker as North Korean.

When the business ended the employment and refused payment, the worker claimed to possess commercially sensitive information and threatened to release it. That is a reported threat and claim of possession; the account does not establish exactly what information was taken. NCSC does not name the business in that case study.

The detail that should interest a small-business owner is how access began. Someone was engaged to do legitimate work. The arrangement gave them a position from which business systems could be misused.

The website version is much closer to home

A web developer may need WordPress administrator access, a hosting control panel, SFTP or SSH, and a Git repository. A migration might also involve the domain registrar, DNS or Cloudflare. Add database access, backups, SMTP credentials and API keys, and a modest website project can involve quite a collection of permissions.

Each request may have a sensible explanation. Together, they can reach well beyond changing a few pages.

Someone able to change DNS may affect email delivery. A hosting account may expose other sites and stored backups. A developer who configures website email does not automatically need access to the owner's mailbox.

Your website security is partly dependent on someone else's laptop, passwords, accounts and employment arrangements. That remains true when the developer is competent and honest: their own account can be compromised too.

Before hiring through Airtasker or another marketplace

Hiring a developer through Airtasker or another freelance marketplace deserves the same care as hiring someone through a referral. A polished profile and positive reviews are useful information. They leave questions about who will actually receive your credentials.

For critical website, hosting, domain and email administration, my recommendation to Australian SMEs is explicit: restrict that access to verified Australian citizens or permanent residents working in Australia, engaged through an identifiable Australian business with an active ABN. Apply the requirement to every person receiving access, including agency staff and subcontractors. Put it in the brief and contract, with no offshore delegation of privileged access.

Government vetting provides a useful reference. AGSVA normally requires Australian citizenship and a checkable background for a security clearance, with exceptional waivers possible. Clearance levels depend on the resources involved: NV1 covers ongoing access up to SECRET. It is not a blanket requirement for every government system. My citizen-or-permanent-resident recommendation is an SME procurement standard, not an equivalent to NV1 or a claim that every web developer needs a clearance.

The practical objective is to establish who holds the access and which Australian business accepts responsibility for the work. Verify the individual's identity and citizenship or permanent residency securely and with consent. Check the supplier's active ABN, legal entity name and business details through ABN Lookup, and match those details to the contract and invoices. Obtain a verifiable Australian business address, contact details and references. Keep an agreed record of authorised workers and their changes, with handover and support obligations that continue after payment.

An ABN alone does not prove citizenship, local operations or competence: businesses outside Australia can also qualify for one. Verify the person, the business and where access occurs separately. A local address on a profile is insufficient.

For Australian SMEs and private clients hiring someone to administer their website or connected services, my recommendation is to insist on the platform's ID verification and a recent Australian National Police Check certificate before granting privileged access. Make that expectation clear before engaging them. Agree what counts as recent for the role, check the issue date and purpose, and use the issuer's verification process where available, with the person's consent. Avoid collecting identity documents or police records in public task comments.

Airtasker's ID Verified badge means its third-party provider has verified the user's identity. Its separate Police Check Badge is available to Australia-based users through its own process, with matching identity details and no disclosable court outcomes. Airtasker says that badge can remain displayed for up to 12 months. Check the actual profile and underlying check date rather than accepting a screenshot as sufficient evidence.

Those checks have limits. The Australian Criminal Intelligence Commission explains that a police check is a point-in-time result, with no standard validity period. It cannot establish someone's future intentions, technical competence or the security of their devices. Nor does a missing badge establish wrongdoing.

An Australian police check also leaves overseas history to consider. Where relevant, seek verifiable overseas checks and references alongside the Australian requirements.

If a supplier cannot meet these requirements, do not grant critical access. A lower quote does not resolve an unverified identity or leave you with an identifiable business to contact after the project. Restricting the shortlist will exclude some cheaper overseas bids. For access that can redirect email, transfer a domain or replace a website, I consider that a reasonable trade-off. Verified local engagement improves traceability and practical accountability; individual accounts, logs and access limits still need to do their part.

Give the project the access it actually needs

After verification comes a separate decision: what should this person be allowed to do?

My SA Health article on least-privilege access explores the distinction between a valid login and appropriate access. For a website project, write down which systems the work requires and when those permissions will end.

A developer changing page content may need an editor account. Someone maintaining plugins may need administrator rights during the maintenance arrangement. Neither task automatically justifies permanent registrar access or unrestricted access to unrelated email systems.

Create individual accounts, require MFA where supported and keep the business in control of ownership and recovery details. If a supplier creates the hosting or domain account, make sure the business can recover it without that supplier's cooperation. Record who is authorised to add other users.

Shared administrator accounts make it harder to withdraw one person's access or establish who changed something. With SSH, use individual keys for each person or device rather than distributing one private key. Removing a former contractor's key should not require rebuilding everybody else's access.

The same principle applies to private clients. Assistants, accountants, property managers, IT providers and smart-home installers may each need access to part of a household's systems. Access should be specific, reviewable and removable. That is part of Solway Web Consulting's personalised cybersecurity consulting for Sydney private clients, as well as its business work.

What happens when the web project ends?

The final invoice is rarely connected to an automatic access review.

An old developer may still have a WordPress administrator account. A former agency may remain in the hosting panel. A plugin support account created for one repair may survive several redesigns. None of those accounts needs malicious intent to become a problem later.

Make access removal part of handover:

• Remove individual accounts and former agency users that no longer have an agreed role.
• Revoke their SSH keys, API tokens and deployment credentials; rotate shared secrets they knew.
• Review registrar, DNS, hosting and backup access, including recovery contacts.
• Check staging sites and integrations for credentials carried over from production.

Confirm that the owner can still log in, deploy and recover the site after the changes. Review available activity logs where there is a concern about past access. Revoking an account prevents further use of that account; it does not retrieve information already copied.

If ongoing support is needed, document the continuing permissions and review date. A maintenance agreement is a reason to retain suitable access. A project completed three years ago needs a better explanation.

A simpler site can need fewer permanent privileges

The recent WordPress Core vulnerability article examines the software side of attack surface: the application code exposed by a running site. Developer accounts add another part of that boundary.

A dynamic WordPress installation needs continuing attention to Core, plugins, themes and its database. Depending on the maintenance arrangement, that can mean several people retain elevated access to the production application or server.

For a suitable brochure website, generating and deploying static HTML can remove the public CMS login, PHP runtime, production database and plugin administration. Once the old installation is properly retired, its permanent WordPress developer accounts can go too.

Git, deployment credentials, hosting, DNS and any CI/CD system still need protection. Someone who controls the deployment pipeline may be able to replace the whole site. Static architecture changes the permissions to manage; it does not eliminate trust.

Fewer components can nevertheless mean fewer persistent privileged access paths. Solway Web Consulting's WordPress migration service considers that alongside editing needs, business functions and the practical work of moving the site.

Before commissioning another rebuild, ask whoever looks after your website for a list of everyone who can administer it, including suppliers and automated accounts. Put a purpose and an owner beside each one. Where nobody can explain why an account still exists, you have a concrete job to resolve.