Identity has become a central part of access control because users and services reach applications across cloud, office and remote environments. That does not make identity a complete replacement for network security. It means the organisation should know which identities exist, what each can access, how that access is granted and how it is removed when it is no longer required.

Identity is more than a sign-in

Authentication helps establish that a person or service is using an account. Authorisation determines what that identity can do. Governance covers how identities are created, changed, reviewed and removed, and who is accountable for those decisions.

An organisation may have workforce accounts, privileged administrator accounts, contractor identities, service accounts and identities used by applications or automation. Each can create a different operational risk if its owner, purpose or permissions are unclear. A strong sign-in method is valuable, but it does not by itself resolve excessive privilege or stale access.

NIST’s zero trust architecture guidance treats identity and device authentication and authorisation as part of access decisions, rather than relying on network location alone.NIST SP 800-207 That is a design principle. The specific controls should reflect the organisation’s systems, risk and ability to operate them.

Establish ownership and lifecycle

Assign an owner to identity processes and to the applications that rely on them. Define who can request access, who approves it, how the request is recorded and who makes the change. Link access changes to joiner, mover and leaver processes so permissions follow current responsibilities.

Contractors and suppliers need clear start and end dates, named sponsors and a way to remove access when the work finishes. Service identities need an owner, documented purpose and review process as well. Avoid leaving an account active because its function is not understood. Investigate first, then remove or replace it through a controlled change.

Apply least privilege

Give an identity only the permissions needed for its role and tasks. Separate everyday accounts from administrative identities. Use distinct approval and authentication requirements for high-impact privileges where supported by the environment. Avoid sharing credentials, and make sure emergency access is controlled and reviewed after use.

Role-based access can make permissions easier to manage when roles are well defined. It can also preserve excessive access if role definitions are copied forward without review. Check what each role grants, whether it still matches the work and whether temporary access has an expiry.

Review access and exceptions

Access reviews should focus on whether a person or service still needs each permission. Prioritise privileged access, sensitive data and external identities. The reviewer needs enough context to make a decision, such as the user’s role, the application, the permission level and the business owner.

Record the decision and follow up on removals or changes. If an exception is required, document its reason, owner, approval and review date. A review that finds an issue but does not track the remediation to completion is not a complete control process.

Monitor use and investigate changes

Monitoring can help identify unexpected sign-ins, privilege changes or unusual access patterns. Decide which signals are collected, who reviews them, what triggers an investigation and how an alert is escalated. Validate that logs are retained and accessible to the people who need them during an incident.

An alert does not prove malicious activity. It is a signal for investigation. The responder needs a process to verify the identity, understand the resource accessed, assess potential impact and take an authorised response action. Coordinate identity response with endpoint, application and network teams where needed.

Integrate identity with the wider architecture

Identity is one part of an access design that also includes devices, applications, data, network paths and operational processes. A user may be authenticated correctly but still have an unmanaged device or a permission that no longer matches their role. Controls should work together, and their owners should know how the decisions connect.

Start with critical applications and high-risk identities. Map access paths, identify gaps and choose changes that the organisation can support. NIST describes zero trust as a set of concepts and architecture, not a single product, and it does not claim that these principles eliminate all risk.NIST SP 800-207

Make identity governance operational

Treat identity as an ongoing business process. Name owners, define approval and removal paths, keep records, review exceptions and test response procedures. Revisit the model when applications, suppliers or organisational roles change.

Read why perimeter security no longer holds and how to rethink access for hybrid work. For AltTab’s current assessment, identity and secure access scope, see Zero Trust services.

Back to Insights