In a company with no security or identity hire, login should be owned by one named person, normally a senior engineer or the CTO, with a named deputy, and that person should be accountable for four things: who can sign in and how access is removed, the answers given to customer security questionnaires, the identity vendor’s contract and renewal dates, and what happens when sign-in stops working. Owning login does not mean doing all the work. It means being the person whose name is beside each of those items when a customer, an auditor or your own team asks who is responsible.
This post is written for CTOs, VPs of Engineering and founders at B2B SaaS, education technology and non-profit platform companies with roughly 20 to 150 people. It covers why login ends up with no owner, what the owner is responsible for, how much time the role takes, which parts to keep in-house, and how to name an owner this month.
Why does login end up with no owner in a small company?
Login is usually set up early, by whoever was available, to get the product working. A library is added, a hosted service is chosen, or a simple password table is built, and it works well enough that nobody revisits it. The person who made those choices may later move to another team or leave, and the decisions stay in place without anyone being assigned to them.
Our guide to what login costs your engineering team each quarter describes the recurring work that results, such as security updates, customer requests and support tickets. The point here is narrower: because the work is spread across several people, it falls between roles. Engineering fixes bugs, support answers tickets, sales forwards questionnaires, and finance handles the renewal, so no one is responsible for the system as a whole.
The gap tends to appear when a customer asks a direct question, such as who in your company is responsible for access control, or how quickly a former employee of theirs would lose access to your product. If the answer is a pause followed by a list of names, the company has a login owner problem, whatever tooling it uses.
What is an owner of login responsible for?
An owner is the single person accountable for outcomes in four areas. They do not have to perform each task personally, but they do have to know the current state and make sure it is handled.
Access: who can sign in, and removing people who have left
The owner knows how accounts are created, how administrators are granted their rights, and how access is removed when a person leaves your company or when a customer’s staff member leaves theirs. They make sure multi-factor authentication is required for administrators and anyone who can see sensitive data. They also run a periodic check of who has access to what. Our guides to the joiner, mover and leaver process and user access reviews describe how to make this a regular, scheduled task.
Evidence: answering customer questionnaires and audits
Enterprise customers send security questionnaires, and many of the questions are about login: how passwords are stored, whether single sign-on is supported, how sessions end. The owner keeps one set of current, reviewed answers so that sales is not asking a different engineer each time and giving slightly different replies. What security questionnaires ask about login lists the typical questions.
Vendors and renewals: what the identity setup costs and when contracts end
The owner knows which identity service or library is in use, what it costs, when the contract renews, and what notice is required to leave. Price changes at renewal are easier to handle when somebody is watching the date. When it is time to compare options, build vs buy for identity and how to pick an identity vendor without an identity team help structure the decision.
Incidents: who acts when sign-in stops working
When sign-in is down, customers cannot use the product at all. The owner decides in advance who is contacted, who can change configuration, and how the company communicates with customers. Our article on identity resilience and IdP outages covers what to plan for.
How much time does the role take each quarter?
We do not have a trustworthy industry figure for this, and the right answer depends on your size and setup, so the most useful approach is to estimate it from your own records. The role breaks into recurring tasks, each of which you can count:
- Access review: one pass through the list of administrators and privileged users per quarter. Count how long your last one took.
- Questionnaires: the number received last quarter multiplied by the time it took to answer the login questions, once you have a reusable set of answers.
- Vendor and contract check: a short review per quarter of renewal dates, usage and any price notices.
- Incident preparation: a yearly rehearsal of what to do if sign-in fails, plus the real incidents that occurred.
- Patching and upgrades: the time spent on security updates for whatever you run yourself. This is the item that shrinks the most when a provider operates the system.
When is this part of an engineer’s job and when does it need its own role?
For a company with a handful of enterprise customers and a simple setup, the role fits inside one senior engineer’s or the CTO’s job. It starts to need a dedicated role when questionnaires and customer SSO requests arrive weekly, when you run your own identity infrastructure at a scale that needs on-call cover, or when a compliance program such as SOC 2 makes evidence collection a regular workload. Track the hours for two quarters before deciding, so the decision is based on your data.
Which parts should you keep in-house and which should a managed service take?
A useful split is between running the system and deciding how it is used. Operation is the part to hand over if you can: keeping the software patched, monitoring uptime, managing certificates, and applying security releases. Those tasks require attention at inconvenient times and offer little advantage when done in-house by a team that has other priorities.
For Skycloak, a managed identity service, that means upgrades and security patches, infrastructure and uptime monitoring, and certificates and your custom sign-in domain are run for you. The hosting page shows what is included, and support differs by plan, with 24/7 support on the Enterprise plan only; the pricing page lists the other plans and their prices.
What do you still own after you hand over operation?
Even after a provider runs the system, you remain accountable for how it is used. You still decide who is an administrator, whether MFA is required, how your customers’ accounts are removed, and what you tell customers in a questionnaire. You also still own the vendor relationship: reading release and security notices, checking renewal dates, and knowing how you would export your data if you left. Skycloak’s security page lists what the company documents about its own controls, and that material is what you will point to when a customer asks, but the decisions about your own configuration remain yours.
How do you name an owner and a deputy this month?
The first conversation can be short. Use this checklist:
- Choose one person as the owner, and one as the deputy who takes over when the owner is away or leaves.
- Write down, in a single document, the current identity setup: what is used, who administers it, where the contract and renewal date are recorded.
- Agree who answers customer questionnaires about login and where the approved answers live.
- Set a quarterly reminder for the access review and the vendor check.
- Decide who is contacted if sign-in fails, and how customers are told.
- Record which operational tasks you do yourself and which a provider does, so that a new hire can see it.
- Book 30 minutes in three months to review whether the time the role takes matches your expectation.
Frequently asked questions
Does a small company need a dedicated security hire to own login?
Not necessarily. A named senior engineer or the CTO can own it, with a deputy, as long as the responsibilities are written down and reviewed regularly. A dedicated role becomes worthwhile when questionnaires, customer SSO requests or compliance work arrive often enough to fill a significant part of someone’s week.
Who should answer customer security questionnaires about login?
The login owner should keep the approved answers, and sales or customer success should reuse them. That prevents different people from giving different answers to the same question.
What happens to login ownership if the owner leaves?
The deputy takes over, which is why you name one. The written description of the setup, the vendor contract and renewal date, and the approved questionnaire answers are what let a new person pick it up without reverse-engineering the system.
If we use a managed identity service, do we still need an owner?
Yes. The provider operates the system, but you still decide who has access, whether MFA is required, how departing users are removed, and what you tell customers.
How often should the owner review access?
At least once a quarter for administrators and privileged users, and whenever a customer or auditor asks for evidence. The more sensitive the data, the more often you may want to check.
Summary
Login needs a named owner and a deputy even when there is no security hire, because the work spans engineering, support, sales and finance and falls between them otherwise. Name the owner this month, write down the current setup and renewal dates, set quarterly reminders for the access review and vendor check, and decide which operational tasks to hand to a managed service while keeping the decisions about access and customer answers in-house.