An IHG Network ID can provide access to multiple workplace systems.
That makes the account useful—and makes credential theft more consequential than losing access to one isolated website.
IHG’s information-security policies require employees to complete annual training on responsible information handling, including password security, email security, vendor relationships, and secure transfer of data.
IHG’s current Merlin support environment also uses a separate authenticator layer in addition to the password.
Good Merlin security therefore depends on protecting both the credential and the second factor.
Password and MFA Are Separate Security Layers
IHG’s Network Account Support documentation distinguishes between:
password lock
and
authenticator lock.
That distinction matters during both troubleshooting and security incidents.
Someone who knows your password may still be blocked by your second factor.
Someone who obtains an MFA response may be attempting to complete a login already started with stolen credentials.
Never Approve Authentication You Did Not Initiate
If an unexpected authentication request appears, do not approve it simply to make it disappear.
First ask:
Did I just attempt to sign in?
Which IHG application am I accessing?
Does the authentication request match what I expected?
Unexpected requests can indicate another person is attempting to use the account.
Repeated Authenticator Failures Can Trigger a Lock
IHG’s current support page says repeated incorrect Entrust or MFA challenges can lock the authenticator.
It currently documents automatic unlocking after approximately ten minutes, with Global Support available when the problem persists.
A locked authenticator is therefore not the same thing as an expired or forgotten password.
Password Guessing Can Also Lock the Account
IHG separately documents account locking after repeated incorrect password attempts.
If you are unsure of the password, use the official recovery mechanism rather than repeatedly testing guesses.
The goal of lockout controls is to prevent unlimited attempts against a workplace account.
Phishing Can Mimic Real IHG Workflows
A convincing phishing message might claim:
your Merlin account is expiring;
your payroll or benefits require confirmation;
a hotel application must be upgraded;
your employee travel benefit needs revalidation;
your MyID account has been disabled.
The presence of familiar IHG terminology does not prove the message is legitimate.
IHG publicly states that its information-security program includes password and email-security education and colleague awareness activities.
Verify the Destination Before Entering a Password
A branded employee portal is particularly easy to imitate visually.
Do not judge a sign-in page only by:
IHG logo;
Merlin wording;
hotel imagery;
“employee portal” title.
Use the destination supplied through authorized IHG channels, existing bookmarks, hotel administration, or current IHG support resources.
An independent editorial website should never ask for Merlin credentials.
Watch for Fake Support
An attacker does not always need a fake website.
They can call or message pretending to be:
Global Support;
hotel IT;
a manager;
a vendor;
corporate security.
If the request involves a password, MFA response, or unusual data transfer, verify the person through an independent official channel.
Supplier and Contractor Access Needs Extra Care
IHG’s security policy specifically includes guidance around working with vendors and transferring data securely.
Contractors with sponsored Network IDs should use their own accounts.
Employees should not provide a vendor with their personal Merlin login because “they need to fix the system.”
Correct vendor access should be provisioned through the authorized sponsor process.
Confidential Hotel Information Also Matters
Security is not limited to personal employee data.
Hotel systems can contain:
occupancy and performance information;
commercial data;
guest information;
pricing;
financial data;
operational reports;
supplier information.
IHG states publicly that protecting information is an organization-wide responsibility.
A legitimate login does not authorize a user to export every accessible record.
Shared Accounts Create Accountability Problems
Never solve staff shortages by allowing several employees to use one person’s Network ID.
Individual identities make it possible to determine:
who performed an action;
which role had access;
who needs access removed after leaving.
Shared passwords undermine those controls.
Inactive Accounts Are Disabled
IHG’s current support page says inactive accounts can be automatically disabled after an extended period without login; the detailed current re-enable section refers to more than 180 days of inactivity.
That is a security control.
An employee returning to a role after a long absence may therefore need account re-enablement rather than ordinary password recovery.
When You Suspect Compromise
Use a structured response.
1. Stop using suspicious links
Return to a verified IHG environment.
2. Secure the credential
Use the official password/account process when appropriate.
3. Review the second factor
If unexpected MFA activity occurred, report it through the approved support channel.
4. Notify the appropriate IHG/hotel support function
Especially if confidential hotel data or another user’s information may have been exposed.
5. Do not delete evidence prematurely
Suspicious emails, timestamps, and messages can help security teams understand what happened.
Security and Troubleshooting Overlap but Are Not the Same
A forgotten password is a usability issue.
An unexpected password reset email can be a security issue.
A locked authenticator after your own failed attempts is troubleshooting.
An authenticator prompt you never initiated may indicate suspicious activity.
The symptom can look similar.
The context determines the response.
The Merlin Security Model
Think in layers:
Network ID — protect the identity.
Password — keep it private and unique.
Authenticator/MFA — never approve unexpected requests.
Application permissions — access only what the role requires.
Data handling — protect information after login.
Vendor access — use authorized external identities.
Support — verify the channel before sharing sensitive information.
The objective is not merely to keep the account working.
It is to keep an authorized workplace identity under the control of the person it belongs to.