Unauthorized access to a certificate is not only a security risk. It is also a risk to a company’s control, accountability, and digital identity.

🔐 Key Messages

✅ A certificate is not just a file. It is part of a company's digital identity.

✅ API integrations introduce new security scenarios that did not exist in the traditional use of token-based certificates.

✅ Not all e-Invoice solutions use the same security architecture or certificate management model.

✅ If the certificate, private key, and password are accessible outside the company, additional controls, procedures, and contractual obligations are required.

✅ Companies should know where the certificate is stored, who has access to it, and whether its usage is logged.

✅ Choosing between a token certificate, a software certificate, and Azure Key Vault is not only a technical decision but also a security and organizational one.

✅ Before selecting an e-Invoice solution, ask for an explanation of the security architecture, certificate model, user roles, and audit trail.

For years, digital certificates in North Macedonia have been used for accessing and signing documents within systems such as the Public Revenue Office (PRO), the Central Registry, commercial banks, electronic public procurement systems, and other public and private electronic services.

In most cases, the certificate was protected inside a physical token. The PIN was known only to the user, and the private key never left the device. The user personally logged in and personally approved each activity.

With the introduction of API integrations and automated document exchange, particularly in the context of the PRO e-Invoice project, a new situation has emerged.

👉 What happens when the certificate is no longer used by a person, but by software?

Unlike traditional web applications used by the PRO, ERP and API integrations require the application itself to digitally sign documents and communications with external systems. In some architectures, this means that the certificate, private key, and password become accessible to software and, in certain cases, to the vendor configuring the integration.

This is where a new security dimension of e-Invoicing begins.

This text is not intended to create fear of certificates or automation.

Quite the opposite. The goal is to help companies understand the differences between various operational models, the potential risks, and the questions they should ask before deciding on a solution, integration approach, or vendor..

Certificate Security Depends on More Than the Certificate Type

Certificates themselves are neither secure nor insecure.

In practice, the level of security most often depends on:

• Where the private key is stored,

• Who has access to it,

• Whether it can be copied,

• How its use is controlled,

• Whether an audit trail exists,

• How user and responsibility changes are managed.

There is no universally best model for all organizations.

Different companies have different needs regarding automation, control, availability, and security.

Three models are most commonly used today.

Three Models Commonly Used for e-Invoicing

Model	Level of Automation	Level of Private Key Control	User Interaction	Typical Use Case
🔵 Token Certificate	Low	High	Yes	Manual Signing
🟠 Software Certificate	High	Medium to High*	No	ERP and API Integrations
🟢 Enterprise Models (Azure Key Vault / HSM)	Very High	Very High	No	Larger Organizations

It is important to understand that no model is inherently secure or insecure. In most cases, the difference lies not in the certificate itself, but in the solution’s architecture and the way it is managed by the organization.

🔵 Token Certificate

The token certificate is the model that most companies in North Macedonia already know through the PRO, Central Registry, and commercial banks.

Its greatest advantage is that the private key remains inside a physical device and cannot easily be copied or transferred.

Advantages

• Private key cannot easily be copied

• High level of control

• Clear connection between the user and the signature

• Lower risk of unauthorized use

Disadvantages

• Difficult to automate

• Depends on user availability

• Limited support for background processing

Best Suited For

• Business owners

• General managers

• Finance directors

• Companies with a lower volume of documents

🟠 Software Certificate

Software certificates enable full automation and are therefore the most common choice for ERP and API integrations.

However, because of automation, the method used to manage the certificate becomes much more important than with token certificates.

If the certificate is not properly protected, the risk does not arise from the certificate itself, but from how it is stored, used, and shared.

Advantages

• Automatic document exchange

• No physical presence required

• Supports background processing

• High operational efficiency

Disadvantages

• The certificate can be copied

• Additional controls are required

• Access management procedures are required

Best Suited For

• ERP systems

• API integrations

• Companies with a large volume of invoices

• Automated business processes

🟢 Enterprise Certificate Management Models

In this model, the private key is not directly available to users or business applications. Instead, it is stored within specialized key management and digital-signature infrastructure.

Examples include Azure Key Vault, HSM solutions and other enterprise certificate-management platforms.

Advantages

• Highest level of security

• Centralized management

• Better traceability

• Easier certificate rotation

• Better compliance with security policies

Disadvantages

• Greater complexity

• Initial configuration effort

• Additional costs

Best Suited For

• Large companies

• Corporate groups

• Organizations with higher security requirements

⚖️ Which Model Is Best Suited?

There is no certificate type that is best for every company.

The choice usually depends on:

• Number of documents processed

• Need for automation

• Security requirements

• Internal controls

• Roles and responsibilities

• Existing IT infrastructure

Companies that process a relatively small number of documents often successfully operate with token certificates. Organizations that require ERP and API integrations most commonly use software certificates.

Larger organizations increasingly rely on centralized services such as Azure Key Vault or HSM solutions.

👤 Digital Identity Should Not Be a Shared Responsibility

In a well-organized company, every important activity should have clear accountability.

It should always be known:

• Who performed the activity,

• When it was performed,

• Under which permissions,

• Under whose responsibility it occurred.

The same principle should apply to certificates.

The more people who have access to a single certificate, the harder it becomes to determine who actually performed an action.

Therefore, security is not only about protecting the certificate. It is also about maintaining accountability and traceability within the company.

⚠️ Most Common Risks Related to Certificates

In most cases, problems do not begin with the certificate itself.

Problems begin when the organization loses control over it.

Typical risks include:

• The certificate is stored in multiple locations;

• Multiple people have access to it;

• The password is known to multiple users;

• No record exists of who used it;

• Responsibility for managing it is unclear;

• There are no procedures for changing responsible persons;

• There are no procedures for employee departures;

• Certificate copies remain in test environments and are never removed.

When the Certificate Leaves the Company

In some integration scenarios, a company may be asked to provide:

• The certificate,

• The private key,

• The password,

  
  

to enable the software vendor to configure the integration and establish communication with the e-Invoice system.

This approach may be technically feasible, but it introduces additional security risks.

Once the certificate and password become available outside the company, the organization no longer has complete control over:

• Where the certificate is stored;

• How many copies exist;

• Who has access;

• Whether it is used in test environments;

• Whether access is restricted;

• How secure the systems are where it is stored.

Trust is important, but good security must be supported by procedures, controls, and clearly defined responsibilities.

A Hypothetical Example

A company decides to implement an ERP integration with the PRO e-Invoice system.

The software vendor requests:

• The certificate,

• The private key,

• The password,

  
  

to configure the integration.

After some time, nobody in the company knows:

• Where the certificate is stored,

• How many copies exist,

• Who has access,

• Whether it is still used in test environments,

• Whether old copies have been deleted.

  
  

Over the years, employees leave, servers change, infrastructure evolves, and external partners are replaced. The company finds it increasingly difficult to determine where certificate copies exist and who can access them.

Years later, the company wants to determine who used a specific certificate and when.

Some employees have already left, the infrastructure has changed, and documentation is incomplete.

The certificate still works.

But accountability is no longer clear.

The Problem Is Not Sharing the Certificate. The Problem Is the Lack of Rules.

In certain cases, the software vendor may legitimately assist with certificate configuration.

The question is not whether access exists.

The question is how that access is controlled.

A good practice is for the company to know:

• who will have access;

• how long the access will remain in place;

• where the certificate will be stored;

• whether any copies will be retained;

• what contractual obligations apply;

• how access will be removed once the configuration is complete.

  
  

When these rules are clearly defined, the risk is significantly reduced.

Potential Consequences of a Compromised Certificate

Most organizations will never experience a certificate-related security incident. However, when such an incident occurs, the consequences can be significant.

Possible consequences include:

• Unauthorized use of the company’s digital identity,

• Signing actions without the knowledge of responsible personnel,

• Loss of control over who performed an action,

• Compromised audit trails,

• Additional internal and external investigations,

• Legal and regulatory consequences,

• Loss of trust among business partners.

In such situations, the biggest challenge is often not the incident itself.

The biggest challenge is the inability to determine with certainty who performed the activity and under whose responsibility it occurred:

👉 who performed the activity and under whose responsibility it occurred.

This is directly related to the themes discussed in the previous articles in this series: accountability, traceability, and control.

Recommended Practices

Good security does not depend on a single product.

It depends on processes.

Companies should ensure:

✓ A clearly defined certificate owner

✓ A designated responsible person

✓ Visibility into all individuals with access

✓ Access revocation procedures

✓ Periodic review of permissions and access rights

✓ Separation of user and administrative roles

✓ Audit trail of performed activities

✓ A certificate renewal and replacement plan

✓ Alignment of certificate usage with internal security policies

Not All ERP Solutions Work the Same Way

Some solutions allow the company to independently manage and enter the certificate.

Some allow the company to do so without sharing the certificate, private key, or password with any third party.

Other solutions require the vendor to perform the configuration.

Some support token certificates, software certificates, and enterprise models such as Azure Key Vault.

Others support only a single model.

Therefore, when evaluating a solution, it is not enough to verify that it supports e-Invoicing. It is equally important to understand how certificates, users, and security are managed.

🔍 Vendor and Solution Selection Checklist

When selecting an e-Invoice solution, companies should consider asking several additional questions.

Certificates

□ What types of certificates are supported?

□ Are token certificates supported?

□ Are software certificates supported?

□ Are Azure Key Vault or HSM solutions supported?

□ Can the company migrate to a different model at a later stage?

Certificate Management

□ Does the vendor require a copy of the certificate?

□ Does the vendor require the private key?

□ Does the vendor require the password?

□ Where will the certificate be stored?

□ Where will the password be stored?

□ Will the certificate be used only in the production environment, or also in test environments?

□ Can the company independently upload, manage, and replace the certificate?

Architecture and Audit

□ Is every activity logged by user?

□ Can it be determined who sent a document?

□ Can it be determined who signed a document?

□ Can it be determined who changed the configuration?

□ Does the system provide an audit trail for all activities?

Users and Access Control

□ Does each user have a unique identity?

□ Are different roles and permissions supported?

□ Can access to specific activities be restricted?

□ Is the person who performed an activity recorded?

□ Is there an audit trail?

□ Can access be revoked immediately?

Security and Accountability

□ Who is responsible for certificate management?

□ How are employee departures handled?

□ How is a compromised certificate handled?

□ How are certificates renewed?

□ Are there documented security procedures that can be presented to the customer?

📋 Management Checklist

Before putting an e-Invoice solution into operation, a company should be able to confirm the following:

□ The location where the certificate is stored is known.

□ It is known who has access to the certificate.

□ It is known who is responsible for managing the certificate.

□ Procedures exist for changing responsible persons.

□ Procedures exist for handling employee departures.

□ Activities are logged and recorded.

□ Access is restricted to authorized individuals only.

□ A model has been selected that aligns with the organization and its risk profile.

□ Certificates form part of the company's overall IT and security policy.

🎯 Conclusion

For years, digital certificates in North Macedonia were primarily used through web applications, where users personally possessed the token, knew the PIN code, and individually approved each activity.

With API integrations and automated document exchange, new opportunities emerge, but so do new responsibilities.

Therefore, when selecting an e-Invoice solution, it is not enough to verify whether it supports integration with the Public Revenue Office (PRO).

It is equally important to understand:

• where the certificate is stored,

• who has access to it,

• how its use is tracked and recorded,

• how the company's digital identity is protected.

A certificate is not merely a tool for signing documents.

👉 It is part of the company's trust, accountability, and digital identity.

🚀 Preparing for e-Invoicing Starts Long Before the First Integration

Selecting a certificate is only one aspect of the overall preparation process.

Equally important are the roles, responsibilities, privileges, procedures, and security controls that support a successful implementation.

Through the e-Invoice Readiness Program, we help organizations assess certificates, privileges, organizational roles, risks, and security controls before selecting a solution and before implementation begins.

The objective is not merely to send the first e-Invoice successfully.

The objective is to establish a secure, controlled, and sustainable process that continues to operate effectively long after deployment.