29.08.2026
Website access: roles, 2FA, and project handover
After launching a website, businesses often focus on advertising, inquiries, SEO, and new sections while putting access management aside. Who has an admin panel login? Is there a backup administrator? Does an old contractor still have access? Where are the passwords for hosting, the domain, email, CRM, and payment services stored?
These questions seem purely organizational until something goes wrong: the site is unavailable, the form is not sending inquiries, content needs an urgent update, a payment system needs connecting, or a backup needs restoring, but the required access is missing. A proper system of roles and permissions protects the business from loss of control, team errors, and unnecessary security risks.
Why website access should be set up properly from the start
After launch, a website does not become a static business card. It is updated, promoted, connected to a CRM, given new text and pages, checked for technical errors, and tested for speed and security. All of this requires access, but not everyone needs the same permissions.
If every employee signs in with the same administrator login, the business cannot see who changed what. If a manager is given full permissions, they may accidentally delete a plugin, change the theme or break checkout. If a contractor receives unrestricted hosting access that is not revoked when the work is finished, this creates lasting risks.
Access should be planned as carefully as the website structure or inquiry form. For the structure of the path to an inquiry, see the article on the website homepage and inquiries, while access permissions ensure this journey can be maintained safely after launch.
What Types of Access a Website Usually Has
In a real project, website access is more than one password. An entire infrastructure surrounds the site: domain, DNS, hosting, CMS, database, email, analytics, CRM, payment services, delivery, CDN, backups, code repository, and ad accounts.
- domain and DNS zone;
- hosting or a server;
- the WordPress, OpenCart, WooCommerce, or other CMS admin panel;
- FTP/SFTP, SSH, database, and file manager;
- email, SMTP, and an email delivery service;
- Google Analytics, Search Console, Tag Manager;
- CRM, Telegram notifications, and integrations;
- payment services and delivery providers;
- a backup service and monitoring.
Some of these access permissions are needed by the business owner, some by the technical team, and some by a marketer or sales representative. Problems begin when these levels are mixed together and everyone gets full control instead of the minimum permissions they need.
The Principle of Least Privilege
The basic rule is simple: users should receive only the permissions needed for their tasks. A content manager does not need database access. A marketer does not need SSH. A developer does not always need access to the advertising budget. A sales representative does not need permission to delete payment modules.
This approach is not about mistrusting the team. It reduces the impact of accidental mistakes. If someone works only with products, pages, or inquiries, their role should be limited to those tasks. If the account is compromised, the damage will also be limited.
WordPress roles
WordPress has standard roles: administrator, editor, author, contributor, and subscriber. WooCommerce adds roles related to store management and customers. In practice, it is important not to give administrator access to everyone who needs to edit pages or products.
Administrator
An administrator can change almost everything: the theme, plugins, users, settings, site structure, SEO parameters, and technical integrations. This level of access should belong to the owner or responsible technical team, not every manager.
Editor and content roles
An editor can work with content without access to critical settings. This is the right level for people who add articles, update service pages, publish news or change copy. If more precise permissions are needed, configure them separately rather than granting full administrator access.
OpenCart access
In OpenCart, user groups and permissions to view or modify sections should be configured separately. A store manager may need orders, products, customers, and coupons, but not settings for payment modules, delivery, SEO URLs, caching, or the template.
After installing modules, check which new permissions have been added. Sometimes a module adds its own sections, and a user cannot see them because they lack permission. The opposite extreme is granting every permission to everyone, allowing a sales representative to accidentally change critical settings.
Passwords, 2FA, and a password manager
Website passwords should not be stored in unprotected chats, notes, or spreadsheets. A working team should use a password manager with separate entries, owners, access history, and the ability to revoke access. One password “for everyone” is a poor solution because it cannot be properly controlled.
Enable two-factor authentication for the admin panel, hosting, domain, email, CRM and payment services wherever possible. If a service supports separate roles and users, create personal accounts rather than sharing the main login.
A secure connection matters too. If the site uses forms, payments, sign-in, or an account area, HTTPS must be configured correctly. More detail is available in the article on domain, SSL, and HTTPS.
Contractors and temporary access
A contractor often needs access for development, SEO, advertising, technical support, or integrations. But that access should be limited by role, time, and task. Once the work is complete, revoke it or change the password if a shared account was used.
Best practice is to create a separate account for each contractor. This makes it clear who signed in, what they changed and when access can be revoked. For complex work, use a test environment or a copy of the website so that production is not changed without testing.
Backups Before Changes
Before granting access to critical settings, make sure there is a current backup. This is especially important before updating the CMS, changing the theme, installing plugins, modifying checkout, connecting payments, or migrating the site.
A backup should include both files and the database, and the team should know where it is stored and how to restore it. Simply knowing “there is a backup somewhere” will not help if nobody can access the restore panel during an incident. This is covered in more detail in the article on website backups.
Hosting, server and technical permissions
Hosting is one of the most sensitive access points. It allows changes to files, the database, email, PHP version, SSL, cron jobs, caching, and backups. The hosting account should therefore not be shared with every contractor without a need.
If the technical team needs file access, it is better to create a separate SFTP or SSH user with the required permissions. If only content needs updating, hosting access is not needed at all. For the environment's role in speed and stability, see the article on website hosting.
CRM, inquiries, and integrations
Access to the CRM and integrations is just as important as access to the CMS. If the website sends inquiries to a CRM, Telegram, email, or advertising analytics, you need to understand who can change fields, webhooks, statuses, tokens, and automation rules.
The problem may look like this: the website works and the form submits, but the inquiry does not reach the sales representative because a token has changed or a CRM workflow has been disabled. Technical integrations therefore need to be documented, and access to them must be controlled. Read more in the articles on Website API integrations and website integration with CRM and analytics.
Email, SMTP and transactional messages
Forms, order statuses, password resets, and system notifications often depend on SMTP or an external email service. If access to that service is lost, the site may appear functional, but customers and staff will not receive important emails.
SMTP credentials must be stored securely, passwords must not be visible to users who do not need them, and there must be a plan for replacing the key. If the email account belongs to a former employee or an old contractor, it needs to be brought under the business’s control. Start testing with an actual inquiry submission scenario, as described in the article on the website inquiry form.
What to document after launch
Access documentation should not contain passwords in plain text. Its purpose is to explain which systems the project uses, who is responsible for each, where secrets are stored, which roles exist, which integrations are critical and what to do in an emergency.
- domain and DNS owner;
- hosting or server and the person responsible;
- CMS, user roles, and rules for granting access;
- where backups are stored;
- which integrations transfer inquiries, payments, and events;
- which access permissions to revoke after the work is complete;
- technical support contact details.
This documentation should be updated after major changes: migration, redesign, connecting a new CRM, changing hosting, replacing a payment service, or updating team roles. For careful project migration, see the article on website migration without losing SEO.
Common access management mistakes
The most common mistake is sharing one main login with everyone. The second is a lack of two-factor authentication for critical services. The third is an unknown domain or hosting owner. The fourth is former contractors who still have access after completing their work.
Another issue is access without a test environment. If every change is made directly on the live site, the risk of breaking a form, payment flow, cache, or SEO settings is much higher. This is especially true for WordPress and OpenCart, where much depends on the theme, modules, cache, hosting, and compatibility. For more on the technical environment, see the article on website hosting.
A basic checklist for a business
If you need to get things organized quickly, start with an inventory. List all systems connected to the website and check whether the business has its own access to them. Then eliminate shared passwords, create individual accounts, enable 2FA, and revoke unnecessary permissions.
- check ownership of the domain, DNS, and hosting;
- create separate accounts for the team and contractors;
- leave full permissions only with those who genuinely need them;
- enable 2FA for critical services;
- check backups and access to restoration;
- document the CRM, email, payments, analytics and webhooks;
- review access after every team or contractor change.
What Web Alchemy does
Web Alchemy helps not only launch websites but also organize their technical foundations after launch: access, roles, backups, hosting, SSL, forms, SMTP, CRM, analytics, caching, and support. This matters when a website is already running, generating inquiries, and cannot risk downtime.
We can check who has access to the website, what permissions the team needs, whether backups exist, whether form delivery works correctly, whether former contractors still have admin access and whether changes can be made safely. The areas of work are described on the page Web Alchemy services, and examples of solutions can be found in portfolio.
If you need to quickly understand which access credentials to gather before website support or improvements, you can contact us through contact details or describe the task through AI consultant.
Conclusion
Website access is part of business control, not a minor technical detail. When permissions are organized correctly, the team can safely update content, handle inquiries, maintain integrations, and respond quickly to problems.
Start simple: identify the domain and hosting owner, review CMS roles, remove shared passwords, enable 2FA, revoke old access, and make sure backups can actually be restored. This is not the most visible part of a website, but it often saves a project at a critical moment.