Content on securing identities, accounts, privileged access, cloud systems and business environments such as Microsoft 365, Google Workspace and cloud infrastructure. We explain MFA, IAM, PAM, access reviews, privileged accounts, logging, monitoring, Zero Trust and cloud security controls.
IAM vs PAM: Key Differences and How They Work Together
IAM manages identities and access, while PAM adds protection for permissions that enable administration and other high-impact operations. This guide compares their goals, users, access types, controls, auditing and tools. It also explains the relationship between PAM and PIM and follows an external technician through a coordinated access process. A sample integration record helps verify that granting, using and removing permissions work together rather than as disconnected activities.
Prepared by: CCyber Editorial Team
IAM manages which identities can access particular resources. PAM focuses on additional protection for privileged access that enables system administration or other security-significant operations. They are complementary disciplines, not interchangeable ways of securing a company.
A practical distinction is that IAM establishes identity, permissions and their lifecycle. PAM helps control when and under which conditions elevated permissions can be used and how the resulting actions are accounted for. Protection should cover employees, providers and relevant application identities.
20 September 2026
The starting point is the “IAM vs PAM” infographic and its accompanying note. We retain the seven comparison areas while clarifying simplifications using Microsoft, NIST, NCSC and HashiCorp documentation. The technician scenario, integration record and proposed acceptance criteria are CCyber recommendations.
IT managers, IAM and PAM owners, administrators, application owners and security teams. It also supports boards and service buyers deciding whether the organization needs better identity management, additional administrator protection or improved integration between existing capabilities.
IAM, or Identity and Access Management, encompasses policies, processes and technologies for managing identities and access to resources. Its purpose includes giving appropriate permissions to authorized users while keeping unauthorized identities out. The scope is described in Microsoft’s IAM overview.
PAM, or Privileged Access Management, protects particularly significant permissions and how they are exercised. Microsoft describes it as a subset of IAM combining people, processes and technology. It is not simply a password vault for administrators. See the PAM overview.
The source note’s term “blast radius” refers here to the possible extent of damage following account compromise or a mistake. Limiting that extent is a security objective, not a guarantee that misuse of elevated permissions cannot cause harm.
The infographic associates IAM with employees, customers and vendors. That is a useful starting point, but not the complete scope. Systems also use application, service and automation identities. Microsoft describes these as workload identities.
PAM is concerned with the privileged access exercised by those identities. It may be used by an administrator, an external technician or a software deployment process. The same person can have both ordinary and administrative access.
Not every technical account is privileged. An application reading one file and an automation process capable of changing an entire environment require different assessments. Machine identities should not be assumed to use the same interactive MFA approval process as people.
The source material contrasts email and applications with servers, databases and administrative consoles. In practice, the more useful distinction is what the identity can do within the system.
NIST describes a privileged user by their ability to perform security-relevant, administrative or control functions unavailable to ordinary users. See the NIST definition.
CCyber example: an HR employee may legitimately read confidential documents without being authorized to grant other people access. An administrator of the same application may change roles and security settings. Both access types need protection, but they do not imply identical permissions or the same PAM implementation.
IAM does not stop at creating an account. It includes job changes, departures and verification that access is still needed. Approvals and time-limited access can also apply outside PAM. Examples appear in the Microsoft Entra governance documentation.
Within PAM, additional controls can govern activation for a specific task, justification, approval and duration. Eligibility to request a role should be distinguished from an active administrative role.
Practical implication: a contractor might retain an account for three months but have administrative access only during approved maintenance. Account lifetime and the duration of elevated permissions are different things.
The infographic assigns “Who signed in?” to IAM and “Which commands were executed?” to PAM. This is a useful simplification, but IAM auditing also covers permission changes and access decisions. NCSC includes activity records and protection against tampering in its IAM guidance.
For privileged access, the organization needs to connect a person or process with permission activation and operations on the target. A session recording may provide one source. It does not automatically replace application logs or records of API activity.
Product-scope example: the HashiCorp Boundary documentation identifies supported session types and recording requirements. This does not establish coverage of every action outside the configured access path.
The infographic lists Okta, Azure AD, ForgeRock and Ping Identity under IAM, and CyberArk, BeyondTrust, Delinea and HashiCorp under PAM. Treat these as examples from the source material, not a ranking or evidence that vendor offerings belong to mutually exclusive categories.
Azure AD has been renamed Microsoft Entra ID. This does not also rename on-premises Windows Server Active Directory. The distinction is explained in Microsoft’s documentation.
Specify the actual product rather than the vendor alone. For example, HashiCorp Vault provides capabilities including secrets management, while Boundary supports remote access control and recording of supported sessions. The name “HashiCorp” does not identify which capabilities have been purchased.
CCyber recommendation: compare requirements, integrations, limitations and licensing rather than logos. Identity and privileged-access functions may exist within the same ecosystem.
The source associates IAM with SSO, MFA and RBAC: shared sign-in across services, multi-factor authentication and role-based access control. PAM is associated with on-demand access, approvals and session recording.
These mechanisms are not exclusive to one side. Administrators also need strong authentication, while ordinary application access can require approval and expire after a defined period.
One example of this overlap is Microsoft Entra Privileged Identity Management. PIM supports time-bound role activation, approvals, MFA and audit history. Its scope must be checked against the actual resources rather than inferred from the feature’s name.
The identity platform has administrators of its own. Someone able to create identities, change authentication rules or assign roles can affect access to other resources. Microsoft distinguishes this level of control in its enterprise access model.
CCyber recommendation: include administration of the identity directory and the PAM platform in the first privileged-access review, not only servers and databases. Check who can change access rules, disable required approvals or alter activity recording.
Do not assess these permissions solely by account count. One role capable of assigning other roles may require more attention than many narrowly scoped accounts.
Illustrative CCyber scenario. A company asks a provider to repair its finance application. The technician needs one administrative function, not control of the entire infrastructure. The following describes a target process to design and verify, not capabilities guaranteed by every product.
The company confirms the person, provider and internal sponsor. The account receives a defined validity period and access to the support portal. Signing in does not itself grant permission to change the finance application.
The register identifies who reports the end of the relationship. The account does not remain active merely because nobody remembers who created it.
The technician requests access linked to the repair ticket. The owner approves a specified function for 60 minutes. This duration is an assumption in the example, not a universal requirement.
Activation requires the agreed authentication and an appropriate device. The target system enforces the permitted scope. Where a technical account is used, its operation must allow activities to be attributed to the technician.
Session recording or application logs document operations within the agreed scope. Limiting duration should not be confused with limiting functionality: full administration for an hour still means full administration during that hour.
When the administrative window closes, the company verifies that the technician can no longer perform privileged operations. At the end of the contract, the remaining access is also removed.
Do not assume every session ends immediately. Microsoft explains that effective access removal also depends on tokens and application behaviour. Disabling an account in one place does not always immediately invalidate a session elsewhere. See the access revocation documentation.
Acceptance should therefore concern the ability to act in the application, not only the status displayed in a central console.
The following template is a CCyber recommendation for integration design. Prepare one record for a selected access path.
Identity and owner: who uses the access, what confirms their relationship with the organization and who reports changes?
Resource and permitted action: which application or system is the target, and exactly what can be performed?
Activation conditions: which authentication, device, justification or approval is required?
Duration and termination: when does the permission expire, what happens to an open session and how is urgent revocation handled?
Alternative paths: does a local account, direct connection, key or another route bypass the designed process?
Evidence: where can identity, decision, activation, activity and termination be connected? Who may review that information?
Acceptance criterion: an agreed test demonstrates both successful execution of an allowed action and denial of an out-of-scope action. It also covers removal, not only successful access provisioning.
Use agreed test accounts and resources. Do not alter production-account permissions without assessing dependencies and preparing a recovery plan.
Recovering control of the environment should not depend exclusively on the same mechanism that may have failed. Microsoft documents emergency accounts, their protection, monitoring and testing in its emergency access guidance.
CCyber recommendation: separately define emergency-use conditions, authorized people and review of the resulting activities. Do not label every permanent administrator account an exception “just in case”. Equally, do not remove every such access path without checking the ability to recover the environment.
Prioritize the gap, not the product label. Where a company does not know who has accounts or when access should be removed, identity lifecycle management needs attention. Where administrators have unjustified control of an entire environment, reducing that exposure should not wait for a large IAM programme to finish.
We recommend starting with one important service. Identify its identities, ordinary roles and privileged operations. Review existing capabilities, integrations and gaps. Then determine whether you need another product, an extension to an existing service or a process improvement.
The application owner should define the necessary activity scope. IAM, PAM and administration teams agree how it will be delivered. Security helps establish requirements and verification. This is a proposed division of responsibilities, not a mandatory organizational structure.
Success is not measured by the number of accounts moved into a vault. In our proposed review, the important questions are whether access has an owner, is limited to the task and can be effectively terminated.
The Identity, Access and Cloud Security category includes further guides on nine foundational PAM controls, Just-in-Time and Just-Enough Access, and preparing an audit trail for privileged access. The linked category is in Polish.
This article focuses on the differences and interaction between disciplines. A detailed control set or complete audit trail requires further adaptation to the environment.
Through its cybersecurity project and implementation services, CCyber supports risk assessment and IAM, PAM and MFA deployments.
Identify where your current access controls stop. To scope assistance, prepare a list of important applications, administrative roles and existing tools. A useful starting point is one complete scenario: identity creation, permission use and verified access removal.
Owning an IAM product does not settle the question. Check which privileged-access safeguards actually operate. They may be part of an existing platform, but the required scope and remaining gaps need separate assessment.
Terminology can vary between providers. Microsoft Entra PIM is a specific service for managing and activating roles. It can support a PAM programme, but role activation alone does not establish recording of every action or coverage of every system. Verify the product and integration scope.
No. Authentication helps establish identity. It does not by itself determine whether the account should be able to delete data, assign roles or disable safeguards. Permission scope requires a separate decision.
We do not prescribe that as a universal rule. Select recording coverage according to risk, requirements and technical capabilities. Define the necessary logs, any session recordings, review permissions and retention. A recording should not be the sole evidence of system behaviour.
Company size alone cannot answer that. Start with administrative operations, provider access and existing capabilities. Select a solution for the missing functions rather than assuming every issue requires another platform.
IAM and PAM answer connected questions about identities, permissions and their use. IAM provides the broader access-management discipline, while PAM adds protection for privileged operations.
The essential outcome is an end-to-end process: the right identity, justified scope, controlled use and effective termination. Where any stage remains uncontrolled, owning both categories of tools does not eliminate the gap.
Microsoft 365 Backups: 8 Best Practices and a Recovery Test
How should Microsoft 365 backups be configured to recover the data your business needs, rather than merely produce successful backup reports? This guide covers eight practices: Exchange, OneDrive, SharePoint and Teams data coverage, capacity, backup independence, frequency, retention, versioning, administrator access and testing. It also includes a recovery test scenario, acceptance criteria and a 30-day action plan. Learn how Microsoft 365 capabilities differ from the features of individual backup solutions.
Prepared by: CCyber Editorial Team
A useful Microsoft 365 backup should recover the right data, from an appropriate point in time, to a usable destination and within the time the business can tolerate. A successful backup-job notification does not establish all these conditions.
Start with the scope: Exchange Online mailboxes, OneDrive accounts, SharePoint sites and the specific data used in Teams. Then define frequency, retention, protection against backup destruction, administrator access and recovery procedures. Evaluate Microsoft’s native service, a third-party product or a combination against the same business requirements.
19 September 2026
The starting point is Xopero’s guide to Microsoft 365 backup practices. Service capabilities were checked against Microsoft documentation and guidance from cybersecurity authorities. The acceptance criteria, test scenario and schedule below are CCyber recommendations, not guarantees about a particular product.
Microsoft 365 administrators, IT managers, business owners and people overseeing outsourced IT support. It is particularly relevant to organizations that already run backups but have not verified completeness, permissions after restoration or the time required to resume work.
Microsoft 365 provides recovery mechanisms and a separate paid service called Microsoft 365 Backup. Activating that service requires billing configuration and protection policies. Do not assume that an email and application subscription automatically includes an active backup service. The process is described in the Microsoft 365 Backup setup documentation.
Recycle bins and version history help with certain user mistakes. Microsoft Purview retention preserves or deletes content according to defined rules. Legal holds and eDiscovery are not the same process as rapid bulk recovery after an incident. The distinction is explained in the Microsoft 365 Backup FAQ.
This article focuses on configuring and verifying protection. The broader rationale is covered in “Backup Microsoft 365: dlaczego sama chmura nie wystarczy”, available in CCyber’s Identity, Access and Cloud Security category.
Instead of writing “back up all users”, identify the data that needs protection. Include email, shared mailboxes and archives, personal and team documents, SharePoint lists and important collaboration materials. Check support for each item in the selected solution.
Teams requires separate clarification. Files uploaded to channels are stored in SharePoint, while files sent through chats are stored in the sender’s OneDrive. This does not establish that messages, team structure and permissions can also be restored. File locations are explained in the Microsoft Teams documentation.
Plan identity and configuration recovery separately. Document backups should not be presented as evidence that the entire environment’s configuration is protected.
Also check new accounts and sites. In Microsoft 365 Backup, selecting a group through a filter can create a static list, while dynamic rules are a separate mechanism. See the protection policy documentation.
Acceptance criterion: for every important data type, the organization knows whether it is protected, when protection started, where it can be restored and which exclusions remain.
Collect the sizes of mailboxes, archives, OneDrive accounts and SharePoint sites. Review data growth and how deleted items and versions are charged. Do not assume backup cost is always proportional only to employee count.
Microsoft 365 Backup uses consumption-based billing for protected content. Its documentation explains that certain deleted and versioned data are included, while basic usage reports do not show every component needed for an estimate. Refer to Microsoft’s pricing model and calculator guidance.
When comparing proposals, also ask about storage, additional copies, data exports, recovery assistance and contract termination. These are questions for the individual agreement, not charges automatically imposed by every provider.
Acceptance criterion: the budget covers the agreed scope, anticipated data growth, operation and testing. Assumptions are documented rather than hidden within one “per-user” price.
The 3-2-1 rule needs a precise interpretation: three copies of the data, including production data and two backups, at least two storage technologies and one copy in a different location. “Two” does not simply mean two folders. A practical explanation is provided in CERT Polska’s backup guidance.
For cloud environments, also examine shared dependencies: administrator accounts, deletion permissions, encryption keys and access recovery. Two copies in different clouds can still depend on one compromised account.
Microsoft describes its backup storage as remaining within the Microsoft 365 trust boundary, with protection against overwriting. Backup deletion has separate rules associated with offboarding. Remaining in one ecosystem therefore does not automatically mean an absence of safeguards, but neither does it provide independence from every ecosystem failure. See the Microsoft 365 Backup architecture overview.
Acceptance criterion: identify which event could simultaneously threaten production data, backups and recovery access, and which safeguards limit that scenario.
RPO defines the point to which data must be recovered following a disruption. In practice, it helps establish the acceptable gap in data currency. RTO concerns the time within which operation needs to be restored. Definitions are available in the NIST glossary for RPO and RTO.
The source article suggests less frequent backups for less active users. This should not be implemented solely on the basis of change volume. A rarely edited document can still be critical to the company.
Agree requirements with the process owner, then check the recovery points actually available. Their spacing can depend on the workload and the age of the data. Microsoft 365 Backup documentation distinguishes Exchange from SharePoint and OneDrive in this respect.
Acceptance criterion: an available, usable recovery point meets the agreed RPO. A job schedule is insufficient where backups fail or remain incomplete.
Set backup retention according to recovery needs, data requirements and how long it may take the business to discover a loss. Do not apply one period to every information type without justification.
93 days is not a universal protection limit for all Microsoft 365 data. Microsoft specifies that period for items in SharePoint recycle bins, counted from deletion from the original location. It is not a separate 93 days for each recycle-bin stage. See the SharePoint recovery guidance.
Microsoft Purview policies can retain content under separate periods and rules. These should not be confused with the backup product’s retention. Retention and deletion behaviour is explained in the Microsoft Purview documentation.
Before deleting an employee account, verify data handover, access to existing backups and the recovery procedure. Do not assume removing a licence, deleting an account and ending backup protection have identical consequences.
Acceptance criterion: the company knows the oldest required recovery point and how data will be handled after an employee leaves or the backup contract ends.
Version history, retention and backups can complement one another. Microsoft explains that versioning supports recovery of previous content but differs from large-scale restoration after a significant incident. Do not disable it merely because backup has been purchased.
Verify recovery of an individual message, file or folder and a larger scope. Establish whether the operation overwrites current content, creates a copy elsewhere, preserves required metadata and avoids disclosing information to the wrong people.
A new account, a new site URL and a different tenant are different recovery destinations. A tenant is a separate organizational environment in Microsoft 365. Support for one option does not establish support for the others. Require product-specific documentation and a test of the scenario you need.
Acceptance criterion: recovering one item does not require an unapproved rollback of the entire team’s work, and the limitations of wider restoration are known before an incident.
Separate everyday work from backup administration. Use named accounts, strong authentication and roles limited to the required activities. Also review integration application permissions, technical credentials and their renewal arrangements.
Microsoft recommends least-privileged roles and documents a dedicated backup administrator role. Notifications about important changes should also be enabled. Their delivery channel and frequency must be understood rather than assumed to provide immediate alerting.
An onmicrosoft.com account is not a separate tenant or an independent backup. A cloud-only emergency account can reduce dependencies on federation or on-premises infrastructure. Microsoft recommends strong phishing-resistant authentication, monitoring and regular validation for these accounts. See the emergency access account guidance.
Acceptance criterion: an authorized person can initiate recovery when the normal administrator account is unavailable. That path is protected and tested, not based on a password stored in a publicly accessible document.
Xopero recommends regular restores into a test environment. This must be adapted to supported recovery methods, licensing and data-handling requirements. Do not assume every product can restore all data into another tenant.
As a starting point, CCyber recommends a test after protection is enabled, an agreed recurring schedule, such as quarterly for selected services, and additional checks after significant changes. Frequency should reflect risk. Restoring one file does not establish performance for hundreds of mailboxes.
Continuously check for missing recovery points, accounts or sites removed from protection and integration failures. Notifications need a recipient, a deputy and a response deadline.
Regular testing of backup availability and integrity is also recommended in the CISA #StopRansomware Guide.
Acceptance criterion: the last successful test, its scope and outstanding remediation are known. “Backup completed” and “recovery verified” are not treated as the same status.
The following scenario is a CCyber recommendation. Use agreed test resources, without running ransomware or deliberately destroying production data.
Prepare a controlled dataset: a message with an attachment, a document with several versions and a folder with differentiated permissions. Record the expected content, an authorized user and someone who should not gain access.
Agree the required recovery point, permitted duration and destination. Confirm that the chosen recovery mode is supported. Where a separate tenant is required, establish support before starting the test.
Confirm that protection has captured the data, then perform an agreed change or deletion only within the test dataset. Select a point preceding that change. Record its timestamp and scope.
Include an older recovery point as well. Testing only the latest backup does not establish what happens when data loss is discovered much later.
Verify content, attachments, required metadata and permissions. Confirm that the agreed business activity can be performed, such as the correct person reading a proposal and its attachment.
Record the tool’s operation time separately from the overall exercise, including notification, decisions, obtaining access and confirming the result. Compare RTO against the previously agreed measurement scope, not merely the copying time.
The record should identify scope, date, operator, recovery point, duration, access-control results and limitations. Assign an owner, deadline and retest to each gap.
After acceptance, remove additional test copies under the agreed rules. Do not leave confidential materials in a less protected location simply because the test succeeded.
Illustrative scenario. A company sets a one-hour RPO and a four-hour RTO for a document library. During an exercise, the simulated incident occurs at 10:00, but the newest usable recovery point is from 08:00.
Restoration finishes quickly and the user can resume work. However, the potential data-loss window is two hours, exceeding the agreed one hour. A positive recovery-time result does not resolve that discrepancy.
The issue may concern frequency, error handling or protection scope. Purchasing faster storage is not automatically the answer when the problem is a missing recovery point.
Agree important services, data, RPO and RTO. Compare them with actual protection. Record unsupported items, accounts omitted from policies and unresolved dependencies.
Address coverage, retention, administrator roles and notifications. Agree error handling, out-of-hours recovery and access to data after contract termination with the provider.
Run the agreed test, validate the business result and present outstanding gaps. Approve further actions and a recurring review schedule. This plan organizes implementation but does not guarantee that every task can be completed within a month.
Instead of reporting only completed backup jobs, show which important services have protection and a usable recovery point meeting their requirements, when recovery was tested and which exclusions remain open.
Distinguish three states: protected and verified, protected but unverified, and unprotected or unknown. Reporting should support decisions about risk and resources rather than conceal gaps behind one success percentage.
The Identity, Access and Cloud Security category also includes articles about privileged accounts and audit trails. For broader recovery planning, see the material on incident response and business continuity. These links lead to Polish-language resources.
Through its secure IT deployment services, CCyber supports security, access and backup configuration, including for Microsoft 365.
Check whether your backups meet your actual recovery needs. A list of protected services, agreed RPO and RTO, and the latest test result can provide a starting point for defining support. Do not send credentials or copies of company documents before agreeing secure working arrangements.
There is no single answer for every company. Microsoft offers its own backup service, and third-party solutions are available. Selection should consider scope, retention, recovery methods and required independence. A third-party product may itself use Microsoft 365 Backup Storage.
Only where the recovery points actually available match acceptable data loss. For a process that cannot lose more than one hour of changes, one daily backup does not meet that requirement.
Do not assume so. File protection differs from restoring communications, configuration and collaboration structure. Check supported data types and the test results for the particular solution.
No. This depends on the product, data type and service conditions. Recovery to a new site URL or another account within the same organization does not establish support for a separate tenant.
It supports data recovery but does not remove the cause of compromise or reverse prior data theft. Restoration must be combined with incident containment and validation of the destination environment, following response practices such as those described by CISA.
Microsoft 365 backup best practices begin with recovery requirements and end with a verified result. Between them are coverage, capacity, backup independence, frequency, retention, versioning and access control.
Do not ask only whether a backup completed. Establish whether the right people can recover the right data within the required time, without unapproved loss of changes or excessive access. That result demonstrates whether the implementation meets the business need.
How to Prepare an Audit Trail for Privileged Access?
An audit trail for privileged access is not just a system log. It is a complete evidence chain showing who had privileges, who approved them, when they were activated, for what reason, from which device, what actions were performed, whether the session was monitored, whether access was removed and whether logs are protected from modification. A good audit trail connects IAM, PAM, PIM, SIEM, system logs, cloud logs, ticketing, access reviews, session recordings and business owner decisions. The key question is: after an incident, can we reconstruct the full history of privileged account use?
Prepared by: CCyber Editorial Team
An audit trail for privileged access should answer six questions: who had access, who approved it, when it was used, why it was used, what was done and whether access was later removed. The information that “an administrator logged in” is not enough. Data from IAM, PAM, PIM, ticketing, SIEM, cloud logs, system logs, application logs, session recordings and access reviews must be connected. A good audit trail covers the full access lifecycle: granting, activation, approval, use, actions during the session, configuration changes, data downloads, session end, permission expiration, review and any remediation actions.
July 2026
An audit trail is an evidence chain. In the context of privileged access, it shows how a permission was created, who approved it, when it was used, what actions were performed and whether the whole process followed company rules.
Privileged access includes accounts, roles and permissions that can change configuration, grant rights to others, read sensitive data, delete data, disable safeguards, manage cloud environments, run commands on servers or affect business continuity.
The audit trail should prove that this access was granted intentionally, used for an approved purpose, monitored and later reduced or removed.
A privileged account can change everything. It can add a user, disable MFA, change an access policy, delete backup, download data, expose a resource publicly, disable logging or grant access to an attacker. This is why after an incident the key question is: what did the privileged account do?
Without an audit trail, the company often knows only that “something happened”. It does not know who made the change, whether they had the right to do it, whether the action was part of a plan or a sign of an attack.
Login logs are part of an audit trail, but not the whole audit trail. A single log saying “user X logged in at 10:14” is not enough. An auditor, customer or incident response team will ask much more.
Every privileged access should have a reason. It may be a service ticket, change request, failure, deployment, incident or scheduled administrative window.
Privileged access should not result only from the administrator’s own decision. It should be approved by the right person: system owner, manager, security, process owner or on-call approver in emergency mode.
Best practice is just-in-time access. The user is eligible, meaning they can activate a role after meeting conditions, but they do not have permanent active access.
The audit trail should show context. This helps distinguish normal administrator work from suspicious activity.
The most important point is what the administrator did after receiving privileges. A login without action logs is weak evidence.
For high-risk actions, it is useful to have a session recording, command log or full action record in PAM. This especially applies to suppliers, critical system administrators and jump server sessions.
The audit trail should show that access was not left permanently. If it was time-bound, it should expire. If it was emergency access, it should be formally closed.
The best audit trail does not end with logs. It should be periodically reviewed. Someone must check whether roles are still needed and whether privileged access was used according to rules.
Every privileged access event should contain a set of fields that allow it to be connected with a person, process and action.
If logs are stored only on the system managed by the administrator, they may be changed or deleted by the same person or by an attacker using that person’s privileges.
The auditor sees role activation, but not why it was needed. Without a ticket, it is hard to distinguish planned change from abuse.
Administrator login is visible, but the changes performed are not. This is not enough to explain an incident.
An “admin”, “root”, “service” or “vendor” account makes accountability difficult. After an incident, the company does not know which person used the account.
Service accounts, service principals, managed identities and API keys often have broad privileges while being poorly monitored.
Logs are collected, but nobody reads them. The company learns about the problem only after the incident.
An incident may be detected after weeks or months. If logs are stored only for 7 or 30 days, the company may lose the ability to reconstruct events.
The worst scenario is an administrator or attacker using that account being able to disable logging or delete logs.
The company should have a clear definition. Without it, some people treat only global admin accounts as privileged, while others also include service accounts, subscription owners, application administrators and suppliers.
You cannot audit what you cannot see. The register should include people, suppliers, technical accounts, applications and cloud roles.
For every system, define where logs come from: IAM, PAM, PIM, operating system, application, cloud, database, ticketing and SIEM.
Every high-risk activation should have justification and a ticket number. This supports audit and incident analysis.
Standing privileged access increases risk. Time-bound access creates a better audit trail because it enforces an activation moment, justification and often approval.
Logs must resist modification and deletion. Access to logs should be restricted, and logging configuration changes should generate alerts.
An audit trail should not be only an archive. It should support detection of events requiring response.
The audit trail shows who uses permissions. Access review shows whether they should still have them.
There is no universal answer. Retention depends on risk, regulations, contracts, industry, storage cost and incident detection time. For privileged access, longer retention than standard diagnostic logs is often appropriate.
Retention should be formally approved. The company should know which logs are needed for audit, which for incident response and which for customer requirements.
The best way is a reconstruction exercise. Choose one administrator account, one role activation or one change ticket and check whether you can rebuild the full trail.
Break glass accounts are necessary, but very risky. They are meant to allow emergency access when standard mechanisms fail. However, they cannot sit outside the audit trail.
IT providers, MSPs and integrators often have privileged access to customer environments. This requires special accountability. A supplier account should not be a black box.
A SaaS company uses Microsoft Entra ID, Azure, GitHub, CI/CD system, database and customer support tool. It has several administrators and an external DevOps provider. The board assumes the audit trail works because “we have cloud logs”.
During a mock audit, it turns out administrator sign-ins are visible, but not all actions are linked to tickets. Roles are permanently active. The supplier uses one shared account. PIM logs have short retention. Session recordings do not exist. Access review has not been done for nine months.
The company implements PIM for critical roles, requires MFA and activation justification, adds ticket numbers, moves logs to a central SIEM, introduces named accounts for the supplier and performs the first access review. After 90 days, the company can show a full trail: request, approval, activation, actions, logs and access removal.
ccyber.io helps companies prepare audit trails for privileged access in cloud, hybrid and SaaS environments. We combine IAM, PAM, PIM, SIEM, compliance, audit and incident response perspectives.
We can support your organization with:
The best first step is a Privileged Access Audit Trail Workshop. In a short workshop, the company can define which accounts matter most, which logs already exist, where evidence gaps are and whether the company can reconstruct administrator account use history.
No. Logs are part of the audit trail. The audit trail also includes access request, approval, justification, activation, actions, session, access expiration, review and process evidence.
The most important thing is connecting person, permission, purpose, approval and actions performed. The auditor should see the full history, not a single login log.
Not always, but recording is valuable for critical systems, suppliers, break glass accounts and high-risk actions.
It depends on risk, regulations and contracts. In practice, privileged access logs are often worth retaining for at least 12 months, and longer for critical systems if audits or contracts require it.
PIM helps significantly because it provides activation, justification, approval and history. But it is not enough alone if you do not collect action logs from target systems and do not link activation with tickets.
You need a register, owner, permission scope, usage monitoring, secret rotation, alerts for unusual use and regular review of unused accounts and keys.
Start with a critical role register, MFA for administrators, centralized logs, ticket requirement during activation and a reconstruction test of one administrator’s activity history.
Select one high-risk change and try to reconstruct the full history: request, approval, activation, MFA, actions, logs, completion and review. Gaps will show what must be improved.
An audit trail for privileged access is one of the most important elements of identity and cloud control. Without it, the company does not know who truly had power over systems, what they did and whether the action was authorized.
A good audit trail connects IAM, PAM, PIM, SIEM, cloud logs, system logs, ticketing, session recordings, access reviews and owner decisions. It creates the most value when logs are complete, centralized, protected from modification and reconstructable after an incident.
The best rule is: do not ask only whether we have logs. Ask whether after an incident we can prove who requested access, who approved it, when it was used, what exactly was done and whether access was removed.
Microsoft 365 Backup: Why Cloud Alone Is Not Enough
Microsoft 365 provides high availability, infrastructure resilience and multiple recovery mechanisms, but cloud alone does not replace a backup strategy. The company is still responsible for data, accounts, permissions, retention, user mistakes, malicious deletions, ransomware, incident recovery and audit evidence. Microsoft 365 backup should cover Exchange, OneDrive, SharePoint, Teams, configuration, permissions, restore testing, RTO, RPO and protection against backup deletion.
Prepared by: CCyber Editorial Team
Microsoft 365 is a highly available cloud service, but this does not mean the company does not need a backup strategy. Microsoft is responsible for infrastructure, service availability and platform resilience, but the organization remains responsible for its data, users, accounts, configuration, permissions, retention, mistakes, malicious activity, ransomware and audit requirements. Recycle bin, versioning, retention and eDiscovery are important, but they are not the same as full operational backup. A good Microsoft 365 backup should answer: what do we protect, for how long, how quickly can we restore, who can delete backups, is the backup resistant to administrator account compromise and when was the last restore test performed.
July 2026
Many companies assume that because data is in Microsoft 365, it is automatically safe. This is partly true, but only in relation to service resilience. Microsoft manages infrastructure, replication, availability, data centers and many platform protection mechanisms. The company must still manage what happens to its data and accounts.
Cloud can protect against a server failure in a local server room, but it may not always protect the company against:
The key difference: Microsoft is responsible for the platform operation, while the company is responsible for data use, configuration, access, retention, classification and recovery readiness.
Microsoft 365 works under a shared responsibility model. This means part of responsibility sits with the cloud provider and part with the customer.
Microsoft 365 backup should not be treated as distrust of cloud. It is part of the customer’s responsibility for their own data and business continuity.
Microsoft 365 has many mechanisms that help recover data. These are very important features. The problem starts when the company treats them as full backup.
Recycle bin helps recover recently deleted files, folders or items. However, it has limited retention time and may not help if data was deleted long ago, removed from many locations or deleted as part of malicious activity.
Versioning helps restore an earlier file version. It can be useful after wrong edits or overwrite. It is not a full strategy for restoring an entire site, mailbox, team or large part of a tenant after an incident.
Retention mainly supports information governance, compliance, eDiscovery and preservation requirements. It can preserve copies of content according to policy, but it does not always answer the need for fast operational restore after ransomware or wrong deletion.
eDiscovery helps find and preserve data for legal, audit or investigation purposes. It is not a tool for quickly restoring operations for sales, finance or customer service.
Backup should make it possible to restore data to a usable state after a mistake, incident, malicious action or process failure. Good backup is designed around RTO, RPO, data scope, copy protection, testing and restore procedures.
Microsoft 365 is not one database. It is a set of connected services. Backup should reflect how the company actually works.
Teams is especially important because Teams data is distributed. Channel files are stored in SharePoint, chat files usually in OneDrive, and teams are connected with Microsoft 365 Groups, permissions, channels, meetings and other services. Therefore, Teams backup must be understood more broadly than “backup the Teams app”.
In practice, check whether backup covers:
Backing up data is one thing. Preserving knowledge about configuration and permissions is also important. After an incident, the company must know not only which files to recover, but also who should have access to them.
It is worth documenting or backing up:
A user deletes a folder, file, message, team, channel or site. The issue becomes serious when the mistake is discovered late or affects many items.
An employee, former employee, supplier or compromised account intentionally deletes data. This may affect customer files, mailboxes, documentation, project teams or financial data.
Ransomware may encrypt local files synchronized with OneDrive and SharePoint. Encrypted versions may then synchronize to cloud, and the issue may affect many libraries and users.
An attacker with administrator access can change configuration, delete data, modify retention rules, disable controls, remove backup or make recovery harder.
An incorrect retention policy may delete data faster than expected or keep data too long and create legal risk.
After an employee leaves, the company may lose access to important files in OneDrive if it has no process for ownership transfer, archiving and backup.
Migration into Microsoft 365, between tenants or between SharePoint structures may lead to loss of metadata, permissions, versions or some data.
Deleting a team may affect the group, SharePoint, files, permissions and project context. Restoring files alone may not restore the full collaboration structure.
RTO, or Recovery Time Objective, means the maximum acceptable restore time. It answers: how quickly must we restore data or service?
Example: finance must recover the mailbox and payment files within 4 hours.
RPO, or Recovery Point Objective, means the maximum acceptable data loss in time. It answers: which point in time must we be able to return to?
Example: the company accepts losing no more than 4 hours of work on sales documents.
Without RTO and RPO, backup is only a technical copy. With RTO and RPO, backup becomes part of business continuity. The board does not need “we have a copy”. The board needs “we can recover critical data within the required time”.
Backup is used to restore data after a mistake, incident, ransomware, deletion or process failure. It focuses on operational recovery.
Archiving is used for long-term data preservation, often for legal, tax, historical or business reasons.
Retention defines how long data should be kept or when it should be deleted. It matters for compliance and information governance.
The company confuses retention with backup. Retention may help preserve data, but it does not always provide fast, convenient and complete operational recovery after an incident.
The company should know which services and data are protected. Do not assume backup covers everything.
Backup should create restore points at a frequency aligned with risk. Finance may need a different RPO than the marketing archive.
The company should be able to restore a single email, file, folder, mailbox, site, OneDrive account or larger data set.
After ransomware, the company may need to restore many accounts, mailboxes, libraries or sites. The tool should support scale, not only one-file recovery.
Backup should be protected from the user account, normal administrator and attacker. MFA, roles, administrative separation, alerts and mechanisms making backup deletion harder are especially important.
If the same administrative accounts manage production and backup, an attacker may try to take over both. Backup should have a separate access model and stronger controls.
Backup without testing is an assumption, not evidence. The company should regularly verify that it can restore data within the required time.
Backup should generate evidence: what is protected, when backup ran, when restore ran, who approved it and what the test result was.
Backup must consider data location, retention, GDPR, customer contracts, industry requirements and data deletion rules.
The company should know who decides on restore, who approves scope, how to check data cleanliness and how to avoid restoring the problem.
The company may use native Microsoft mechanisms, Microsoft 365 Backup or partner and third-party solutions. There is no single answer for everyone. The choice should follow risk, data scope, RTO, RPO, legal requirements, budget and IT operating capability.
Do not ask “which tool is best?”. Ask: which recovery scenario must we handle, within what time, for which data and with what evidence?
Not all data has the same value. Start with data the company cannot operate without.
Evidence to prepare: critical Microsoft 365 data list with business owners.
Determine where the data actually is. Teams, SharePoint, OneDrive and Exchange are connected, and one business process may use several locations at once.
Check:
Evidence to prepare: Microsoft 365 data location map.
For every critical process, define how quickly data must be restored and how much data loss the company can accept.
Example:
Evidence to prepare: RTO and RPO table for Microsoft 365 data.
The scope should follow risk and data criticality. Do not automatically assume everything needs the same protection level.
Evidence to prepare: formal Microsoft 365 backup scope.
Backup should be protected as seriously as the production system, and sometimes even more strongly. An account that can delete backup is a highest-risk account.
Define:
Evidence to prepare: Microsoft 365 backup role and permission matrix.
Backup retention should follow operational and legal needs. Short retention may not be enough if a problem is discovered after several months. Too-long retention may increase costs and data risk.
Define:
Evidence to prepare: Microsoft 365 backup retention policy.
Restore should not be improvised during an incident. The company should have procedures for the most common scenarios.
Evidence to prepare: Microsoft 365 restore playbook.
The test should verify not only whether the tool works, but whether the company can restore data according to RTO and RPO.
Test:
Evidence to prepare: restore test report with time, scope, result and findings.
Backup is part of incident response. In ransomware, account takeover or mass deletion, the company must know what to do before restore.
The plan should cover:
Evidence to prepare: Microsoft 365 incident playbook with backup and restore section.
Ransomware in Microsoft 365 usually does not mean that Microsoft 365 as a service stops working. The problem may be that the attacker encrypts files on a user device and the changed files synchronize with OneDrive or SharePoint. Another scenario is account takeover and mass deletion or overwrite.
Employee departure is a common data loss scenario. Many important files live in the user’s OneDrive, not in a formal team site. If the company has no data handover process, it may lose project knowledge, contracts, analyses and work history.
Backup does not replace offboarding, but it can significantly reduce data loss risk after a key person leaves.
For compliance, what matters is not only that data exists. What matters is whether the company can prove control over recovery process, retention, access and exceptions.
Microsoft 365 has many resilience and recovery mechanisms, but the company still needs to define its own backup, restore, retention and data responsibility strategy.
Retention helps meet data preservation requirements, but it does not always provide fast and convenient operational recovery after an incident.
The company has a backup tool, but never checked whether it can restore a mailbox, site or data after mass deletion.
If the backup administrator has no MFA or can delete copies without additional controls, backup may be destroyed during an attack.
Many important data sets are in OneDrive. Without offboarding, the company may lose data after deleting a user account.
Teams is connected to SharePoint, OneDrive, Exchange and Microsoft 365 Groups. Backing up files alone may not be enough to restore collaboration context.
Without RTO and RPO, the company does not know whether backup meets business needs. It may have a copy but restore too slowly.
The board often learns about backup problems only after an incident. Regular reporting enables earlier risk and budget decisions.
Some incidents are detected after weeks or months. Retention that is too short may prevent return to a healthy data point.
After ransomware, clicking restore is not enough. Accounts, devices, sessions and data must not still be under attacker control.
A services company uses Microsoft 365 as its main work environment. Email is in Exchange Online, customer documents are in SharePoint, employee files are in OneDrive, and projects run in Teams. The board assumes that because everything is in cloud, backup is not needed.
After one user account is compromised, files in several SharePoint libraries are massively deleted and overwritten. IT tries to recover data from recycle bin and versions, but quickly discovers that the issue affects many locations, some data is already outside simple recovery scope, and the company has no list of critical sites, RTO, RPO or restore procedure.
After the incident, the company implements a Microsoft 365 backup strategy. It creates a critical data list, covers Exchange, OneDrive and SharePoint with backup, organizes Teams, restricts administrator roles, enables MFA, prepares a restore playbook and performs quarterly restore tests.
The most important change: the board stops asking “is the data in cloud?”. It starts asking “can we recover it within the required time and do we have evidence?”.
ccyber.io helps companies design and test a Microsoft 365 backup strategy. We combine security, business continuity, compliance, identity, access and real ransomware scenario perspectives.
We can support your organization with:
The best first step is a Microsoft 365 Backup Readiness Workshop. In a short workshop, the company can determine which data is critical, what is already protected, what is missing, which RTO and RPO are realistic and which restore test should be performed first.
Microsoft 365 has resilience, retention, recycle bin, versioning and recovery mechanisms, but the company should have its own backup and restore strategy aligned with risk, RTO, RPO and audit requirements.
Not as a full backup strategy. Recycle bin helps with recent deletions, but it has time, operational and scenario limitations.
Not fully. Retention matters for compliance, eDiscovery and information governance, but it does not always provide fast and complete operational restore after an incident.
At minimum, critical Exchange mailboxes, OneDrive accounts, SharePoint sites, Teams-related data, shared mailboxes, groups and selected metadata and permissions.
Yes. Teams uses multiple Microsoft 365 services. Files are connected with SharePoint and OneDrive, while teams are connected with groups, channels, memberships and permissions.
At least quarterly for critical data and after major changes, migrations, new backup tool deployment or retention changes.
Only selected people, with MFA, separate roles, activity logging, least privilege and additional approval for high-risk operations.
Start with critical data list, RTO and RPO, review of current recovery mechanisms, restore test and assessment of whether the current model meets company needs.
Microsoft 365 is a very strong cloud platform, but cloud alone does not replace a backup strategy. The company remains responsible for data, accounts, permissions, retention, recovery, testing and evidence of readiness.
Recycle bin, versioning, retention and eDiscovery are needed, but they should not be confused with operational backup. Microsoft 365 backup must address business scenarios: accidental deletion, malicious action, ransomware, account takeover, employee departure, Teams deletion and bulk data recovery.
The key rule is: do not ask only whether data is in Microsoft 365. Ask whether the company can recover it within the required time, from the right point, safely and with evidence for the board, customer, auditor or insurer.
Just-in-Time Access and Just-Enough-Access: A Simple Explanation for IT and Compliance Teams
Just-in-Time Access means access granted only for the time needed, while Just-Enough-Access means access limited only to the necessary permissions, resources or commands. Together, they help reduce standing privileges for administrators, suppliers, developers and service accounts. For IT, this lowers account takeover risk. For compliance, it proves that privileged access is justified, approved, time-bound, monitored and regularly reviewed.
Prepared by: CCyber Editorial Team
Just-in-Time Access and Just-Enough-Access are two simple ways to reduce privileged access risk. Just-in-Time Access answers: when can the user have permissions and for how long? Just-Enough-Access answers: which exact permissions are needed and for what? In practice, an administrator, supplier, developer or operator should not have standing, broad access “just in case”. They should receive access only when they have a specific task, only for a defined time, only to the right scope and only after meeting conditions such as MFA, justification, approval, trusted device, session logging and later review.
July 2026
Just-in-Time Access, or JIT, means access granted only when needed. The user does not have standing administrator privileges all the time. Instead, they can activate a role for a defined period, for example 30 minutes, 2 hours or one day, to perform a specific task.
Example: an administrator does not have the Global Administrator role permanently active. They are eligible, meaning they can request role activation. To activate it, they must use MFA, provide justification, sometimes obtain approval and complete the task within a defined time. After that time, the role expires.
Just-Enough-Access, or JEA, means access limited only to what is needed to perform the task. In practice, this may mean a narrow role, restricted resource scope, selected commands only, read-only instead of write access or access only to one application, subscription, folder, database or environment.
In Microsoft environments, the term Just Enough Administration is also used. It is a specific PowerShell technology that delegates administration so that a user can perform only approved commands and functions. In this article, we use Just-Enough-Access more broadly: as a principle of minimum access scope that can apply to cloud, systems, applications, data, code, servers and production environments.
Concerns access time.
Example: an administrator can have the Owner role in Azure for only 2 hours after MFA and approval.
Concerns access scope.
Example: an administrator can manage only one resource group, not the whole subscription.
The best model is: the user gets only the access they need, only when they need it and only for the time required to complete the task.
JIT limits the time of risk. JEA limits the scope of risk.
Standing broad permissions are convenient, but risky. If an account with such permissions is compromised, the attacker does not need to wait for approval or activate a role. They can act immediately.
JIT and JEA do not replace MFA, logs, segmentation, backup or monitoring. However, they are among the most important controls for reducing the impact of account compromise.
Compliance teams often ask: who has access, who approved it, whether it is still needed and whether the company can prove what the user did. JIT and JEA make these questions easier to answer.
JIT and JEA help show that the company does not grant access “forever” and “to everything”, but manages access according to risk, business need and least privilege.
An administrator needs to change configuration in Azure. Normally, they do not have the Owner role active. They open the access management system, select the role, provide justification, pass MFA and request activation for 2 hours. After the work is complete, the role expires automatically.
A supplier needs access to a customer server to update an application. The system owner approves access for a specific maintenance window. The supplier logs in through VPN with MFA and a jump server. The session is logged and access expires when the window ends.
A developer needs to investigate a production incident. They do not have standing production access. They receive read-only access to logs for 60 minutes. If a configuration change is required, it needs separate approval.
An administrator needs to restore selected data. The backup management role is activated temporarily. Deleting backups requires additional approval and is separately alerted.
A helpdesk employee can reset passwords for users in a specific organizational unit, but cannot change MFA configuration, administrator roles or conditional access rules.
An operator can restart a specific service on a server, but cannot browse files, change system configuration, add users or run arbitrary scripts.
A developer can view application logs and metrics, but cannot change data, run migrations, modify configuration or export the entire database.
An ERP supplier can access only the ERP environment, only through an approved path and only for service functions. They do not have access to email, backup, cloud or other systems.
A strong JIT and JEA implementation should meet both goals: reduce technical risk and create control evidence.
First, know who has high-risk access. Without this, JIT and JEA will be implemented randomly.
List:
Evidence to prepare: privileged access register with owner, scope, time and last use.
Not all access requires the same control. Treat marketing admin access differently from Global Administrator, production, backup or cloud root access.
Evidence to prepare: access risk classification.
JIT should be mandatory where standing permissions create high risk. Not everything must be changed immediately. Start with the highest-risk roles.
Evidence to prepare: list of roles covered by JIT and exception list with justification.
JEA should be mandatory where a role is too broad for the task. This is especially important in helpdesk, application administration, DevOps, production and supplier access.
Evidence to prepare: minimal role and permission scope matrix.
JIT should have conditions. Time-bound activation alone is not enough if anyone can activate a role without MFA, justification and logs.
Evidence to prepare: JIT activation policy for high-risk roles.
JEA requires specifics. It is not enough to write “least privilege”. The exact allowed actions must be defined.
Evidence to prepare: JEA role card with allowed and prohibited actions.
JIT and JEA without logs are weak from audit and incident response perspectives. The company should know when access was activated, who used it, what they did and whether actions matched the purpose.
Log:
Evidence to prepare: privileged access activation and usage report.
JIT reduces standing role risk, but it does not remove the need for access review. A person may still be eligible to activate a role even after changing teams or finishing a project.
The review should cover:
Evidence to prepare: access review for eligible roles, active roles and exceptions.
JIT and JEA must not lock the company out during a crisis. Emergency accounts, break glass procedures and emergency access rules are needed.
The emergency process should define:
Evidence to prepare: break glass procedure and emergency account test report.
Start with Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator and data access roles. Implement JIT for high-risk roles, MFA, access reviews and fewer global administrators.
Review Owner, Contributor, User Access Administrator, Key Vault Administrator, Backup Contributor and network roles. Decide which roles can be eligible, which require approval and which can be scoped to a specific subscription, resource group or resource.
Review root accounts, AdministratorAccess roles, cross-account roles, IAM, KMS access, Secrets Manager, CloudTrail, backup and production access. Reduce standing roles, use temporary sessions, permission boundaries, SCPs and narrowly scoped roles.
Review Owner, Editor, IAM Admin, Service Account Admin, Organization Admin, Project IAM Admin and secret access. Reduce broad roles, use time-bound access where available and narrow scope to project, folder or resource.
Review Domain Admins, Enterprise Admins, local administrators, administrative workstations, service accounts, supplier accounts and remote access. Introduce separate administrative accounts, administration tiering, JEA for PowerShell where useful and administrator activity monitoring.
Review who can deploy to production, change pipelines, modify secrets, disable tests, approve releases and read production data. Introduce JIT for production access and JEA for roles: log read, deploy, rollback, configuration change and secret access.
The user activates access only for one hour, but during that hour has full control over the whole tenant, subscription or production environment. This is still high risk.
The role is limited, but access is standing. If the account is compromised, the attacker can use it for a long time.
Activations without a reason are weak for audit and make misuse detection harder.
For critical roles, MFA alone may not be enough. Sometimes approval by the system owner or security is needed.
The company knows access was activated, but does not know what the user did. This is insufficient during incidents and audits.
A “temporary” exception often becomes standing access if nobody defines a review date.
Suppliers often have broad access, but are missed in JIT and JEA programmes. This is one of the most common weak spots.
An overly restrictive model without emergency accounts may make incident or outage response harder.
Compliance should be involved from the start so required evidence is collected during the process, not reconstructed before audit.
A SaaS company has IT, DevOps and several external suppliers. A review shows that 12 people have standing production access, 5 people have Owner in the cloud, a supplier has standing VPN access, and compliance has no evidence why these accesses are needed.
The company starts with a pilot. For cloud Owner roles, it introduces JIT: 2-hour activation, MFA, justification and approval. For developers, it introduces JEA: production log access is read-only by default, while configuration changes require approved change management. For the supplier, it introduces access through a jump server, only for a maintenance window, with session logging.
After 90 days, standing permissions are reduced, compliance has activation and approval reports, and IT has fewer exceptions and better visibility into administrator actions. The company can still move fast, but high-risk access is time-bound, scoped and auditable.
ccyber.io helps companies design and implement Just-in-Time Access and Just-Enough-Access in a practical, auditable and risk-based way. We combine IT, security, compliance, suppliers, cloud and business process perspectives.
We can support your organization with:
The best first step is a JIT and JEA Access Control Workshop. In a short workshop, the company can identify the riskiest roles, where standing access exists, which permissions are too broad, which evidence is needed for audit and which quick changes reduce risk in the first 30 days.
It is access granted only for the time needed to perform a specific task. After the time ends, access expires automatically or is removed.
It is access limited to the minimum scope: only the required roles, resources, commands, systems and actions. The user does not receive more permissions than the task requires.
JIT limits access time. JEA limits access scope.
Not always. If a user receives very broad permissions for a short time, risk is still high. Time-bound access should be combined with minimum scope.
Not always. Limited but standing access can still be used by an attacker after account compromise. For high-risk roles, JIT should also be used.
Usually the system owner, manager, security team or process owner. For critical roles, approval should be independent from the person requesting access.
Access request, justification, approval, activation time, role scope, MFA, activity logs, access expiration, access review and exception list.
Start with a privileged role list, MFA, removal of unjustified standing access, selecting first roles for JIT and preparing a least-privilege role matrix.
Just-in-Time Access and Just-Enough-Access are two pillars of modern privileged access management. JIT limits the time during which a user has high privileges. JEA limits the scope of what the user can do.
For IT, this means lower risk of account takeover, privilege misuse, misconfiguration and ransomware. For compliance, this means better evidence, easier audits and clear answers to: who had access, why, for how long, to what and what they did.
The best rule is: privileged access should be justified, minimal, time-bound, approved, monitored and regularly reviewed. If a company implements this first for the highest-risk roles, it quickly reduces the attack surface and improves audit readiness.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.