Security Documentation

This document provides a comprehensive overview of the security framework for Identum's products and services, including eADM and eFeide. Our security posture is built on industry best practices, robust operational procedures, and a commitment to protecting customer data.

Development and design philosophy

Our development process is guided by a "security-first" mindset, incorporating foundational principles of modern cyber security.

"Privacy by design"

Identum develops its solutions with Privacy by design as a basic philosophy. The 7 principles are:

1. Proactive not Reactive; Preventative not Remedial

2. Privacy as the Default Setting

3. Privacy Embedded into Design

4. Full Functionality - Positive-Sum, not Zero-Sum

5. End-to-End Security - Full Lifecycle Protection

6. Visibility and Transparency - Keep it Open

7. Respect for User Privacy - Keep it User-Centric

For the end customer, this means that our solutions are secure by default; privacy is built into the solution and does not need to be configured.

Zero trust

The zero trust principle in the context of Identity and Access Management (IAM) is a security model and strategy built on the concept that no user or device, whether inside or outside the organisation's network, should ever be granted de facto trust. Instead of assuming that everything behind the firewall is safe, zero trust requires that all access is continuously verified and authorised.

Here are some important aspects of the zero trust principle in connection with eADM:

1. Identity verification: Any request for access to the system requires strict verification of the user's or device's identity. This is often implemented using strong authentication methods, such as multi-factor authentication (MFA).

2. Minimisation of access: Users only get access to the resources they need to perform their tasks (the principle of least privilege). Permissions are often granular and dynamic, adjusted based on the user's needs and behaviour. This applies both to users' access to eADM and the permissions the system is set up to grant other users. Typically, needs-based access management (ABAC or JIT) will be better on sensitive systems than e.g. role-based account control (RBAC).

3. Continuous monitoring: All activity is monitored and analysed to detect suspicious or unusual behaviour. This can include unusual access patterns or attempts to gain access to sensitive data.

4. Data protection: Although identity and access management is critical, zero trust also focuses strongly on protecting data. This includes encrypting data both in transit and at rest, as well as securing data-stored access based on need.

The implementation of zero trust in eADM is central to protecting organisations against security threats by challenging traditional security model assumptions.

Data minimisation

Data minimisation is about reducing the amount of personal data and sensitive data collected, processed and stored, to what is strictly necessary to perform legitimate functions. This principle is a key component of the General Data Protection Regulation (GDPR) and other data protection laws, and it helps to reduce the risk of data breaches and privacy breaches.

1. Limited collection: Only data necessary for specific functions or services should be collected. For example, eADM does not import salary data by default, only if it is necessary for the individual customer.

2. Shorter retention periods: Data should only be stored as long as there is an operational or legal obligation . eADM has data retention policies that automatically delete or anonymise data as needed. By default, eADM uses 365 days for the retention of deactivated users, which can be adjusted for the individual customer.

3. Aggregated data instead of individual data: Whenever possible, data should be anonymised or aggregated so that processing is not based on individual identification.

4. Access control and least privilege: Implementing strict access control ensures that only authorised personnel have access to personal data, and users are only granted the rights they need.

5. Data purpose and transparency: Clear guidelines on why and how data is used, restricted to the least intrusive ways to achieve those purposes, contribute to data minimisation.

6. Pseudonymisation: If identifiable data must be used, pseudonymisation (using data aliases) can help protect people's identities and reduce the impact of potential data leaks.

By applying these principles, an eADM can support data minimisation in your organisation, thereby better protecting personal data while meeting regulatory requirements and promoting user privacy.

Operation and "Basic principles for ICT security"

On the operational side, we have based our security thinking on the Norwegian National Security Authority's basic principles for ICT security.

Identify and map devices, software, users and need for access

• Overview and control of how long we retain user data, and routines for deletion.

• Accesses must always be assigned at the minimum level; no one should have higher access than what is necessary to get the job done.

• See the sections on access for access levels for system users in AD, G Suite and M365.

Protect and maintain

• Establish a secure ICT architecture and protect the enterprise's network. Control data flow.

• Have control over identities and accesses.

• All passwords must be stored in a password vault. Passwords must not be reused. All passwords and accesses are personal.

• If you gain access to a customer system, the password and username must be deleted when the job is done.

• Protect data at rest and in transit.

• Retain critical information about deactivated users in eFeide and eADM to ensure blocking of reuse of usernames and other unique identifiers.

• After a set period, logs, personal information and access/rights history for a user are automatically deleted.

Detect and remove known vulnerabilities and threats

• In line with the first of the basic principles on "privacy by design", we actively strive to find vulnerabilities in our system. We therefore conduct annual penetration tests of our solutions. These are performed by Visma's security experts; see more information under "Penetration testing".

• Threat assessment is done in collaboration with the National Cyber Security Centre (NCSC). Identum is defined as critical infrastructure and receives notifications from the NCSC when security holes and exploits are discovered in server systems, software and other IT systems. Threat assessments are carried out continuously by Identum based on info from the NCSC. Relevant security holes are patched continuously as we become aware of them.

• All Identum servers, both in production and test environments, are updated weekly. This applies to the operating system, installed apps and other software. In addition, eFeide and eADM are also updated on Sundays, in accordance with 14-day development sprints. Identum has a dedicated resource responsible for ensuring this. After patching/updating, all systems are tested to ensure full functionality. Sunday is chosen due to low load and usage on Sundays . eFeide is not updated in connection with the start of the school year and exams, with the exception of operationally critical updates.

Handle and recover

All unwanted incidents regarding security or privacy are registered in a separate register, including time, place, who, measures and follow-up afterwards. The procedures are documented in Identum's internal contingency plan. Customers are notified of both internal and external unwanted incidents according to the Service Level Agreement (SLA). The procedures are documented in Identum's internal contingency plan. Where relevant, threat assessments from the NCSC are shared with customers.

Identum has an agreement for assistance from Visma's own cyber security group if the company comes under attack, is hacked, or if data security is otherwise threatened. Visma will then establish a response team that will be responsible for handling the situation, getting it under control and recovering any affected systems.

System monitoring and threat management

As of 01.02.2023, Identum AS is a wholly-owned subsidiary of Visma AS and subject to Visma's routines for cyber security, monitoring and threat management. Visma uses Sentinel One (SentinelOne | AI-Powered Enterprise Cybersecurity Platform) for Managed Detection and Response (MDR). Sentinel One runs continuous monitoring of Identum's servers, clients, endpoints and employees' computers. All incidents are logged, evaluated, and threats are automatically actively followed up by Visma's Security Operations Centre (SOC) team.

In the event of a sufficiently serious security incident or attack, Identum is notified by Visma; they have a 24/7/365 response and will implement measures even before Identum is notified. If the incident/attack is evaluated as critical or targeted at a specific customer, the customer is notified immediately and included in the team handling the incident. The normal notification service for our customers is via email; in such cases, you will also receive a phone call.

Backdoor and access if ordinary login is down

Identum has its own "break glass" accounts in our operating environment. If ordinary login for our employees is out of order for some reason, such accounts can be used to grant or restore access to the system. This backdoor is not used in normal operations, and all logins are monitored with immediate notification. In cases where the customer's login to eADM does not work (e.g. if the customer's AAD is down and SSO is therefore out of order), Identum can change to another login during the period the customer experiences downtime, e.g. from Entra ID SSO to login with ID-porten.

Penetration testing

Identum is part of Visma's PENTEST 2.0 programme. Continuous testing is triggered based on actual risk signals, rather than elapsed time. The testing is now driven by data from other services in Visma's Application Security Programme (Software Composition Analysis, Static Application Security Testing, Dynamic Application Security Testing, External Attack Surface Mapping) as well as expert assessments from Visma's own penetration testing team. Our customers are, of course, free to run their own penetration testing, with or without assistance from third parties chosen by the customer.

Operation and hosting

Identum's solutions are cloud-based and are operated and maintained in Entra ID via our operating partner Microsoft, with redundancy, remote backup and load balancing. We have two Entra ID environments: in Østfold for Norwegian customers, and in Gävle, Sweden, for EU customers. The uptime guarantee is 99.9% (see our SLA). Identum is responsible for the operating system and software, while Microsoft handles the operation of hardware, communication, offsite backup, redundancy and firewall. Only employees with technical responsibility in Identum or necessary operating personnel at Microsoft have access to the server environment. This takes place via Teamviewer clients with MFA. Identum has an extended SLA agreement with Microsoft with a response time within 10 minutes during office hours and 1 hour otherwise.

The only firewall ports that are generally open for incoming traffic are ports 80/443 for the use of Teamviewer, web clients and API clients. All traffic to port 80 is automatically routed to 443 so that communication takes place on an encrypted line via TLS. All web services/pages, internal and external, are secured with SSL certificates from Digicert.

Patching and updating

Patching of systems, components, servers, databases, etc., is done every Sunday. Identum has a dedicated resource for this. Identum is defined as critical infrastructure and receives notifications from the National Cyber Security Centre (NCSC) when security holes and exploits are discovered in server systems, software and other IT systems. Threat assessments are carried out continuously by Identum based on info from the NCSC. Relevant security holes are patched continuously as we become aware of them. Updating of systems, components, servers, databases, etc., is also done every Sunday. Identum does not use beta functionality or beta versions by default.

Encryption

Identum's servers are hosted in the Entra ID cloud and therefore use standard server-side encryption of all data during storage. The encryption keys are handled automatically by the Entra ID platform (Server-side encryption of Entra ID managed disks - Entra ID Virtual Machines). Communication between Identum's servers, clients, web browsers and third-party systems is end-to-end encrypted via TLS 1.2 with 2048-bit encryption, and the certificates are issued by Digicert. These are installed and maintained by the members of our operations team who have the necessary access to servers and the Digicert service. They are replaced/have a validity according to industry standards (12 months). Database, backup and operating systems are also encrypted. Furthermore, all user data is encrypted. In eADM and eFeide, all system passwords (secrets) are secured with Rijndael AES 256-bit encryption. Passwords for users are stored in our LDAP database, which uses standard Active Directory technology and therefore stores them hashed and encrypted. When transferring passwords (secrets), end-to-end encryption via TLS is always used.

Data Segregation and separation

Customer data is logically separated using a unique customer ID, effectively treating each customer as a distinct realm. This architecture mirrors the multi-tenant model found in Microsoft Entra,
where logical boundaries ensure that each client exists within a self-contained environment.
All data tables are linked to this unique ID, and every API request must include this key as amandatory parameter. By enforcing these realm-based boundaries, the system ensures that
authentication, authorization, and data storage are strictly scoped to the specific customer. This guarantees that data remains isolated and secure, preventing any cross-customer exposure.

Administrators can only be granted access to more than one instance of eADM by Identum, and the administrator cannot assign others the same access. It is recommended that such access is always given with an expiry date.

Backup and recovery

Databases are backed up every 10 minutes; the production environment as a whole is backed up daily. Backups are not stored in the production environment, but in a physically separate environment. To verify both the quality and content of backups and test data recovery, Identum's test environment is always created from backups. The test environment is a complete copy of the production environment. This is done at least every 14 days.

Continuity plan

If necessary, the entire operating/server environment can be recovered from scratch in under six hours, either in the same environment or in a secondary environment (e.g. if the primary environment is subjected to a DDOS attack). It is also possible to restore individual customers from a backup. This can be done both if errors occur in connection with upgrading or technical changes to the solution, or if the customer needs to recover, for example, after an import of corrupt data from the source system. This can be ordered via Identum's customer support, and such requests will be handled as a level A error according to the customer's applicable Service Level Agreement at any given time. If Identum independently decides that either the entire server environment or a specific customer must be restored, the customer is notified, either via the notification service in eADM or by telephone.

Preventive measures

Identum, like other Visma companies, has its own procedures for Risk assessment, Risk mitigation and Risk management. Risks are identified and assessed according to severity and probability (risk assessment). For each risk, there must be a preventive plan (risk mitigation) and a handling plan (risk management) if the risk actually occurs. This material is part of Identum's internal security documentation. This is, naturally, not public information. See also section 3 "System monitoring and threat management" and section 5 "ISO27001 and Visma Cloud Delivery Model".

Consequences of downtime on eADM

If eADM experiences downtime, all accounts in the organisation will function as before, with all rights and accesses. As long as eADM is down, accounts will not be created/updated/deactivated/deleted and no accesses/licences will be granted/changed/removed by eADM. It will still be possible to do this manually in the individual target system.

Consequences of downtime on eFeide

If eFeide, as the User Administration System (BAS) for the FEIDE directory, experiences downtime, FEIDE login will still function as before. It is only if SIKT (The Norwegian Agency for Shared Services in Education and Research, https://sikt.no/ ) experiences downtime that FEIDE login becomes unavailable. If eFeide has downtime, password handling functionality, internet access management and MFA administration of FEIDE accounts will be unavailable.

Consequences of downtime on source systems

If a source system is down, eADM and eFeide will naturally not be updated with new source data. Data flow from eADM and eFeide to target systems will continue as before. Examples of this are password changes, changes in group/teams membership, roles and rights. When the source system is available again, eADM and eFeide will process all source data again, so that all waiting users etc. get the necessary accounts and accesses.

Consequences of downtime on target systems

If a target system is down for a shorter or longer period, changes are placed in an export queue. When the target system is available again, the queue is processed. Examples of changes that are placed in the export queue are attribute changes (e.g. name of a user), passwords, group/teams membership, roles and accesses. It is logged in eADM when changes were placed in the export queue and sent to the various target systems.

Notification

Identum has several types of notification about errors, downtime or other incidents that have a negative impact on the service:

• Automatic system-based notification → The system sends out a status report after each completed synchronisation with general information. In addition, the system will notify if synchronisation stops, e.g. as a result of corrupt data or if a target system does not respond. It is also possible to set up your own notification criteria, either by email or SMS, e.g. if an administrator access is given to a user . eADM can be set up to notify automatically in case of error messages for individual users, e.g. if an update fails in a target system (given that the target system supports this!).

• Manual notification → Identum has its own notification list with email and SMS for all administrators in eADM and/or eFeide. This list is used to notify of incidents that negatively affect one or more customers. Both general and specific issues will be notified, in accordance with the SLA.

• Please note that customers who have their own monitoring systems can connect to the logs in eADM via API and automatically extract continuous logs with notifications, updates and errors.

Error reporting

All errors discovered by the customer can be reported directly to Identum via a form available to administrators in eFeide and eADM. This applies to all types of errors, both errors with the system and notifications of privacy-related incidents and measures. All privacy-related incidents are treated as a level A error according to the agreed service level agreement (SLA). All incidents are handled according to the basic principles for ICT security, section 4.-4.4. eADM and eFeide also have built-in functionality to submit suggestions for improvement. All proposals are assessed continuously.

Information security

GDPR and privacy

As a basic principle for importing source data into our systems, we only import users and user data that are to be processed further. If an employee is not to have an account in AD, we will filter this out from being imported into our systems at all. Guardian data is not used when importing into Feide directories. Only relevant user data is imported; for example, we import employment percentage (which may be relevant in connection with assigning licences) as opposed to salary data which we do not import. It is important to emphasise that it is the source data systems (HRM and SAS) that override. When a user is created in HRM, the user is created in eADM. When a user is deactivated or deleted from the system, the associated data will also be deleted, according to rules set in eADM. For example, it can be automated that users are first deactivated and then deleted from the system after a given period of time.

The security and privacy in eADM are completely dependent on the customer having good routines in connection with registering and deregistering users from their source systems. A common sigh from administrators when it comes to the lifecycle of user accounts is that "everyone notices when someone starts, but no one notices when someone leaves". Thus, you risk old user accounts and personal data lying around for a long time. The solution to this is good rule sets in eADM that ensure that data that is not to be stored is deleted, e.g. when the user is deactivated, goes on leave, dies or quits . eADM automates this and ensures all user accounts are either removed automatically or that necessary recipients are notified where something must be done manually. Via message templates, IT, operations, and admin can be notified when equipment is to be handed in, or accesses are to be changed or removed. All users have a login to the user interface, and everyone can see all data registered for their own user at any time.

In connection with GDPR and privacy, end users can see their data in a privacy section where we also state where the data comes from, who they should contact if something is incorrect, or if they want the data deleted. Identum's solutions meet all requirements for the Norm for information security. See Appendix 9 in the contract for Identum AS's data processing agreement. We have a principle that we adapt to our customers, instead of them having to adapt to us. If our standard data processing agreement does not cover the customer's needs, we adapt and use the one the customer wants.

Subprocessors

Please see the Visma Trust Centre for information about our hosting providers and data processors:

ISO27001 and Visma Cloud Delivery Model

As of 01.02.2023, Identum AS is a wholly-owned subsidiary of Visma AS and thereby subject to their quality system and delivery model as described here: The Visma Cloud Delivery Model (VCDM) describes our approach to developing, delivering and operating cloud services. It describes aspects of how we should be organised, how we should work (processes), as well as technical requirements and best practices necessary for successful delivery of cloud services. Further information about VCDM can be found at: The Visma Cloud Delivery Model (VCDM). The model is based on a set of core principles and focuses on DevOps and Continuous Delivery. VCDM has the following audit statement and certifications:

• ISAE 3402 SOC 1 Type II

• ISO 27001

The Visma Security Programme and the Visma Architecture and Technology Programme are integrated into the Visma Cloud Delivery Model. Our Information Security Management System (ISMS) is certified according to ISO 27001 and is audited annually by an independent IT auditor. In addition, Visma's ability to comply with ISMS and the quality management system in VCDM is audited by an independent audit firm in accordance with ISAE 3402. This comprehensive control is also carried out annually and is summarised in an ISAE 3402 Type II report. Our approach to implementing changes is continuous integration and continuous deployment (CI/CD). The methodology is constantly evolving in terms of technology, competence and procedures. Right now, this means that changes are continuously verified and implemented in our staging environment. There, manual tests are done both internally in the development department and by subject experts. For more extensive changes, we also use pilot customers who test the changes in normal operation for a period before they are released to all customers. Https://www.visma.com/trust-centre Visma Cloud Delivery Model.

Changes and updates

Changes and updates do not generally entail downtime. If this happens, it will be carried out in predefined service windows and notified in accordance with the SLA. We have a common, automatic, upgrade process for all environments. Frequent and small updates provide a low risk of errors with each change. We increasingly use implementation of upgrades directly in the production environment, but hidden behind feature toggles, so that the functionality is only activated when it is ready for the customer. In combination with automated tests, this provides high stability, fewer errors and rapid rollout of new features. Updates will be communicated differently depending on the size and scope of the change:

• Minor changes such as bug fixes that do not affect the customer or the user will be notified through an update of release notes.

• Medium changes such as changes or additions to work processes or screens will be announced in release notes, notifications on the start page, updated user documentation and on the Visma Community.

• Major changes such as new key functionality or a major change in a work process may additionally feature webinars and/or updated e-learning.

For major changes that require training and/or configuration of the system, we will involve the customer before we implement the change. The scope of this will vary depending on what kind of change it is. Our strategy for handling any errors that might occur during updates is to "roll-forward". This means that we want to correct the error and update with a new version, rather than rolling back. Only exceptionally and in the case of serious errors will it be relevant to roll back.

Security and access management

Identum operates its software mainly via web applications: https://mega.efeide.no, https://mega.eadm.no and https://mega.eADM.se. All access to the web applications is protected by a captcha, username and password, as well as 2FA authentication. The customer can themselves use these portals for administration and self-service, but then with other accesses and rights (see the section on access management). We recommend all our customers to use authentication with MFA enabled, and we require that all access to all our systems at the administrator level must be with MFA. We offer login via username/password with MFA, ID-porten, or SSO with Entra ID. If SSO is used, we require that access is protected at the rights level of Department Manager and upwards. It is an important principle not to grant higher access than what is necessary.

We therefore recommend that you are restrictive about granting access at the administrator level. For the vast majority of daily operations, service desk user access is sufficient. For users who only need to solve a specific task, for example managing passwords for a department, super user access is enough. Only absolutely necessary personnel should have administrator access to the system, and this should be considered time-limited. This principle limits access to personal data and the opportunities to assign accesses or rights. All changes performed via the web interface are automatically logged. The customer is routinely notified in the event of unwanted incidents, in addition to the daily status report from our systems.

We emphasise that we recommend that access to eFeide and eADM is protected with two-factor authentication for all users with administrator access; this functionality is part of the solutions. Our policy for access management is that users should not be given a higher access level than they need on a daily basis; higher access is assessed according to need. Administrator access should only be assigned to a few selected users who have completed training in using the system. An example might be that 1st-line support at the customer has service desk access, while only 3rd-line has access to the system at administrator level. Identum recommends all our customers follow this policy when setting up rules for automatic or manual access management to business systems, third parties, etc., via eADM.

Internal personnel

This also applies to Identum's own employees. Employees only get necessary access according to position and function. When employees leave, all accesses are removed immediately. Identum does not use assistance from external third parties and has a policy that only employees actively working with the operation and user support of the solution have access to the customers' data. The different access levels and roles in Identum are firmly defined, and are audited and needs-tested at regular intervals in accordance with ISO27001. All changes made in the system are logged in the same way as the customer's own users. So if an employee in Identum grants an access to a business system at a customer, it is logged in the history of the user who received the access. It is not possible to copy user data between the different instances in the user interface, only templates and rule sets.

Access control

Both eFeide and eADM support different methods for user login, including two-factor authentication. We offer (of course) FEIDE login, ID-porten, ADFS/LDAP, SSO with Entra ID/EntraID, SSO with Google Workspace and other SAML2.0 authorisation solutions. We expect customers to protect SSO login with MFA; it is not recommended that access to eADM and eFeide is without two-factor protection, even at employee/department manager level. At the service desk and administrator level, we require our customers to protect SSO with MFA, or alternatively use ID-porten. System accesses can be given automatically based on rule sets or manually for the individual user. We recommend that administrator accesses are only given manually and based on needs. Accesses can be given with or without an expiry date, and the system has a solution for both active and passive access review at given time intervals. The different access levels can be administered at group, role and personal level. For example, the login to the user interface for eFeide can be regulated so that everyone who has access to see personal data about other users must log in with two-factor authentication, while students (who can only see their own data) can log in without using two-factor.

Employees

The system also takes into account that one and the same user can have different roles in the different departments, with varying needs and accesses. An employee can see all available information about themselves and change their password. A department manager only sees their employees. If a user is a department manager and at the same time is employed at another level in the organisation, this user will only have administrator access to the department where he/she is a department manager. In the other department, he/she will only have ordinary employee access. The six roles provide access to functional areas, underlying information and functionality.

History, logs and access review in eADM

eADM has full logging of all changes made at the object level, i.e. for users, groups and departments. The logs are available to anyone with administrator access in the solution. Both changes coming in from source systems and changes made in eADM are logged. The system also logs all data sent to the various source systems, so that you have a full overview of which data has been exported where. All entries are logged with object ID, date/time, the reason for the change, who performed the change if it is a manual change, the previous value and the new value. All changes to the system setup itself are also logged. This means all changes to rule sets, synchronisation templates, message flows, access controls and workflows. All logs are stored, encrypted, digitally and physically protected according to the same standards as Identum's other data. Logs cannot be changed by any type of user, including Identum's own "superduper" administrator role. Logs can be exported for processing in third-party systems. All incidents, logs etc. can be set up to trigger a notification by email or SMS when they occur. For example, the system can notify of specific error messages in connection with export to sensitive systems or when a user logs on with an IP address outside a given geographical area.

Logging of changes to user data, rights and accesses

In the user interface of eADM, one can also see all accesses and licences assigned to a user, both in eADM and in associated target systems. The history shows when an access or licence was assigned, whether it was given automatically based on a rule set or manually by a user. One will be able to see what a user has access to in a case/archive system, and what type of access it concerns. eFeide logs all rights changes in addition to changes in user data and passwords. If an access is granted by a rule set, one can further track who made the change in the rule set that triggered the access.

Security and password logs

Security logging in eADM logs all login attempts, both authorised and unauthorised with who, time, location (IP), type of authentication and status. In addition, all error messages are logged, with method (e.g. type of API call), time, user and IP. All password changes are logged, with time and date stamp, how the password change was made, who initiated the password change, whether the password was exported further to other target systems, and with any error messages.

Third-party access

The customer themselves controls who has access to customer data in eADM via the user interface. Data flow to target systems is controlled via synchronisation templates where the customer themselves decides which data is to be exposed to/transferred to each individual third party. eADM does not allow third parties to retrieve data from the system at their own discretion, unless the customer specifically grants this access via the API. See also the point on "Penetration testing".

Password handling

In eADM and eFeide, all system passwords (secrets) are secured with Rijndael AES 256-bit encryption. Passwords for users are stored in our LDAP database, which uses standard Active Directory technology and therefore stores them hashed and encrypted. When transferring passwords (secrets), end-to-end encryption via TLS is always used. This applies to all transfer of data to and from the solution. Passwords are not accessible to any users in eADM or eFeide, be it the employees themselves, department managers, or administrators. The only exception is initial passwords, naturally since they must be readable, printable and sent to the employee. After the first login, this password will be changed and stored encrypted. From then on, no one will be able to see it; it can only be changed. Initial passwords for users are created in eADM/eFeide when a user account is created. The password is generated according to rule sets set up according to requirements from the customer, e.g. 16 characters, capital letter, at least 1 special character.

When a user account is created in target systems such as AD, Entra ID or business systems, the users can be created with the same initial password. This is transferred encrypted. Passwords can be changed in our solutions and transferred in real time to the target systems. Requirements can be set that users must change their initial password in connection with login to Entra ID, AD and Google before they are allowed to log in. Identum has a solution to reset passwords via SMS or via authentication through ID-porten, and we strongly recommend ID-porten. All password changes are logged, with time and date stamp, how the password change was made, who initiated the password change, whether the password was exported further to other target systems, and with any error messages. In eADM, department managers can change passwords for their employees, either by assigning a new password or sending a generated password to the employee via SMS if a mobile phone number is registered on the user.

We recommend, however, that the procedure should be that employees do this themselves via the forgotten-password portal. Service desk users and administrators in eADM can change passwords for all users, either by assigning a new password or sending a generated password to the employee via SMS if a mobile phone number is registered on the user. We recommend, however, that the procedure should be that employees do this themselves via the forgotten-password portal. In eFeide, teachers can change passwords for pupils, school administrators can change passwords for pupils and teachers at their school, and municipal administrators can change passwords for all users. Feide does not support forced password change.

Security and Feide services

In eFeide, administrators can manage login with MFA for given Feide services for employees. Requirements for MFA for Feide services can be set both individually and for whole schools. A two-factor method is what a user uses to prove their identity when a Feide service requires two-factor authentication. Feide has four different available two-factor methods; login via ID-porten, code via SMS, code sheet, and authenticator client (MS Authenticator or Google Authenticator). Which Feide services are to be protected with MFA is up to the individual customer; our rule of thumb is that all Feide services where personal information about pupils and/or employees is stored should be protected with MFA. A cloud-based school administrative system is an example of a system that, in our opinion, should be protected with two-factor login.

Export of personal data to target systems

Both eADM and eFEIDE contain personal data, and one should be careful about which data is exported to which target systems. A rule of thumb should be that you should only export the minimum of data that the target system needs. In addition, a needs assessment should be carried out for data such as national identity numbers, private contact information, salary information, etc.

Use of national identity numbers in Active Directory

We recommend that if a national identity number is used as a unique identifying attribute in AD (e.g., in the attributes employeeID or employeeNumber), this should either be encrypted (there is functionality for this in both systems) or hidden so that viewing these attributes is only available to administrators: How to Hide User Attributes in Active Directory.

Use of national identity numbers in Entra ID / Entra ID

We do not recommend the use of national identity numbers as a unique identifying attribute in Entra ID, as this field cannot be protected or hidden. Use employee numbers or another unique number series instead.

Summary for AI and Search

This document outlines the comprehensive security framework for Identum's eADM and eFeide products. It covers the "Privacy by Design" and "Zero Trust" development philosophy, ISO 27001 certification via the Visma Cloud Delivery Model, and secure hosting in Microsoft Entra ID. The framework includes continuous threat monitoring by Visma's SOC, annual penetration testing, robust backup and disaster recovery plans, and detailed policies for encryption, access control, and GDPR-compliant data handling.